Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
DYNSCRIPT?
Posts
Pages:
1
Rave
View playlists
CloseCould someone write DynRPG plugin that would expose whole DynRPG API to some easier than c++ (so literally anything besides c/c++) language, maybe scripting one like Lua? This way it would be easier to write things and you could test changes without recompiling plugin.
Kazesui
5797
I don't recall exactly where I read it, but if I recall correctly, Cherry stated that it wasn't feasible due to performance issues.
"Wasn't possible due to performance issues" is often synonym to "I was lazy, so I didn't took my time to optimize it correctly". Scripting in VX/VXAce is very fast, so it can be done about as fast in 2k3 via DynRPG scripting plugin, if one would be written.
Of course it won't be as fast as native RPG_RT, DynRPG isn't as fast as original RPG_RT either, but then again - hardware from 2000/2003 on which RM2k/2k3 was supposed to run, isn't around anymore, is it?
Of course it won't be as fast as native RPG_RT, DynRPG isn't as fast as original RPG_RT either, but then again - hardware from 2000/2003 on which RM2k/2k3 was supposed to run, isn't around anymore, is it?
Actually, one of my very early creations was the so-called "Power Patch", which allowed very limited scripting using Lua.
Later I started creating CGSS (http://cherrytree.at/cgss) which is actually something like DynRPG, but using Lua. I stopped it in a very early stage though (you can download a demo on my page) because I noticed that the performance was terrible. And even with optimizations (which would have made the system less transparent, on the other hand) it would never have been worth the effort because most "exciting" things would just slow down everything so much that it wouldn't have any real-world usage.
That's partly to poor design of the RPG Maker system itself and partly due to all the marshalling which is necessary to interface Lua with the RPG Maker, mostly when callbacks come into play (and be honest - without callbacks, DynRPG would be far less powerful!).
The fact that DynRPG uses compiled C++ allows for much better results. Firstly because it's using compiled code, no interpreting is needed there. Secondly because accessing the RPG Maker system is mostly "direct". For example, writing RPG::system->scene = RPG::SCENE_MENU; produces about the same machine code as if the RPG Maker would do the same thing natively! That's because the DynRPG classes have been designed in a way that their memory layout matches the layout of the internal classes of the RPG Maker so that the C++ compiler can generate the optimal code. Even most method calls (like RPG::Character::move, for example) are only very thin wrappers around the corresponding interal functions of the RPG Maker, mostly in order to translate C++'s calling convention (using stack only) to Delphi's (using the eax, edx and ecx registers), so that the overhead is minimal. This means that DynRPG code is at least 90% as fast as the native code of the RPG Maker.
This also means that exposing the full DynRPG API via Lua or Ruby or anything else would probably need many times more effort than creating DynRPG itself needed! It's like building an adapter cable for DVI>HDMI versus building an active converter for VGA>HDMI. The first one just needs the right wiring and the right plugs (and doesn't need any actual curcuitry apart from the connections), while the second one is a complex device which needs to actually "translate" an analog signal to a digital one!
Later I started creating CGSS (http://cherrytree.at/cgss) which is actually something like DynRPG, but using Lua. I stopped it in a very early stage though (you can download a demo on my page) because I noticed that the performance was terrible. And even with optimizations (which would have made the system less transparent, on the other hand) it would never have been worth the effort because most "exciting" things would just slow down everything so much that it wouldn't have any real-world usage.
That's partly to poor design of the RPG Maker system itself and partly due to all the marshalling which is necessary to interface Lua with the RPG Maker, mostly when callbacks come into play (and be honest - without callbacks, DynRPG would be far less powerful!).
The fact that DynRPG uses compiled C++ allows for much better results. Firstly because it's using compiled code, no interpreting is needed there. Secondly because accessing the RPG Maker system is mostly "direct". For example, writing RPG::system->scene = RPG::SCENE_MENU; produces about the same machine code as if the RPG Maker would do the same thing natively! That's because the DynRPG classes have been designed in a way that their memory layout matches the layout of the internal classes of the RPG Maker so that the C++ compiler can generate the optimal code. Even most method calls (like RPG::Character::move, for example) are only very thin wrappers around the corresponding interal functions of the RPG Maker, mostly in order to translate C++'s calling convention (using stack only) to Delphi's (using the eax, edx and ecx registers), so that the overhead is minimal. This means that DynRPG code is at least 90% as fast as the native code of the RPG Maker.
This also means that exposing the full DynRPG API via Lua or Ruby or anything else would probably need many times more effort than creating DynRPG itself needed! It's like building an adapter cable for DVI>HDMI versus building an active converter for VGA>HDMI. The first one just needs the right wiring and the right plugs (and doesn't need any actual curcuitry apart from the connections), while the second one is a complex device which needs to actually "translate" an analog signal to a digital one!
Pages:
1
