Sign in to follow this  

Script library issues.

This topic is 4819 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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..

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

This topic is 4819 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this