- 浏览: 3047838 次
- 性别:
- 来自: 海外
文章分类
- 全部博客 (430)
- Programming Languages (23)
- Compiler (20)
- Virtual Machine (57)
- Garbage Collection (4)
- HotSpot VM (26)
- Mono (2)
- SSCLI Rotor (1)
- Harmony (0)
- DLR (19)
- Ruby (28)
- C# (38)
- F# (3)
- Haskell (0)
- Scheme (1)
- Regular Expression (5)
- Python (4)
- ECMAScript (2)
- JavaScript (18)
- ActionScript (7)
- Squirrel (2)
- C (6)
- C++ (10)
- D (2)
- .NET (13)
- Java (86)
- Scala (1)
- Groovy (3)
- Optimization (6)
- Data Structure and Algorithm (3)
- Books (4)
- WPF (1)
- Game Engines (7)
- 吉里吉里 (12)
- UML (1)
- Reverse Engineering (11)
- NSIS (4)
- Utilities (3)
- Design Patterns (1)
- Visual Studio (9)
- Windows 7 (3)
- x86 Assembler (1)
- Android (2)
- School Assignment / Test (6)
- Anti-virus (1)
- REST (1)
- Profiling (1)
- misc (39)
- NetOA (12)
- rant (6)
- anime (5)
- Links (12)
- CLR (7)
- GC (1)
- OpenJDK (2)
- JVM (4)
- KVM (0)
- Rhino (1)
- LINQ (2)
- JScript (0)
- Nashorn (0)
- Dalvik (1)
- DTrace (0)
- LLVM (0)
- MSIL (0)
最新评论
-
mldxs:
虽然很多还是看不懂,写的很好!
虚拟机随谈(一):解释器,树遍历解释器,基于栈与基于寄存器,大杂烩 -
HanyuKing:
Java的多维数组 -
funnyone:
Java 8的default method与method resolution -
ljs_nogard:
Xamarin workbook - .Net Core 中不 ...
LINQ的恶搞…… -
txm119161336:
allocatestlye1 顺序为 // Fields o ...
最近做的两次Java/JVM分享的概要
从我开始关注吉里吉里2这个引擎开始,就一直看到关于“KAG的执行效率比TJS2低很多”的说法。但是到底慢多少呢?没见到过具体测评。
有机会的话我看看设计一个测评方法好了。关键是看看eval,iscript这两个标签里的表达式执行效率与真正的TJS2有多少差距。不过在那之前,我们可以看看“KAG比TJS慢”这种说法在吉里吉里引擎发展过程上的根源。
======================================================================
回到2001年,当时的吉里吉里只发展到吉里吉里1,具体版本号吉里吉里0.91/KAG 2.3;要执行KAG 2.3的吉里吉里本体至少要达到0.89.6.1512版本。当时的KAG脚本是如何被解释执行的呢?
\system\KAGMain.tjs/3384行: function getNextLine()
\system\KAGMain.tjs/3472行: function getCurrentElement()
\system\KAGMain.tjs/3641行: function getNextElement()
\system\KAGMain.tjs/2610行: function process(storage="",start="",incflag=true, run=true, immediate=false)
\system\KAGMain.tjs/3771行: function processOne()
这几个就是构成KAG解释/执行系统的主要函数,加上在KAGMain.tjs里的其它函数,构成了KAG系统的执行核心。这个核心与system目录里的其它TJS脚本合在一起,则构成了完整的KAG系统。
可以看到,吉里吉里1里的KAG系统是完全由TJS脚本实现的。其中在MainWindow.processOne()里,有这样的代码片段:
于是可以很明确的看出,吉里吉里1中的KAG系统的执行核心是一个switch dispatch loop,KAG脚本由TJS解释执行;而用于实现KAG系统的TJS又由底层的吉里吉里1本体解释执行。我手上没有吉里吉里1核心部分的源代码,不太清楚当时TJS是如何被解释的,不过想来其执行效率肯定没有现在的TJS2高;可以想像当时的KAG系统与现在相比肯定是慢很多。
进入到吉里吉里2时期后,为了解决KAG系统的性能问题,其核心解释执行部分被移动到了吉里吉里2本体中,以C++代码实现。
吉里吉里2的源代码中,
\kirikiri2\src\core\utils\KAGParser.h
\kirikiri2\src\core\utils\KAGParser.cpp
这两个文件定义了TJS2中可以使用的KAGParser这个native class。但在这对C++源代码里却找不到KAG系统里用到的tag。它们跑哪里去了呢?
在原版KAG系统(2.28稳定版)中,\system\MainWindow.tjs/4551行,
或者在KAGEX(同样在2.28稳定版)中,\system\MainWindow.tjs/5770行,
这里,MainWindow内定义了一个函数,用于获取一个关联数组,这个数组里元素是tag名与其对应的处理函数。在构造MainWindow对象时,这个关联数组会被作为参数用于构造一个Conductor对象。注意到,Conductor类继承于BaseConductor类,而BaseConductor类继承于上面提到的KAGParser。
在原版KAG系统(2.28稳定版)中,\system\Conductor.tjs/433行,
或者在KAGEX(同样在2.28稳定版)中,在\system\Conductor.tjs/441行,
这样就可以知道,吉里吉里2中KAG系统有部分的核心被移动到了吉里吉里2本体中以提高运行效率,而具体与tag对应的操作依旧以TJS2实现。
由于吉里吉里2中的关联数组实现比吉里吉里1中的更高效,并且在tag的处理上以table-driven的方式替代了吉里吉里1中的大switch语句,运行起来应该是更快的。但其本质并没有改变:每个KAG脚本中的tag都是一个对TJS定义的函数的调用。
要在KAG脚本里实现相同的(复杂)功能,一般有两种选择:1、以iscript块嵌入TJS脚本,并将其注册为一个插件;或者直接把一些KAG tag组合在一起写成一个macro。从上面的分析应该能看到,使用嵌入的iscript将比简单的使用macro有更精确的控制,因而也确实会更加有效。
如果感到在KAG系统有什么功能会经常被用到,但原本的KAG系统并没有提供,也有另外一种方法来修改:直接在MainWindow.tjs的getHandlers()函数里添加需要的tag与其对应的处理函数。这又比在KAG脚本中嵌入iscript快要更直接,代价是对KAG系统有侵入性。
======================================================================
回到前面提到的,嵌入在KAG脚本中的iscript块的执行问题,在吉里吉里2中有这样的代码片段:
\kirikiri2\src\core\utils\KAGParser.cpp/1070行: bool tTJSNI_KAGParser::SkipCommentOrLabel()中
可以看到,iscript块的执行其实与TJS2普通的全局脚本一样,是直接通过TJS2 VM来完成而没有太多经过别的处理。从这点看,无论是普通的TJS2代码还是嵌入在KAG脚本中的TJS2代码,在执行效率上都应该差不多。
有机会的话我看看设计一个测评方法好了。关键是看看eval,iscript这两个标签里的表达式执行效率与真正的TJS2有多少差距。不过在那之前,我们可以看看“KAG比TJS慢”这种说法在吉里吉里引擎发展过程上的根源。
======================================================================
回到2001年,当时的吉里吉里只发展到吉里吉里1,具体版本号吉里吉里0.91/KAG 2.3;要执行KAG 2.3的吉里吉里本体至少要达到0.89.6.1512版本。当时的KAG脚本是如何被解释执行的呢?
\system\KAGMain.tjs/3384行: function getNextLine()
\system\KAGMain.tjs/3472行: function getCurrentElement()
\system\KAGMain.tjs/3641行: function getNextElement()
\system\KAGMain.tjs/2610行: function process(storage="",start="",incflag=true, run=true, immediate=false)
\system\KAGMain.tjs/3771行: function processOne()
这几个就是构成KAG解释/执行系统的主要函数,加上在KAGMain.tjs里的其它函数,构成了KAG系统的执行核心。这个核心与system目录里的其它TJS脚本合在一起,则构成了完整的KAG系统。
可以看到,吉里吉里1里的KAG系统是完全由TJS脚本实现的。其中在MainWindow.processOne()里,有这样的代码片段:
function processOne() { // 省略...local variable declaration // 省略...beginning of try block while(true) { // 省略...element type checking switch(elm.type) { case 'jump': // jump ! { var count=true; count=+elm.countpage if elm.countpage!==void; process(elm.storage, elm.target, elm.countpage, true, true); return; } case 'call': // call processCall(elm); return; case 'return': // return { var count=true; count=+elm.countpage if elm.countpage!==void; processReturn(elm.storage, elm.target, count); chTimer.interval = 1; nextResetChTimer = true; return; } case 'image': // image ! case 'img': loadLayerImage(elm); break; // 省略...a few tags case 'eval': // evaluate ! parseExpression(elm.exp); break; // 省略...rest of the switch } // end of switch } // end of while // 省略...error handling } // end of function
于是可以很明确的看出,吉里吉里1中的KAG系统的执行核心是一个switch dispatch loop,KAG脚本由TJS解释执行;而用于实现KAG系统的TJS又由底层的吉里吉里1本体解释执行。我手上没有吉里吉里1核心部分的源代码,不太清楚当时TJS是如何被解释的,不过想来其执行效率肯定没有现在的TJS2高;可以想像当时的KAG系统与现在相比肯定是慢很多。
进入到吉里吉里2时期后,为了解决KAG系统的性能问题,其核心解释执行部分被移动到了吉里吉里2本体中,以C++代码实现。
吉里吉里2的源代码中,
\kirikiri2\src\core\utils\KAGParser.h
\kirikiri2\src\core\utils\KAGParser.cpp
这两个文件定义了TJS2中可以使用的KAGParser这个native class。但在这对C++源代码里却找不到KAG系统里用到的tag。它们跑哪里去了呢?
在原版KAG系统(2.28稳定版)中,\system\MainWindow.tjs/4551行,
或者在KAGEX(同样在2.28稳定版)中,\system\MainWindow.tjs/5770行,
function getHandlers() { return %[ // 关联数组对象 /* 处理函数数组是名字/函数对的枚举,以 函数名 : function(elm) { // 函数内容 } incontextof this, 的格式来表示。但是,如果函数名是保留字, 则不使用“函数名 : ”而使用“"函数名" => ”为开头。 为了让函数正确使用这个类为上下文运行, incontextof this是必要的。 */ //--------------------------------------- 处理函数数组群(消息操作) -- // 省略...部分tag endline : function(elm) { // 改行模式在一行末尾调用的处理 return 0; } incontextof this, dispname : function(elm) { if (elm !== void) { var name = elm.disp !== void ? elm.disp : elm.name; if (name !== void) { return tagHandlers.origch(%["text" => "【" + elm.name + "】"]); } } return 0; } incontextof this, // 省略...部分tag //--------------------------------------- 处理函数数组群(变量、TJS操作) -- eval : function(elm) { // 计算表达式 Scripts.eval(elm.exp); return 0; } incontextof this, // 省略...剩余tag //----------------------------------------------- 处理函数数组结束 -- interrupt : function(elm) { return -2; } incontextof this ]; } // end of function
这里,MainWindow内定义了一个函数,用于获取一个关联数组,这个数组里元素是tag名与其对应的处理函数。在构造MainWindow对象时,这个关联数组会被作为参数用于构造一个Conductor对象。注意到,Conductor类继承于BaseConductor类,而BaseConductor类继承于上面提到的KAGParser。
在原版KAG系统(2.28稳定版)中,\system\Conductor.tjs/433行,
或者在KAGEX(同样在2.28稳定版)中,在\system\Conductor.tjs/441行,
function onTag(elm) { // tag的处理 var tagname = elm.tagname; var handler = handlers[tagname]; if(handler !== void) { var ret = handler(elm); lastTagName = tagname; return ret; } return onUnknownTag(tagname, elm); }
这样就可以知道,吉里吉里2中KAG系统有部分的核心被移动到了吉里吉里2本体中以提高运行效率,而具体与tag对应的操作依旧以TJS2实现。
由于吉里吉里2中的关联数组实现比吉里吉里1中的更高效,并且在tag的处理上以table-driven的方式替代了吉里吉里1中的大switch语句,运行起来应该是更快的。但其本质并没有改变:每个KAG脚本中的tag都是一个对TJS定义的函数的调用。
要在KAG脚本里实现相同的(复杂)功能,一般有两种选择:1、以iscript块嵌入TJS脚本,并将其注册为一个插件;或者直接把一些KAG tag组合在一起写成一个macro。从上面的分析应该能看到,使用嵌入的iscript将比简单的使用macro有更精确的控制,因而也确实会更加有效。
如果感到在KAG系统有什么功能会经常被用到,但原本的KAG系统并没有提供,也有另外一种方法来修改:直接在MainWindow.tjs的getHandlers()函数里添加需要的tag与其对应的处理函数。这又比在KAG脚本中嵌入iscript快要更直接,代价是对KAG系统有侵入性。
======================================================================
回到前面提到的,嵌入在KAG脚本中的iscript块的执行问题,在吉里吉里2中有这样的代码片段:
\kirikiri2\src\core\utils\KAGParser.cpp/1070行: bool tTJSNI_KAGParser::SkipCommentOrLabel()中
if(p[0] == TJS_W('[') && (!TJS_strcmp(p, TJS_W("[iscript]")) || !TJS_strcmp(p, TJS_W("[iscript]\\")) )|| p[0] == TJS_W('@') && (!TJS_strcmp(p, TJS_W("@iscript")) ) ) { // inline TJS script if(RecordingMacro) TVPThrowExceptionMessage(TVPLabelOrScriptInMacro); ttstr script; CurLine++; tjs_int script_start = CurLine; for(;CurLine < LineCount; CurLine++) { p = Lines[CurLine].Start; if(p[0] == TJS_W('[') && (!TJS_strcmp(p, TJS_W("[endscript]")) || !TJS_strcmp(p, TJS_W("[endscript]\\")) )|| p[0] == TJS_W('@') && (!TJS_strcmp(p, TJS_W("@endscript")) ) ) { break; } if(ExcludeLevel == -1) { script += p; script += TJS_W("\r\n"); } } if(CurLine == LineCount) TVPThrowExceptionMessage(TVPKAGInlineScriptNotEnd); // fire onScript callback event if(ExcludeLevel == -1) { if(Owner) { tTJSVariant param[3] = {script, StorageShortName, script_start}; tTJSVariant *pparam[3] = { param, param+1, param+2 }; static ttstr onScript_name(TJSMapGlobalStringMap(TJS_W("onScript"))); Owner->FuncCall(0, onScript_name.c_str(), onScript_name.GetHint(), NULL, 3, pparam, Owner); } } continue; }
可以看到,iscript块的执行其实与TJS2普通的全局脚本一样,是直接通过TJS2 VM来完成而没有太多经过别的处理。从这点看,无论是普通的TJS2代码还是嵌入在KAG脚本中的TJS2代码,在执行效率上都应该差不多。
发表评论
-
habakiri / kirikirij notes
2013-01-19 01:36 0编译startup.tjs时的stack trace: Thr ... -
自己关于VM的帖的目录
2009-04-07 14:02 69495JavaEye的blog系统只允许把帖放到单一类别下,而不能用 ... -
吉里吉里2 2.30版正式发布了
2008-09-16 03:10 16690这应该是不到两个小时之前才发生的事吧……嗯应该还算是新闻。 ... -
使用Dictionary保存数据的功能在引擎里的内部实现
2008-05-09 19:51 3192有时候我们希望能够在存档文件里保存些结构化的数据,而不只是简单 ... -
吉里吉里2相关的一些引用资料
2008-02-20 17:15 4160[後知後覺]吉里吉里與KAG引擎與Fate/StayNight ... -
吉里吉里2 2.28 rev3发布
2008-01-23 17:41 36102008/01/22 引用レイヤの重ね合わせ方によってはまれに ... -
[笔记] 关于KAG3中宏参数的类型
2008-01-07 20:03 2131[macro name=addFiveZero] [eval ... -
吉里吉里3观察记录(2008-01-05 3523)
2008-01-05 19:27 2694其实应该是到2008-01-03的3511,不过我机上是更新到 ... -
把吉里吉里3 revision 3419中Risse的部分build了出来测试
2007-11-16 16:36 3676把吉里吉里3 revision 3419中Risse的部分bu ... -
KAGEX revision 3614更新
2007-11-14 12:45 1996今天刚出现的更新: 最 ... -
TJS2中对象的表示方法,其代表的运行时环境,与闭包的关系
2007-11-03 09:30 3119对一个对象实例调用(string)转换时,可能会看到这样的结果 ... -
吉里吉里2中TJS2 VM的dispatch loop
2007-10-29 15:03 4806稍微在吉里吉里2.28的源代码里找了下TJS2 VM的执行机制 ...
相关推荐
《krkr 吉里吉里 中文版》是一款由日本开发者W.Dee设计的高级文本冒险游戏(恋爱AVG)制作引擎,名为KRKR或KAG3。这款工具以其强大的功能和可扩展性在游戏制作社区中备受青睐,使得创作者能够轻松地构建具有丰富剧情...
吉里吉里2安卓手机模拟器.apk
吉里吉里XP3提取工具安卓版android-实用工具
这两款引擎在游戏开发者中非常流行,主要用于创建文字冒险类游戏,具有丰富的脚本系统和图形用户界面。 吉里吉里(KRIKRIRI,也称为Krkr2)是一个开源的游戏开发工具,特别适合制作 AVG 游戏。它提供了强大的脚本...
吉里吉里SDL2 吉里吉里SDL2は,macOSやLinuxなど, をサポートするプラットフォームで実行できるの移植版です。 変のプログラムは,KAG(吉里吉里アドベンドベーチャーム)3の変更バージョンと共に使用できます。...
吉里吉里[きりきり] 2 実行コア/2.25.11.909 (SVN revision:1109; Compiled on Sep 12 2005 22:44:16) TJS2/2.4.19 Copyright (C) 1997-2005 W.Dee and contributors All rights reserved. 12:48:07 ! バージョン情...
吉里吉里最新版.apk
85709703768437z安卓吉里kr模拟器!!!!!!!!.apk
.xp3文件是吉里吉里引擎的一种归档文件格式,它将各种资源如图片、音频、脚本等整合在一起,形成一个单一的可执行文件。这样的设计有利于减少加载时间,保护版权,并简化项目管理。Kikiriki工具就是针对这种文件格式...
MT管理器(安卓手机下载).apk
这种格式通常包含游戏的资源,如音频、图像、脚本和其他重要文件,为了减小存储空间并提高加载速度,将所有这些资源集中在一个单一的文件中。"XP3文件解包工具"是为了帮助用户访问和提取这些打包文件中的内容而设计...
【压缩包子文件的文件名称列表】:“Yangi-Davr--main”可能是项目的核心文件或者启动文件,通常在软件开发中,“main”代表主函数或主要入口点,是程序执行的起点。这可能是一个源代码文件,用于启动或管理整个...
在IT行业中,游戏开发是一个非常活跃的领域,而krkr引擎(又称吉里吉里)是其中一款广泛应用的游戏制作工具,特别适合制作2D视觉小说和小型RPG游戏。本示例将详细介绍如何使用krkr引擎实现一个滚动式的存档界面。 ...
它基于吉里吉里2(KiriKiri2)和Kirikiri Adventure Game 3这两款强大的游戏引擎,旨在降低游戏开发门槛,让创作者能更加便捷地实现自己的创意。 首先,我们来了解一下KAGeXpress的核心特点。作为一款AVG游戏制作...
【吉里奇】,在IT领域中,"吉里奇"可能是指一款名为Jirachi的软件或技术,但没有足够的上下文来确认其具体含义。不过,由于标签指定为"CSS",我们可以推测这里可能是指一个与CSS(层叠样式表)相关的项目或工具,...
KrkrExtractA tool can extract and pack krkr2 and krkrz's xp3 files (32Bit & 64Bit)Beta Version Warning!!download pre-release binaries from release pageDO NOT USE v5 now中文说明我平时很忙,本工程开源...
xp sp3补丁,sp2升为sp3补丁下载。如果使用360安全卫士的话,也可以直接下载安装最好,打开修复漏洞界面,在功能性补丁里可以找到这个补丁,选择下载即可,不过速度慢了点。对速度有要求的,可以直接下载xp sp3补丁...
出于效率考虑,LGame中所有组件都不依赖于Swing,而是基于AWT独立绘制成型,因此它可以将自身的运行环境压缩到最小,一个压缩后不足4MB的精简JRE,已足够支持它的运行,也就是与RMXP或吉里吉里2的运行库大小相仿佛,...
Econometrics-USU-SP21:教授拥有的Github计量经济学存储库。 贾汉吉里
内含xp3拆包工具、操作说明,适用于非专业人士