Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 

 Home / General Programming / Question RE scripting engine Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Joe

May 10, 1999, 11:14 AM

The tutorial on flipcode re:
Implementing a Scripting Engine was good. But I do have one question.
How does the script parser prevent blocking the main engine when poor script code
blocks?
Does each VM have its own thread? Is there one thread (seperate from the engine) for all VM instances? What's the deal? 8-)
Thanks.
Joe
joehall at mindspring dot com

 
Jan

May 10, 1999, 01:10 PM

Joe wrote:
>>The tutorial on flipcode re:
>>Implementing a Scripting Engine was good.

Thanks.. there's lots more to come!

>>How does the script parser prevent blocking the main engine when poor script code
>>blocks?

First, the parser usually cannot detect this; if we can detect lockups at all we
can only do this while executing the VM code. Even then, it's very hard. You could
maybe have a special debug mode in which the virtual machine checks how long it
stays in a certain block of code and stops execution when it thinks it's 'stuck'..

I won't be covering this sort of thing in this tutorial series though; I'm just
trying to create a simple scripting engine so everyone can get started without
worrying about these complications. But maybe later.

>>Does each VM have its own thread? Is there one thread (seperate from the engine)
for all VM instances? What's the deal? 8-)

Letting every game object have its own thread is definitely not feasible, since you
might have over a thousand objects and all the thread switching would take up way
too much processor time. Instead, we simulate threading ourselves.

Putting the VM instances in a separate thread would be useful to keep a steady framerate
if you have relatively long-running scripts that are only occasionally executed. It
would also allow the engine to keep running if the script code blocks, so the user could
just load or exit instead of having to reset.

A problem arises when the rendering engine is updating the screen while the script engine
is, for example, updating actor positions. So, you should probably give the renderer a
separate copy of actor positions and update this copy just before rendering a new frame
(temporarily freezing the scripting engine).

Note however that I do not have any experience with this threading scheme; I don't know
if Unreal used this form of threading. Does anyone else know this?

I hope this answers your questions. If you have any more, just send them my way.

Jan Niestadt.

 
Henry Robinson

May 14, 1999, 08:17 AM


re Unreal's Scripting System

I remember reading on the unreal technology page that unreal simulates threads internally for all its game objects. I think that while threads are so damn expensive then you have to rely on the scripting code to execute quickly in order to give the engine space to breathe. The best way to do this is to write your script as functions that are almost always idle. You can try and get clever and have your VM retain a code pointer which it returns to every time it gets the chance to execute some code, but this complicates all sorts of matters about data synchronisation and is not worth the hassle in my opinion. Just make sure your code executes quickly enough.

H.

 
Conor Stokes (aKa DirtyPunk)

May 15, 1999, 09:56 AM



Henry Robinson wrote:
>>
>>re Unreal's Scripting System
>>
>>I remember reading on the unreal technology page that unreal simulates threads internally for all its game objects. I think that while threads are so damn expensive then you have to rely on the scripting code to execute quickly in order to give the engine space to breathe. The best way to do this is to write your script as functions that are almost always idle. You can try and get clever and have your VM retain a code pointer which it returns to every time it gets the chance to execute some code, but this complicates all sorts of matters about data synchronisation and is not worth the hassle in my opinion. Just make sure your code executes quickly enough.
>>
>>H.
Aghh, well I guess the way I am going to be doing it is having an enternal update loop
that is called every frame. So the engine simply goes through and does the internal loops.
Using a simple assembler sytle system, code is pretty easy to generate, and normally
I only need to perform two stage compilation. Which is simply, convert variables to
offsets of my heaps, which is the first pass, and on the second convert the whole thing
to byte code. I am designing a syntax which should be very easy to use, and perform game
operations quickly (you could also use a facility to convert C, Pascal or Basic code into the
asm form rather easily. Maybe a re-targetable compiler like lcc, or a lex utility.

Conor Stokes


 
This thread contains 4 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.