2014-1-4 23:32 /
随手写了个cgm脚本生成器(解不开脚本只有这样了,完坑后谷歌上挂代码)
另外随手写了个99月的脚本简易转换器。挂在谷歌上的。有兴趣可以去看看233.

文本提取后提取前的对比。

PS : 抱歉的是。hf里面将不会使用我的引擎。因为还没有完善233,
如何汉化组给我ab的授权,到时候应该会用上的。
目前使用ONScripter+LUA进行移植。

一个WorkQueue+图形   另一个是WorkQueue+少量图形
由于LUA的图形线程和ONS的图形线程实质上是平行的关系,所以,LOOP和Multi-event之类的事件只能由LUA分担。

ONS默认是SDL—image进行图片加载的,从(FILE *fin)加载到SDL_Surface *dst的,本来surface的加载就很耗时间了,再加上ONS自己预处理,那个效率简直无法忍(这也是lsp2为何如此低效的原因了)。


整个ONS被封装在ONScripter这个大类下面的,而ONScripter以public方式将ScriptParser这个小一点的class给继承过来。
在初始化的时候建立一个ons的实例,然后调用成员。我无法评论这货的好坏,我只能说,太蛋疼了。
ONS在书写过程中,没有给多线程留下一点发展空间,无论是它的图形线程还是他的work线程都是紧紧绑定在一起的233.我曾经想改造ONS,但是一天过后我放弃了。
ONS也有一个比较优秀的变种版本,支持多线程的,但是我还是放弃改造了,第一书记不支持IOS和android。并且其中的thread系统可以说是极为简陋,如果是单核的cpu,直接禁止多线程(爪机上)。PS:在我自己的引擎中,我放弃了SDL_thread 。系统大不了分两种,一种win框架的,还有一种就是类unix的。前者我们不提,后者直接使用pthread。

第二点才是最重要的,那就是整个工程动不动就用this,动不动就用宏,而且这个版本的ONS并不支持LUA。所以在自己引擎还没开发好之间还是老老实实用原版本的ONS吧。

再多废话几句,LUA的语法我真心不喜欢,以后将转战as(啥时候能把指针给加上就好了,说实话,没有了指针,真心不习惯)。

//=============================================================
Koe自动移植完成,要开始最痛苦的图形了=。=

2014春节之前会发布移植(不出意外的话)。
本人Gmail:[email protected]

下面卖两个萌。


//=============================================================
移植完毕,进入Debug阶段=。=
Tags: Rewritehf