Gan's Runtime & Script Interpreter

[GMG Mike]

Gan - sorry for being so cross on AIM. Been having a rough time lately.

[x]

SilverCreator already does this. The SCScript object has Import and Export methods. All of the constants, and the big parameter lookup table are also written to the runtime (compiled game). SilverCreator compiled games contain no human readable scripting. The only thing you'd recognize would be the string constants, all clumped together towards the end of the runtime data file.

When the game is started it reads all of this back into the appropriate SCScripts, SCMathExpressions, SCParameters, etc. in the exact same order and your game runs. That is why it is not possible to have an Eval function in SilverCreator anymore.

Is that how you coded the SilverBASIC compiler back in the day too (if you don't mind my asking)?

[GMG Mike]

Is that how you coded the SilverBASIC compiler back in the day too (if you don't mind my asking)?

No. SilverBASIC was strictly interpreted. Some kind of simple encryption was applied to the script, and it was stored in the resource fork.

[GabrielCA]

@Gan good.

Of course, modern scripting languages are compiled to bytecode, like the SilverCreator of today.

Someone mentioned METAL, a BASIC I like, although people sometimes say it's "old" because the last version dates to 2001.
METAL compiles programs to an internal bytecode system, and outputs bytecode assembly listings using a special option.
This:

Code: [Select]

x = 1 + 1
if x > 0 then
   print x
endif

Gives this:

Code: [Select]

*       0 <  0> [  0]: NumTokenAddr 0
*       c <  0> [  1]: NumConst 1.000000
*      18 <  0> [  2]: NumConst 1.000000
*      24 <  0> [  3]: AddNum
*      28 <  0> [  4]: AsnNum
*      2c <  1> [  5]: NumToken 0
*      38 <  1> [  6]: NumConst 0.000000
*      44 <  1> [  7]: LGreaNum
*      48 <  1> [  8]: BranFalse 4
*      54 <  2> [  9]: KeyWPS
*      58 <  2> [ 10]: NumToken 0
*      64 <  2> [ 11]: IPAddP3
*      68 <  2> [ 12]: KeyW 1
*      74 <  2> [ 13]: NOP

Clearly, a stack is involved, and it seems everything is floating-point by default.

Also note that METAL has an "accept tokens with space" option. This allows variable names to contain spaces (!), so that the above can be written:

Code: [Select]

my variable = 1 + 1
if my variable > 0 then
   print my variable
endif

[Gan]

Gan's Runtime & Script Interpreter Graphics Drawing Video

Very large and exciting update here. I've added a whole bunch of commands, fixed boat loads of bugs, tested a plenty, rewired the runtime to work more like a game maker, added drawing abilities, and have tasted the best pie on Earth.

I just gotta say, that pie was delicious.

Command List

• Print(text) - Prints text
• Str$(number) - Turns a number to a string
• Ticks - Gets the amount of ticks since program opened
• Key - Returns the ascii value of the last key pressed or depressed
• LoadImage(Image Name, Identification name) - Loads an image from outside.
• CreateSprite(Identification Name) - Makes a sprite from a loaded image, returns sprite num
• MoveSprite(SpriteNum, X, Y) - Moves a sprite
• SpriteX(SpriteNum) - Gets X position of a sprite
• SpriteY(SpriteNum) - Gets Y position of a sprite
• KeyIsPressed(Ascii Value of Key) - Determines if that key is pressed, returns True or false
• KeyUp - Returns ascii value for the up arrow key
• KeyDown - Returns ascii value for the down arrow key
• KeyLeft - Returns ascii value for the left arrow key
• KeyRight - Returns ascii value for the right arrow key

Here's the download of the runtime if you want to test:
Gan's Runtime Demo

@Mike
No worries. Hope things get better.

@GabrielCA
That's very unique.


I think I need to add in comment support and basic debugging. I also need to go through and clean and optimize. Also need to redo the command system. Cause when I add a command, I gotta add it to 3 different spots in the code, just kinda annoying.

So far it redraws the screen at 60 fps using quartz. If I bumped it up to using OpenGl I bet it could support a crap load of sprites on the screen.


What are your thoughts?

Edit: Images!

[Gan]

Made another little demo. Just of a graphic bouncing around the screen:
Gan's Runtime Bouncing Graphic

Here's the code:
Startup

Code: [Select]

LoadImage("guy.png","guy")
guy=CreateSprite("guy")

speed = 60
xvel = speed
yvel = speed

Timer

Code: [Select]

MoveSprite(guy, spritex(guy)+xvel,spritey(guy)+yvel)
If spritex(guy) > 440-45 Then

xvel = -speed
End If
If spritey(guy) > 403-45 Then

yvel = -speed
End If
If spritex(guy) < 0 Then

xvel = speed
End If
If spritey(guy) < 0 Then

yvel = speed
End If

Just realized I forgot to program in an Else for the IF-statements. Also might program an Else-If statement. If it's not too complicated.
Also thinking of arrays. Arrays would be nice. Not quite sure how I'd set it up...
Probably just like variables, to make one:

Code: [Select]

myArray = NewArray(object1,object2,object3)

Then to get or set:

Code: [Select]

myArray[1] = 5
or
var1 = myArray[1]

Then to add an object:

Code: [Select]

AddObject(myArray, myObject)

Then to remove an object:

Code: [Select]

RemoveObject(myArray, IndexOfObject)

Ideas... ideas.

[x]

Made another little demo. Just of a graphic bouncing around the screen:
Gan's Runtime Bouncing Graphic

Here's the code:
Startup

Code: [Select]

LoadImage("guy.png","guy")
guy=CreateSprite("guy")

speed = 60
xvel = speed
yvel = speed

Timer

Code: [Select]

MoveSprite(guy, spritex(guy)+xvel,spritey(guy)+yvel)
If spritex(guy) > 440-45 Then

xvel = -speed
End If
If spritey(guy) > 403-45 Then

yvel = -speed
End If
If spritex(guy) < 0 Then

xvel = speed
End If
If spritey(guy) < 0 Then

yvel = speed
End If

Just realized I forgot to program in an Else for the IF-statements. Also might program an Else-If statement. If it's not too complicated.
Also thinking of arrays. Arrays would be nice. Not quite sure how I'd set it up...
Probably just like variables, to make one:

Code: [Select]

myArray = NewArray(object1,object2,object3)

Then to get or set:

Code: [Select]

myArray[1] = 5
or
var1 = myArray[1]

Then to add an object:

Code: [Select]

AddObject(myArray, myObject)

Then to remove an object:

Code: [Select]

RemoveObject(myArray, IndexOfObject)

Ideas... ideas.

The way your implementing the array looks like a linked list, not an array. Arrays by definition can't have objects added past their limit. An unbounded array would either by a Dynamic array, or a linked list, although a dynamic array is usually just a linked list of arrays anyway.

Why don't you just do it the way its meant to be done, and also the way its most efficient. Creating a new array creates a block of memory X units long where is is as follows: myArray = Array[X]
Then you add, remove, modify using any index between 0 and X.
myArray[2] = 10
myArray[0] = 0
etc.
Since Objective-C is a superset of C you would have no trouble hard coding it. Just clear out a block of memory objectType*X wide, and store a pointer to the beginning. When they access something using the index access the block objectType*index bytes along. Thats how its done in just about every language.

[Gan]

I suppose. Though a mutable array sounds quite a bit more user friendly.

[x]

I suppose. Though a mutable array sounds quite a bit more user friendly.

If its mutable, its not an array.

What you are talking about is a linked list, or a dynamic array like C++'s vector class.

[GMG Mike]

If its mutable, its not an array.

What you are talking about is a linked list, or a dynamic array like C++'s vector class.

REALbasic's Arrays are mutable. SilverCreator's Arrays are based directly off REALbasic's.

Maybe it's really technically a dynamic array or a linked list or whatever. SilverCreator users don't care and shouldn't have to.

[x]

REALbasic's Arrays are mutable. SilverCreator's Arrays are based directly off REALbasic's.

Maybe it's really technically a dynamic array or a linked list or whatever. SilverCreator users don't care and shouldn't have to.

Yes, REALbasic's Arrays are dynamic arrays, almost exactly the same as a C++ vector. I personally think having a normal fixed array is better (if you are calling it an array) - but thats just me obviously. It sure does make it easier for newbies to have dynamic arrays, which is an excellent point Mike. Please understand I wasn't saying don't use them, I was just saying I'm not sold on the name  

[GMG Mike]

ExecuteScript method in SilverCreator is faster when you comment out support for SELECT CASE and IF... END IF, even though the standard speed test script uses neither of these.

In other words - commenting out code that is never executed  (but could possibly be executed) somehow speeds up execution overall.

I have only a very basic knowledge of how compilers work. I know registers are involved somehow. Commenting out those lines greatly reduces the number of variables used in the method. Would this allow registers to be used more efficiently somehow?

After reading a bit more about how stacks work - REALbasic uses stacks. When you call another method, the current method's variables are dumped to the stack. When the other method concludes, the variables have to be loaded back. Therefore - it's not really that the method call is so expensive, but it's all the stack dumping and reloading. When you have a FOR loop, it calls ExecuteScript over and over again - lots of stack dumping and loading, over and over again. And right now I'm forming several ideas - how we could reduce or eliminate these method calls, and therefore all of this costly stack manipulation.

[GMG Mike]

I don't think my theory about the stack pans out.

I replaced the repetitive call to ExecuteScript in the FOR loop handler with a method named "Twiddle" which manipulated some variables of no consequence and returns nil (ExecuteScript returns a variant, in order to handle user functions). This method call should be causing variables to be dumped and reloaded from the stack, but still takes into account any delays caused by that variant/nil return, etc. Calling Twiddle 1,000,000 times in this manner only took 16 ticks. Regular time is 199 ticks.

This means that this (theoretical) stack manipulation is of little consequence to our speed problem.

[GMG Mike]

OK, Twiddle wasn't accurate enough. I needed to pass a string (script location) and a graphics object (always Nil unless we're in the Paint event). Even with these, and the manipulation of the string in Twiddle the increase in time is inconsequential.

But now here's the big news. If I add more code to Twiddle it gets slower even though i'm just pasting the same two lines over and over again without using any new variables!

Code: [Select]

Function Twiddle(farts as uint32, g as Graphics, location as string) As variant
 Â dim q As  Integer
 Â dim previousloc as string
 Â previousloc=scriptlocation
 Â scriptlocation=location
 Â q = WasteTime + farts
 Â WasteTime = q - 1
 Â WasteTime = q + 1
 Â [REPEAT THE ABOVE TWO LINES SOME NUMBER OF TIMES IN THE CODE]
 Â ScriptLocation=previousloc
 Â return nil
End Function

If I just copy and paste those two lines a few more times the method gets slower, but we're only calling it 1,000,000 times total and I'm using a Mac Pro!

So for some reason calling a method is slow but only when the method has more and more code??? Even if the code is doing piss all and should be no problem for a Mac Pro???

Nope this isn't directly correct either and now I'm confused as hell.

nevermind that, sleep deprivation, ran one test in RB Debugger instead of real compiled app

so I haven't figured out SHlT, pretty much

[x]

Could be an inefficiency in the way REALbasic maps methods to the stack/heap/however it organizes it. C is know for being monstrously efficient at that sort of thing, and Objective-C is a superset of C.