Script library issues.
Author
Hi,all,
I have implemented a small script system composed of a compiler and a virtual machine, and it works pretty well. However, this toy system only allows the user to call predefined script functions or user-defined script functions, how can I improve it so that it can support 3rd party functions? For example, like tcl supports OpenGL, I would like that the user can write some OpenGL functions in the script, and my compiler compiles those into vm code, and then my vm calls corresponding OpenGL functions in turn. I guess the vm needs to do some low-level job to feed the arguments for the OpenGL functions. Can anybody explain a bit on this topic?
Thanks a lot.
Your engine would need to be designed in such a way that it acts as a standard programming language, that it, for example, gets compiled into actual Machine code, and gets executed as it were machine code by the VM. So, the VM would only have the job of emulating the Machine code for other processors.
Anyways, if you have a scripting language of this kind of level (i guess the lowest possible), you could declare OpenGL calls from within your Scripts as Assembly function calls. So each time a user writes some OpenGL code inside your Scripting language, it gets replaced during compile process with a jump to the actual OpenGL library files :)
You'd need to do some research on Assembly and the location of the OpenGL libraries inside your Memory after loading, etc..
Anyways, if you have a scripting language of this kind of level (i guess the lowest possible), you could declare OpenGL calls from within your Scripts as Assembly function calls. So each time a user writes some OpenGL code inside your Scripting language, it gets replaced during compile process with a jump to the actual OpenGL library files :)
You'd need to do some research on Assembly and the location of the OpenGL libraries inside your Memory after loading, etc..
Or as a simpler (and slower) alternative you could write your own wrapper binding code for the OpenGL functions you'll need. The wrapper would deal with translating the function calls and parameters to and from the scripting machine to OGL.
Author
Thanks for your guys. I think both of your ideas work, but I prefer to the wrapper function method. Here is a link I found from the web discussing the wrapper one:
http://www.swig.org/Doc1.3/Scripting.html
http://www.swig.org/Doc1.3/Scripting.html
You probably wouldn't want to implement to the whole OGL API, more like write some functions to perform specific actions. For example, you wouldn't want to implement the calls to create a window in steps, a reasonable assumption would be to export a "CreateWindow" function to cover the whole process of window creation. Not only does it make your application faster (the more you do in native code, the quicker it'll be) but it allows you to sandbox things to prevent your users from breaking things.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
