Game Maker's Garage Forum

Game Maker's Garage => Announcements => Topic started by: Gan on March 13, 2011, 01:53:53 PM

Title: Gan's Runtime & Script Interpreter
Post by: Gan on March 13, 2011, 01:53:53 PM
Version 2:
Runtime Download (http://cl.ly/3H3o3o2M1p0I0S2K3W3x)
Videos:
Demo Video - 14 min long (http://www.youtube.com/watch?v=g4a4oHXweL0)
Graphic Bouncing demo (http://www.youtube.com/watch?v=adJQMprjTEI)
Command ListMini manual:
Making Variables
Code: [Select]
//Either form can be use
Let x = 1
or
x = 1

Let x$ = "test"
or
x$ = "test"
Variable Equations
Code: [Select]
//+=, -=, *=, and /= are supported
x = x + 5
or
x += 5
Complex Equations
Code: [Select]
//Complex equations are handled with ease.
x = (5 * (3 + 1) / 6 * 18) - 3
If Statement
Code: [Select]
//If statements and nested if statements work well.
If  x < 5 Then
x+=1
End If
For Statement
Code: [Select]
//For and nested for statements work.
For i = 1 to 5
x+=1
next


Version 1:
Quote
Gan's Runtime Video Demo (http://www.youtube.com/watch?v=qKZPKYQgnSE)

Hey guys, this is my top secret incredibly confidential my-eyes-only project.
Started this last weekend, spent 2 days thinking about it, 1 night dreaming about it, and 2 days making it. Then I procrastinated all week long.
Finally this weekend I got it into a useable state.

Yeah I cloned the Sc language. Mainly cause of people's familiarity with it.
So how about some details of this runtime:
  • Supports number and string variables
  • Can do complex equations of both strings and numbers. Especially with lots of parenthesis
  • Supports if statements that can also do complex equations and compare strings and numbers
  • Allows the use of AND and OR in if statements
  • Isn't case sensitive. You can write things in all caps if you want
  • So far two commands work. STR$(5) which makes "5" and print("test") which outputs text
  • If statement clusters work perfectly

How it works:
Three main things. The first is the parser.
It takes the code as a string, separates it into smart keywords, cleans out unnecessary stuff, lowercases the code, then compares each keyword string and attaches an identifier number to it.
Then there's the runtime.
The smart keywords go straight to the runtime that goes line by line running stuff. To detect what it's suppose to do, it looks at the number identifiers. It doesn't use any unreliable slow string comparisons when running code.
Finally, probably the most important part is the solver. When the runtime comes upon something that needs solved, it sends those keywords to the solver. The solver will go through, solve parenthesis, */+-, true/false equations, commands, and anything that gets in it's way. It was the hardest thing to make and is just like a large calculator. It can handle numbers, strings, and variables.

Surprisingly this whole thing isn't very large, is fairly readable, and incredibly versatile. Of course, I think there's a lot optimizations and cleaning I can do. Also there isn't any bug detection. If you aren't a perfect coder then the code's not gonna run. Though I think I can add something that'll tell you which line contains a bug.


Now before you guys get certain thoughts, I just gotta say.
I made this cause I thought it would be fun. At the moment I have no plans.
If you guys want I can open source it or something. Otherwise I'll probably just stick it in some folder until I make something that can make use of it.

So what are your thoughts?


EDIT: Pics!
The project in Xcode 4.
(http://cl.ly/1f2G110s090l3e192d1b/Screen_shot_2011-03-09_at_8.19.46_PM.png)
The coding and output window:
(http://cl.ly/3Z303f2m450H3S0m0T0I/Screen_shot_2011-03-13_at_1.55.12_PM.png)
Complex equations!
(http://cl.ly/0d2K0u3K3C1R0i302M2f/Screen_shot_2011-03-13_at_2.00.05_PM.png)
Title: Re: Gan's Runtime & Script Interpreter
Post by: Charlo on March 13, 2011, 02:55:31 PM
Cool!  You could make another GameMaker clone with this as a base (provided you changed some syntax so as to not be a total SC ripoff).   ;D

By the way, whatever happened to Titanium Forge?
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 13, 2011, 03:20:46 PM
Quote
Cool!  You could make another GameMaker clone with this as a base (provided you changed some syntax so as to not be a total SC ripoff).   ;D

By the way, whatever happened to Titanium Forge?
I could make a GM clone but unless it was incredibly fast and had superior features, it'd be useless. I haven't done speed tests yet but I don't know if I could keep interest long enough to make a GM.

Titanium Forge was a game maker made in Java that took your code and put it in a Java app. Had no actual runtime. Was as slow as Java, and I wasn't very happy with it. I don't like Java, especially the IDE Netbeans.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 13, 2011, 09:06:19 PM
Can you send me the code? I'd like to study it. Thanks.

mike (at) silvernetworks (dot) net

Would it work in Xcode 3 or does it use some kind of new language features? I can install Xcode 4 on the laptop I suppose. I want to keep Xcode 3 on the Mac Pro in case I ever decide to use it (because I'd want to support at least 10.5 and PPC. I probably wouldn't support 10.4 because I'd want garbage collection).
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 13, 2011, 09:54:24 PM
Sent.

Should work just fine in Xcode 3. In Xcode 4 it just uses the new LLVM compiler and the more advanced debugging features are nice.
I tried to make this very well memory managed, at the moment I don't have garbage collection enabled.
If you want to keep Xcode 3, recopy the developer folder and name it Developer Xcode 3. Then install Xcode 4.
Thanks for being interested.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 14, 2011, 01:28:25 AM
I'm interested in a speed test. Can you support a ticks function? Just add a bit of code in your variable handler. Then we can run a standardized speed test.

Code: [Select]
LET x = ticks
FOR i = 1 to 100000
   LET q = q + 1
NEXT
PRINT STR$(ticks-x)

Use the latest build of SilverCreator to run the test on your Mac. Do it from a real built program, not the "Run" menu. The standalone runtime is slightly faster (it does not record some information such as line numbers which are used by SC to help you debug). Compile yours as well.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 14, 2011, 12:34:37 PM
Yeah sure.
Ticks are in milliseconds right?
Title: Re: Gan's Runtime & Script Interpreter
Post by: Silverwind on March 15, 2011, 03:36:15 AM
Hehe, remember the last time you, me and TD debated that? I think we were all wrong.

Come to think of it, TD's been even less active than I have lately. I wonder what he's up to...
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 15, 2011, 03:40:22 AM
Quote
Yeah sure.
Ticks are in milliseconds right?


There are 60 ticks to a second.

The "ticks" function as defined by REALbasic (and SilverCreator) returns the number of ticks since the computer was turned on.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GabrielCA on March 17, 2011, 09:33:07 AM
It's great to see someone making a script interpreter.

Does it support operator precedence ?
Did you use known algorithms or "reinvent the wheel" ?
Do you plan to add arrays, while() ?

It would be nice to see the source code (can it be posted here ?)

I've been working on a similar project myself (clown/SDL_clown). It is very fun but after some time I realized it is really best to use known algorithms. To the best of my knowledge, the "science" of making compilers has existed for at least 30 years, and a lot of research has gone into developing efficient algorithms and techniques.

[EDIT] it would be nice if you could make a manual or something that would give a clear list of the script interpreter's features
Title: Re: Gan's Runtime & Script Interpreter
Post by: Connors on March 17, 2011, 11:52:48 AM
Does it have to use LET? I think it looks a bit cleaner and it's easier to type the code without LET. You can just say
x = 8
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 17, 2011, 04:06:27 PM
Quote
There are 60 ticks to a second.
 
The "ticks" function as defined by REALbasic (and SilverCreator) returns the number of ticks since the computer was turned on.
Thanks. I should have ticks and the for loop code in by this weekend.

Quote
Does it support operator precedence ?
Yes. In this order: (), * or /, + or -, < or > or <= or >= or =, And or Or.

Quote
Did you use known algorithms or "reinvent the wheel" ?
I've made it all from scratch.

Quote
Do you plan to add arrays, while() ?
I had no plans to add anything new. Then Mike wanted to do speed tests. So I'll add for statements and the ticks function. Arrays and a while loop wouldn't be hard to add but it's not on my list of todo.

Quote
It would be nice to see the source code (can it be posted here ?)
I'm going to clean, add for loops and the ticks function, then do a speed test first. After that I'll probably post the source up.

Quote
I've been working on a similar project myself (clown/SDL_clown). It is very fun but after some time I realized it is really best to use known algorithms. To the best of my knowledge, the "science" of making compilers has existed for at least 30 years, and a lot of research has gone into developing efficient algorithms and techniques.
Nice, I'd enjoy discussing compiler techniques or even checking out your project.

Quote
[EDIT] it would be nice if you could make a manual or something that would give a clear list of the script interpreter's features
Not much to post. It just supports if statements, making variables and two commands: STR$() and print()
It can also handle complex equations.

Quote
Does it have to use LET? I think it looks a bit cleaner and it's easier to type the code without LET. You can just say
x = 8
At the moment it has to but it would be fairly easy to get rid of the LET. I really only have the LET so it'll resemble Sc's language more.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 20, 2011, 11:03:05 PM
First I'd like to apologize for my lateness.
Fortunately it is still the weekend by a few hours so technically I'm still sorta on time.

Second, I'd like to say that you'll be shocked by the results of the speed test.

Here's the video:
SilverCreator VS Gan's Runtime SPEED TEST (http://www.youtube.com/watch?v=Yhuvn8jk-YY)

So a few details of why I'm so late:
I actually finished adding the for statement and TICKS command Thursday. Without telling any of you guys I did my own speed tests. I was so disappointed by the tests I refused to post them up. So because I set the deadline for the weekend, I spent my time thinking of how to speed up my runtime. I fell asleep with the problem and woke with the solution. Then I started implementing. Took a ton of work, moved and edited a crap load of code. Cleaned a bunch, got rid of unnecessary stuff and did lots of debugging and testing.
Finally it produced these results. I was so happy I nearly screamed and cried with joy. Nearly.

So how bad did my runtime do before?
SilverCreator: 33 ticks
Gan's Runtime: 64 ticks

On more advanced equations:
SilverCreator: 70 ticks
Gan's Runtime: 500 ticks

Yeah, it sucked.

So this whole recode I did to boost performance was essentially just moving a ton of code from the solver into the parser. So all the hard work was handled before any script executed. Therefore making it incredibly faster.

In case you didn't watch the video or just like spoilers, the final results are:
SilverCreator: 33.5
Gan's Runtime: 2.5

My runtime was able to achieve speeds of 10-16 times faster than SilverCreator.
Meaning, my runtime could do a FOR loop 1 million times and still beat Sc if it did a 100,000 FOR loop.

Pretty sweet, eh?

EDIT:
Here's the download:
Gan's Runtime Download (http://cl.ly/22210o101I0H0v1q2Q1J)
Compiled for 10.5-10.6. Sorry if it doesn't work on your machine, haven't spent time testing on various machines.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 20, 2011, 11:17:56 PM
Quote
So this whole recode I did to boost performance was essentially just moving a ton of code from the solver into the parser. So all the hard work was handled before any script executed. Therefore making it incredibly faster.

In case you didn't watch the video or just like spoilers, the final results are:
SilverCreator: 33.5
Gan's Runtime: 2.5

My runtime was able to achieve speeds of 10-16 times faster than SilverCreator.
Meaning, my runtime could do a FOR loop 1 million times and still beat Sc if it did a 100,000 FOR loop.

Pretty sweet, eh?


I deleted the triple posts. I don't know why you did that.

Anyway, it sounds to me like the initial version was more of a straight interpreter (like the old SC) and the new version is pre-interpreted (like the current SC).

Please send me the new source so I can take a look at it. You may have used a better technique than I did.

I'd also like you to run your test again with the runtime compile for 32 bits ONLY. It is well known that 64 bit Intel programs have an advantage over 32 bit Intel programs, due to a greater number of registers. For the fairest comparison, your program should be using 32 bits (or run both tests on a PPC Mac).

Also keep in mind that SilverCreator supports a far greater number of instructions. Your runtime has almost no instructions. Each new instruction supported in the language slows down the execution of each instruction slightly. This is why SilverCreator got massively faster when the old monolithic ExecuteScript function was broken down into numerous sub-functions with each one dealing with a common set of instructions (one for sprite instructions, etc). The compiler was able to optimize each sub-function independently in regards to the use of CPU registers, etc. Even adding instructions to a sub-function causes a small slowdown because it is one additional check somewhere that must be made. I think I tried breaking down the sub-functions even more but found diminishing returns.

Garbage collection also slows down SilverCreator compared to other languages. Objects are used extensively in the pre-interpreted (byte code) representation of scripts. REALbasic wastes some time incrementing and decrementing reference counters. Experiments are planned in the future where some objects may be replaced with simple structs.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 20, 2011, 11:39:08 PM
Quote
I deleted the triple posts. I don't know why you did that.
I was trying to get my post on page 2.  ;D

Quote
Anyway, it sounds to me like the initial version was more of a straight interpreter (like the old SC) and the new version is pre-interpreted (like the current SC).
Yeah.

Quote
Please send me the new source so I can take a look at it. You may have used a better technique than I did.
Sent.

Quote
I'd also like you to run your test again with the runtime compile for 32 bits ONLY. It is well known that 64 bit Intel programs have an advantage over 32 bit Intel programs, due to a greater number of registers. For the fairest comparison, your program should be using 32 bits (or run both tests on a PPC Mac).
http://www.youtube.com/watch?v=glqlORHLbdY
I think that's 32 bit but I'm not use to Xcode 4 at all. May have done completely different compiler settings as well.

Quote
Also keep in mind that SilverCreator supports a far greater number of instructions. Your runtime has almost no instructions. Each new instruction supported in the language slows down the execution of each instruction slightly. This is why SilverCreator got massively faster when the old monolithic ExecuteScript function was broken down into numerous sub-functions with each one dealing with a common set of instructions (one for sprite instructions, etc). The compiler was able to optimize each sub-function independently in regards to the use of CPU registers, etc. Even adding instructions to a sub-function causes a small slowdown because it is one additional check somewhere that must be made. I think I tried breaking down the sub-functions even more but found diminishing returns.
A boat load of new commands could be added to my script interpreter and this speed test would produce the same results. Commands don't influence the speed of equations or the language structure. Though a negligible slow down would occur when calling a command.

Quote
Garbage collection also slows down SilverCreator compared to other languages. Objects are used extensively in the pre-interpreted (byte code) representation of scripts. REALbasic wastes some time incrementing and decrementing reference counters. Experiments are planned in the future where some objects may be replaced with simple structs.
Yeah, that could definitely be costly. I've tried to make my runtime well memory managed and to not allocate resource while running code.
Title: Re: Gan's Runtime & Script Interpreter
Post by: x on March 20, 2011, 11:47:29 PM
Gan, do you use any languages objects?
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 20, 2011, 11:57:01 PM
I'm afraid I don't quite understand that question.

I have around 6 custom classes I've made. Runtime, ParseLine, ParseKeyword, CodeLine, CodeEquation, and Variable. Those are objects. All subclasses of the NSObject.

I'm not really using any code that's proprietary to a single language. I could port this to plain C or C++ I suppose. Would take a little bit of work though.
Title: Re: Gan's Runtime & Script Interpreter
Post by: x on March 21, 2011, 12:10:32 AM
Do you do any lexical analysis? Do you create a token tree and "interpret" from there?

What kind of pre-processing are you doing, or are you parsing raw input?
(these questions go for Mike too, if he wants to answer)


Also, if those are objects, not just static classes, you might have a little trouble porting it to C :p but Im sure you know that.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 21, 2011, 12:14:45 AM
Quote
http://www.youtube.com/watch?v=glqlORHLbdY
I think that's 32 bit but I'm not use to Xcode 4 at all. May have done completely different compiler settings as well.

So it definitely got slower - because of the fewer registers available, but faster.

Quote
A boat load of new commands could be added to my script interpreter and this speed test would produce the same results. Commands don't influence the speed of equations or the language structure. Though a negligible slow down would occur when calling a command.

True function support would probably slow down equations.

Additional commands would most likely slow down the speed test but I still need to look at your code.

REALbasic may have additional unknown speed penalties related to objects or recursive function calling. The key to speeding up the SilverCreator runtime is to work around these speed penalties. Although honestly I think the SC interpreter is not the current bottleneck - the graphics system is.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 21, 2011, 12:28:30 AM
Quote
Do you do any lexical analysis? Do you create a token tree and "interpret" from there?
Oh crap, I gotta pull out the dictionary.
Just a sec...
Lexic...
Aha yes. I have made a function similar. You put in a raw string and it spits out keywords from the string. Like "LET x = 1" would turn into 4 keywords, LET, x, =, 1. Of course they wouldn't be in strings, they'd be the keyword object filled with identifiers and other useful info.

My solver is a tree. The parser splits equations into chunks, linking them and stuff. Until there's only 1 equation object that links to all sorts of other equations. Like a tree. I could draw a picture to show it but I gotta get some sleep. So when the single equation goes through the solver, it sends the message on through and solves the outermost branches of the equation, folding back in until it hits the base of the equation and the equation spits out a final result. Makes it fairly efficient and fast when running code in real time.

Quote
What kind of pre-processing are you doing, or are you parsing raw input?
(these questions go for Mike too, if he wants to answer)
Yeah, raw strings go into the parser which get turned into smart keywords with further get turned into code lines and equations.

Quote
Also, if those are objects, not just static classes, you might have a little trouble porting it to C :p but Im sure you know that.
I had no idea. My knowledge is fairly lopsided.

Quote
So it definitely got slower - because of the fewer registers available, but faster.
Yeah, I think I want to do some tests in Xcode 3 cause I understand how to manipulate the compiler controls and stuff.

Quote
True function support would probably slow down equations.
I'm not sure I understand.

Quote
Additional commands would most likely slow down the speed test but I still need to look at your code.
They wouldn't. Commands are recognized before code runs. If there are no commands inside the for loop, it won't slow it down.

Quote
REALbasic may have additional unknown speed penalties related to objects or recursive function calling. The key to speeding up the SilverCreator runtime is to work around these speed penalties. Although honestly I think the SC interpreter is not the current bottleneck - the graphics system is.
Yeah, I agree.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 21, 2011, 02:37:27 AM
In SilverCreator each script is represented by a SCScript object. SCScript objects consist of 3 arrays of equal length.

commands() as UInt16
linenums() as UInt32
params() as UInt32

For each scripting instruction there will be an entry in all three arrays. Consider this one line script as compiled into our object:

command(0) = 75
linenums(0) = 5
params(0) = 1

Instructions are given numbers. Instruction 2 is string variable assignment (LET, when allocating a value to a string). Assigning a value to a number variable is Instruction 75. Which instruction to use for a LET command is determined by the line parser (which is not detailed here).

In Run mode (debugging), it's useful to know exactly what line of a script that some instruction is representing. Even though this is the first and only instruction, it was on the 5th line of the script, perhaps because the first 4 lines had some comments which we threw away. Compiled games do not store this information.

Each instruction most likely has some parameters. For instructions with no parameters (such as CLEAR to clear the text area), this would be set to 0. Otherwise, it is a reference to the position in an array of a particular SCParameters object.

The SCParameters object is nothing but an array: list() as UInt32.

For our number variable allocation, the parameters object list array would have two items. list(0) would reference directly the number variable we are assigning to.

list(1) is trickier - how do we know if we are dealing with a constant, another variable, a built in function, a user function, an array, or an expression? In this case it references a huge table. The table then tells us three things:

Type - such as, is this a constant, or a variable, or an array
Value - which constant (they are all stored in another table)? which variable (direct reference to the index position of that variable in the array)? which array?
Ptr - only used for functions and arrays. for arrays this would reference another point in the table and we have to look up all over again, because maybe they referenced the index with a constant, or another variable, or another array's value, or a function, or an expression!

Now what's interesting is the support for code blocks such as IF. An IF statement, including the ELSE block, all of the code inside, etc. is considered ONE instruction. The IF instruction has numerous parameters such as:

list(0) = left side
list(1) = sign
list(2) = right side
list(3) = are we comparing strings or numbers
list(4) = SCScript to run if the comparison was true
list(5) = SCScript to run if the comparison was false (ELSE). if no ELSE then this array index does not exist.

The SCScripts referenced by the IF instruction, would have line numbers corresponding to their original true location in the parent script. This allows perfect debugging even though we are now dealing with nested scripts.

I'm a bit tired so this isn't the best explanation. The other main object used is SCMathExpression which consists of two arrays:

signs() as byte
vars() as UInt32

There is always one less signs than vars. There is always one sign though otherwise it's stupid, we would have just referenced the var directly and not wasted time on an expression.

signs() is self explanatory, it just represents + - / * etc

vars() references the big ass table above with the param types, ptrs, values. So to add a number to an expression in parenthesis might be represented as such:

vars(0) = 4
signs(0) = whatever means add
vars(1) = 2

vars(0), would have us go to the params lookup table, where we would see that the paramtype is a constant, the paramvalue references the constant. ptr is blank

vars(1) would have us go to the lookup table again, we would see that the paramtype is a math expression, value tells us which one. ptr is not used

NewMath deals with all use of numbers in your scripts. NewMath is used recursively, when dealing with expressions.

So basically - there are no trees, although the representation in memory for some things is tree-like, it uses recursion to do the heavy lifting. This may be a bottleneck but it was also the easiest to program and understand.

Really tired so I probably screwed up at the end a bit
Title: Re: Gan's Runtime & Script Interpreter
Post by: x on March 21, 2011, 05:31:37 AM
Cool explanation Mike and Gan! I was just wondering for two reasons. Firstly I was thinking maybe we could determine some of the reasons why they perform the way they do, and because I just started a course in compiling+syntactical analysis, and its interesting too see the different approaches.

@Mike: Thats a nice way of doing things, seems streamlined enough and easy to work with/understand! Just a random thought: Mike, couldn't you use a hash table instead of arrays? Hence making the look-ups faster? Do they support them is REALbasic?
I just thought this since I am assuming its the constant function lookups/array searching that might be slowing SC down in comparison to Gans interpreter.

@Matt: I gotta say man, I'm pretty impressed. I'm not sure if you're aware of this, but the way you handled the interpreter is in essence the "standard" (and supposedly best) way too do it. At least according to my laymans understanding. Many kudos.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 21, 2011, 11:36:19 AM
Quote
So basically - there are no trees, although the representation in memory for some things is tree-like, it uses recursion to do the heavy lifting. This may be a bottleneck but it was also the easiest to program and understand.
Ah yeah. Before I recoded my solver, it relied solely on recursion. It'd constantly loop through the equation looking for things to solve. Made it incredibly slow. Now the parser takes care of that and there's no recursion in the solver, just a straight shot through.
At first I thought taking out recursion that it'd be quite a bit more complicated and less friendly but, that's not true. It actually is kinda easier, most of everything is chunked together in the parser instead of part in the parser, part in the solver.

Here's a little description of how it works:
User types in:
Code: [Select]
Let x = 1 + 5 - 3 * 2
Parser breaks that up into: let, x, =, 1,+,5,-,3,*,2
X is identified as a variable. This line is marked as a variable setting line. Everything after = is identified as the equation.
The parser takes that equation and sticks it into an equation parser. Which looks through and breaks the equation into equation objects:
Eq1 is 3*2
Eq2  is 1+5
Eq3 is Eq2 - Eq1
Then it realizes that the equation is all broken down into tree form and returns Eq3 as the base.
So after the parser, the runtime runs each line of code.
It realizes that the line is setting a variable, it takes the variable and the equation, Eq3, and it calls the solve function of Eq3.
Eq3 is the base so it calls solve on Eq2 and Eq1. Looks like:
Eq3 = Eq2 - Eq1
Eq3 = 6 - Eq1
Eq3 = 6 - 6
Returns 0.
Then the runtime takes the returned 0 and stores it in the variable.

There's no searching for stuff to solve, it just knows what to solve.

Quote
@Matt: I gotta say man, I'm pretty impressed. I'm not sure if you're aware of this, but the way you handled the interpreter is in essence the "standard" (and supposedly best) way too do it. At least according to my laymans understanding. Many kudos.
Thanks.


I've worked on it a bit more. So...

New Features
Here's the download: Gan's Runtime (http://cl.ly/3d210b2m1w3j2j2c3n2y)

Mini manual:
Making Variables
Code: [Select]
//Either form can be use
Let x = 1
or
x = 1

Let x$ = "test"
or
x$ = "test"
Variable Equations
Code: [Select]
//+=, -=, *=, and /= are supported
x = x + 5
or
x += 5
Complex Equations
Code: [Select]
//Complex equations are handled with ease.
x = (5 * (3 + 1) / 6 * 18) - 3
If Statement
Code: [Select]
//If statements and nested if statements work well.
If  x < 5 Then
x+=1
End If
For Statement
Code: [Select]
//For and nested for statements work.
For i = 1 to 5
x+=1
next


I'm thinking of adding support for comments, more commands, and rudimentary debugging but I'm not sure. But since I don't have plans for this, I'm really not sure what would be the point.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 21, 2011, 06:19:00 PM
Quote
Cool explanation Mike and Gan! I was just wondering for two reasons. Firstly I was thinking maybe we could determine some of the reasons why they perform the way they do, and because I just started a course in compiling+syntactical analysis, and its interesting too see the different approaches.

@Mike: Thats a nice way of doing things, seems streamlined enough and easy to work with/understand! Just a random thought: Mike, couldn't you use a hash table instead of arrays? Hence making the look-ups faster? Do they support them is REALbasic?
I just thought this since I am assuming its the constant function lookups/array searching that might be slowing SC down in comparison to Gans interpreter.

There aren't any array lookups really. The whole idea of the byte code/pre-interpreted system is to eliminate slow look ups.

For example, with the old interpreter I did use a hash table (called a Dictionary in REALbasic) to deal with variables. In the new byte code system, because variables are global, all variables are pre-assigned memory. All number variables are stored in one array and all string variables are stored in another array. If you only have one variable "x", then it will be assigned position 0 in the NumberVariables array. Compiled scripts have no reference to "x" at all. They reference position 0 of the NumberArrays variable. As far as this goes I don't think it could be made any faster.

You might say this wastes some memory, but consider that even a complicated game might only use a few hundred number variables. Number variables are all double precision and use 8 bytes each. Even if the game uses 500 number variables this only uses 4000 bytes memory. As far as strings go, they are variable length and REALbasic handles their management. I think REALbasic allocates some small amount of memory for each string and then uses an algorithm which doubles the memory used for each string when the string grows to run out of memory. REALbasic is not known for having the fastest strings - but it does have some of the easiest strings around with excellent Unicode support (SilverCreator supports Unicode for almost all game strings. You can write the entire game in Japanese if you wish. I think variable names/custom methods must still be ASCII.)
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 21, 2011, 07:02:32 PM
Quote
Ah yeah. Before I recoded my solver, it relied solely on recursion. It'd constantly loop through the equation looking for things to solve. Made it incredibly slow. Now the parser takes care of that and there's no recursion in the solver, just a straight shot through.
At first I thought taking out recursion that it'd be quite a bit more complicated and less friendly but, that's not true. It actually is kinda easier, most of everything is chunked together in the parser instead of part in the parser, part in the solver.

Maybe you guys didn't understand. Nothing is parsed in my system anymore. The math expressions are fully parsed, but we still use recursion to solve them. Consider this expression (keeping in mind that SilverCreator still uses left to right math for historical reasons)

8 / (5 + 3) - (6 * (1 + 1)) + (5 + 3)

The expression parser receives this expression and outputs a SCMathExpression. Assume we have no previous expressions. After the parser is done, we will now have the following expressions in the list (represented in a human readable form):

MathExpressions(0) = 5 + 3

MathExpressions(1) = 1 + 1

MathExpressions(2) = 6 * MathExpressions(1)

MathExpressions(3) = 8 / MathExpressions(0) - MathExpressions(2) + MathExpressions(0)

The parser will return 3 (referencing MathExpressions(3)). We will store this in ParamValues(x). In ParamType(x) we store the value that indicates it's a MathExpression. ParamPtr is unused. "x" is then stored in list(1) for the LET command.

Now let's say we are running the script and we get the LET command which says store into variable "lard" the results of MathExpression(3). We then call NewMath which has an extremely fast solver. It just looks at two items and the sign. If one of the items is a MathExpression, then we call NewMath again (recursion).

It's the mechanism by which MathExpressions reference each other which makes it a sort of "tree" but as you can see, it's set up to optimize so we don't store any duplicate expressions (which is easy due to global variable scope).

MathExpressions are only objects because objects provide a convenient way to store arrays.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GabrielCA on March 21, 2011, 08:34:26 PM
This is all very interesting.

The talk about trees (and the pseudocode) reminded me of my own script interpreter experiment, which manages nested expressions by rewriting them in a pre-compiler phase:
Code: [Select]
x = 2/(3 *(4+5))
becomes
Code: [Select]
PS_EXP1 = 4+5
PS_EXP2 = 3 * PS_EXP1
x = 2/ PS_EXP2
Of course, this isn't very thoughtful, and my interpreter doesn't manage operator precedence.

One interesting script interpreter written by a teenager that I found out about a few months ago is "nscript". It is very well written (very readable and concise) and uses good, well-known algorithms.
Note that it is stack-based, unlike most programming languages discussed here.

Printing the sum of 253 and 561 is written, in nscript, as:
Code: [Select]
253 561 + print
It is hosted at https://github.com/nikki93/nscript

@Matt: can you put the source code of your interpreter on this site so we can look at it ?
Title: Re: Gan's Runtime & Script Interpreter
Post by: x on March 21, 2011, 09:14:14 PM
@Gan. You could totally make a token compiler for this quite easily if you wanted.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 21, 2011, 09:42:09 PM
@GabrielCA That's pretty neat. My equation parser works like that. It just targets the equations in operator precedence.

I'd like to post the source but (1) I'm on the road traveling and (2) I'm in the process of adding new stuff.

@X What's a token compiler?
Title: Re: Gan's Runtime & Script Interpreter
Post by: x on March 21, 2011, 09:55:29 PM
Its a bit of an archaic/weird term, buts its what TNTbasic and Metal Basic did I think. Its not fast, but its easy to do.

Basically you bind the processed or "tokenized" script to a runtime. And tadah, its compiled. Its kind of cheating. All you would have to do is port your interpreter into a "run time" and have your "compiler" embed the script into it. Then every time the run time is executed it launches that script and works as a "compiled" executable. I managed to do it using an embedded databank in blitzmax at one point. There are other ways to do it, I've even seen some token compilers that just require you to put the source.txt file in the same folder, although IMO thats a little pointless.

EDIT: I almost forgot, since its on Mac, you could probably just add the preprocessed code as a resource file.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 21, 2011, 11:06:57 PM
Quote
Its a bit of an archaic/weird term, buts its what TNTbasic and Metal Basic did I think. Its not fast, but its easy to do.

Basically you bind the processed or "tokenized" script to a runtime. And tadah, its compiled. Its kind of cheating. All you would have to do is port your interpreter into a "run time" and have your "compiler" embed the script into it. Then every time the run time is executed it launches that script and works as a "compiled" executable. I managed to do it using an embedded databank in blitzmax at one point. There are other ways to do it, I've even seen some token compilers that just require you to put the source.txt file in the same folder, although IMO thats a little pointless.

EDIT: I almost forgot, since its on Mac, you could probably just add the preprocessed code as a resource file.


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.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 22, 2011, 01:44:33 AM
Gan - sorry for being so cross on AIM. Been having a rough time lately.
Title: Re: Gan's Runtime & Script Interpreter
Post by: x on March 22, 2011, 02:31:02 AM
Quote


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)?
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 22, 2011, 02:36:11 AM
Quote

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.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GabrielCA on March 22, 2011, 07:23:01 PM
@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
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 23, 2011, 12:13:59 AM
Gan's Runtime & Script Interpreter Graphics Drawing Video (http://www.youtube.com/watch?v=g4a4oHXweL0)

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
Here's the download of the runtime if you want to test:
Gan's Runtime Demo (http://cl.ly/3H3o3o2M1p0I0S2K3W3x)

@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!
(http://cl.ly/2G05233k192r0v0I0B17/Screen_shot_2011-03-23_at_8.20.26_AM.png)
(http://cl.ly/1o0a0G0f0w1t3n3P3p0E/Screen_shot_2011-03-23_at_8.21.07_AM.png)
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 23, 2011, 03:06:21 PM
Made another little demo. Just of a graphic bouncing around the screen:
Gan's Runtime Bouncing Graphic (http://www.youtube.com/watch?v=adJQMprjTEI)

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.
Title: Re: Gan's Runtime & Script Interpreter
Post by: x on March 23, 2011, 06:36:44 PM
Quote
Made another little demo. Just of a graphic bouncing around the screen:
Gan's Runtime Bouncing Graphic (http://www.youtube.com/watch?v=adJQMprjTEI)

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.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 23, 2011, 07:55:44 PM
I suppose. Though a mutable array sounds quite a bit more user friendly.
Title: Re: Gan's Runtime & Script Interpreter
Post by: x on March 24, 2011, 04:24:55 AM
Quote
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.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 24, 2011, 06:07:05 AM
Quote

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.
Title: Re: Gan's Runtime & Script Interpreter
Post by: x on March 24, 2011, 07:00:39 AM
Quote


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  :)
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 24, 2011, 07:08:38 AM
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.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 24, 2011, 07:26:41 AM
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.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 24, 2011, 07:29:53 AM
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
Title: Re: Gan's Runtime & Script Interpreter
Post by: x on March 24, 2011, 08:52:30 AM
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.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 25, 2011, 04:02:00 PM
Gan's Runtime Cross-Platform Video (http://www.youtube.com/watch?v=qCtFj91QA7Q)

(http://cl.ly/131w3m2b2R0a2r1b2n3M/Screen_shot_2011-03-25_at_3.35.01_PM.png)
(http://cl.ly/3l0R1g46000d012v0j0L/Screen_shot_2011-03-25_at_3.35.31_PM.png)

Magic? Sorcery? Computer wizardry?! No, it's Cocotron.

Cocotron allows Obj-C and Cocoa to be compile for Windows. From a mac. From inside Xcode. With 1 click of a button. Impressed?

Cocotron was a major headache to set up. It's still a young open source project, working to duplicate the Cocoa functionality for windows. Much of Cocoa does work on windows but bugs still exist and some functionality isn't made yet. There are plenty of programmers working on this project and so far it looks great.
Once the setup was completed, compiling and using my program on windows was a breeze.

This alternative for cross compiling has many advantages:
Disadvantages:

Gan's Runtime Mac Executable (http://cl.ly/0Q3F1z1I0H0c3v26233g)
Gan's Runtime Windows Executable (http://cl.ly/36423b450Z41152c071t)

So this runtime can compile for mac and pc, fairly nicely(it works on both). Now what?
I have no idea.
Any of you guys have any ideas of what to do with this?
Title: Re: Gan's Runtime & Script Interpreter
Post by: x on March 25, 2011, 06:29:42 PM
Wheres my credit for telling you about this  :P

And I still think you should make a token compiler for it.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Telstar5 on March 25, 2011, 07:53:02 PM
94% CPU usage for 1 line.

----> http://oi54.tinypic.com/14j3f52.jpg

I think I need to lie down.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 25, 2011, 07:53:54 PM
Quote
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.


SilverCreator uses REALbasic and this will never change. What would be beneficial to SilverCreator is to figure out the particular inefficiencies, and recode around them.

Or we can just be lazy, and wait for LLVM.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 25, 2011, 08:04:22 PM
@Telstar
There's actually 5 lines in the start and 5 lines in the timer methods. They just weren't showing cause they were bugging out on me. 95% CPU is due to the 100 sprites moving on screen being drawn at 60 frames per second. Yeah, very inefficient. Would help tons to switch to OpenGl.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Telstar5 on March 25, 2011, 08:22:34 PM
Why 60fps for something that isn't moving? Sure, I see the point of being able to have 100 sprites on screen at the same time, but isn't 60fps a bit... overkill?

I'd fiddle with the runtime myself, but it's eating system resources whilst idle. That's probably Cocotron, though.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 26, 2011, 12:13:00 AM
Quote
Why 60fps for something that isn't moving? Sure, I see the point of being able to have 100 sprites on screen at the same time, but isn't 60fps a bit... overkill?
The timer is automatically set to 60fps and it also controls the updating of the screen.

Quote
I'd fiddle with the runtime myself, but it's eating system resources whilst idle. That's probably Cocotron, though.
Yeah, Cocotron isn't entirely safe at the moment. Best to try the mac version.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 26, 2011, 12:45:41 AM
SilverCreator does not update the screen 60 fps by default.

At first, the screen was updated every time you moved a sprite, but this was found to be inefficient if you needed to move 10 sprites. So that's why we have the extra boolean at the end, with your last sprite move omitting the boolean and causing the screen to update.

You can also choose to use the boolean with ALL sprites, and then use UPDATESCREEN in a timer.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Telstar5 on March 26, 2011, 08:47:12 AM
If Cocotron is that unstable, I wouldn't rely on it for compiling Windows binaries. You'd be better off using two separate source codes and keeping compatibility with the end-user syntax. Or use another cross-platform library like Qt.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 26, 2011, 09:23:06 AM
To stabilize Cocotron it requires me to use my program and dig deep fixing stuff. Then what I fix I should send off to the Cocotron to post as a patch.
Then it's a win-win for all.
They say it takes less time to stabilize your program then to recode it.

I just can't wait till Cocotron becomes pretty much complete, fast, and safe. But that'll take a while, it's just an open source project being lead by 7 main programmers.

I think I'd like to try other cross platform alternatives but I'd very much like to stay within Obj-C and Cocoa.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 26, 2011, 04:04:45 PM
Hey Mike I did a Obj-C vs RealBasic speed test:
(http://cl.ly/0s3k0H380Z402j211244/Screen_shot_2011-03-26_at_3.50.51_PM.png)
Realbasic Speed Test Source (http://cl.ly/163l3Z320o2n0m1x2A3V)
(http://cl.ly/120i411W0W2p1n3L0k1f/Screen_shot_2011-03-26_at_3.52.32_PM.png)
Obj-C Speed Test Source (http://cl.ly/3R1a0K1O1F210G2y1245)

Language Speed Test
Obj-C is 71.6 *faster than RealBasic

Scripting Language Speed Test
Gan's Runtime is 13.2 *faster than SilverCreator

So what's my point?
Well if we do further ratios...
According to this data... If RealBasic had the speed of Obj-C, SilverCreator would clock in at:
33 ticks / 71.6 = 0.46 Ticks.

If Obj-C had the speed of RealBasic, Gan's Runtime would clock in at:
2.5 ticks / (3/215) = 179.16 Ticks


Conclusion
If my math is right and language speed was constant, then if SilverCreator were written in Obj-C exactly how it is then it's be about 5* faster than my runtime.

What does it mean?
If this data is correct, SilverCreator is more efficient than my runtime. It just has RB slowing it down.
Title: Re: Gan's Runtime & Script Interpreter
Post by: x on March 26, 2011, 07:47:47 PM
Languages are never consistent in their speed for different operations. Although I agree that Obj-C would be much faster than REALbasic, but I'm not sure thats a fair margin. Can you post the exact code you used? Maybe Mike could optimize it better for REALbasic, than you can. Plus I would like too know.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 26, 2011, 07:56:47 PM
The download links are below the images.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Telstar5 on March 26, 2011, 08:38:17 PM
Quote
I think I'd like to try other cross platform alternatives but I'd very much like to stay within Obj-C and Cocoa.

Why? Other than because it's supported by Apple. In the long run something like Cocotron is never going to be as fast on Windows as it would be if it the applications compiled using it were written using the Windows API, or something that is cross platform by design and is already very mature.

Edit: I mean, don't get me wrong, this is a fantastic app and a great achievement, but I'm just saying you could take a lot of the pain and headaches out of cross-platform by trying something different.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GMG Mike on March 26, 2011, 08:39:13 PM
Gan actually compiled the Cocoa tests, while he RAN THE REALBASIC TESTS IN THE DEBUGGER

RB apps in debug mode are slower.

The entire test above is flawed and should be thrown out.

Here are my tests. Both apps are 32-bit Intel. Both apps are compiled.

RB: 70 ms
OBJC: 3 ms

Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 26, 2011, 09:08:27 PM
Yeah I ran both tests on debug.

So according to the new results, Sc's runtime isn't 5* more efficient than mine.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Telstar5 on March 26, 2011, 09:49:49 PM
One other tiny niggle about Windows compile: none of the menus seem to serve any purpose..actually, they're all the standard OS X menus and menu items :P is there a way to have two menu bars and keep one for Mac, another for Windows? It's a one-click operation under RB.
Title: Re: Gan's Runtime & Script Interpreter
Post by: x on March 26, 2011, 09:54:41 PM
You should just code it in C++ eventually Gan with a simple GUI library. You really wouldn't have to change much. Objective-C is a superset of C, and C++ is just a different superset. Both bring objects to the table, the only difference is the syntax.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on March 26, 2011, 11:21:22 PM
@Telstar
I can have 2 different interface files, 1 for pc, 1 for mac.

@X
You're probably right, it'd be beneficial if I gave that a try.
Title: Re: Gan's Runtime & Script Interpreter
Post by: WarHampster on March 27, 2011, 05:34:52 PM
Just stopping by to say how cool this is.

This is cool ;D
Title: Re: Gan's Runtime & Script Interpreter
Post by: GabrielCA on April 05, 2011, 03:31:03 PM
So, any source code  ;D ?
Title: Re: Gan's Runtime & Script Interpreter
Post by: Gan on April 15, 2011, 04:57:59 PM
Here's the source:
Gan's Runtime & Interpreter Source Code (http://cl.ly/3c1a2P0J3W1C1b2I1746)

It may be a mess, but it works.
Title: Re: Gan's Runtime & Script Interpreter
Post by: GabrielCA on April 15, 2011, 07:13:18 PM
Thanks a lot.
Title: Re: Gan's Runtime & Script Interpreter
Post by: Eugeneepinc on March 22, 2024, 12:32:08 PM
Excuse, that I interrupt you, there is an offer to go on other way.
 
circumspection
<a href=https://mmfporn.com/tags/gay-gaycest/>mmfporn</a>
@456FgDDY8
Title: Young, suicidal, decade, connecting colonoscope self-judgment.
Post by: ujivikuzemorq on March 22, 2024, 04:18:11 PM
A circumflex cheap amoxicillin pills (https://pureelegance-decor.com/amoxicillin/) amoxil tablets 1000 price (https://primerafootandankle.com/item/amoxicillin/) furosemide and heart failure (https://columbiainnastoria.com/lasix/) amoxicillin (https://the7upexperience.com/amoxicillin/) buy prednisone (https://wellnowuc.com/prednisone/) prednisone without prescription retin a cream 0.05 (https://recipiy.com/retin-a/) buy nolvadex (https://primerafootandankle.com/nolvadex/) hydroxychloroquine (https://shilpaotc.com/hydroxychloroquine-without-dr-prescription/) cialis tablets (https://youngdental.net/buying-cialis-online/) vidalista-black pharmacology (https://inthefieldblog.com/vidalista-black/) prednisone online (https://americanazachary.com/product/prednisone-online/) low cost effient (https://racelineonline.com/effient/) testosterone anadoil (https://damcf.org/item/testosterone-anadoil/) lasix lowest price (https://rdasatx.com/buy-generic-lasix/) lasix lowest ketorolac prices (https://fairbusinessgoodwillappraisal.com/product/ketorolac/) best india cialis black and price (https://frankfortamerican.com/cialis-black-commercial/) purchase prednisone (https://livinlifepc.com/purchase-prednisone/) levitra 20 mg (https://ossoccer.org/www-levitra-com/) zithromax (https://coastal-ims.com/drug/zithromax/) generic tadalis  sx in canada (https://mplseye.com/product/tadalis-sx/) buy tadalis--sx in indonesia wool slow us: <a href="https://pureelegance-decor.com/amoxicillin/">cheap amoxicillin online</a> <a href="https://primerafootandankle.com/item/amoxicillin/">amoxicillin online canada</a> <a href="https://columbiainnastoria.com/lasix/">lasix without prescription</a> <a href="https://the7upexperience.com/amoxicillin/">amoxicillin without a doctors prescription</a> <a href="https://wellnowuc.com/prednisone/">order prednisone</a> <a href="https://recipiy.com/retin-a/">retin a</a> <a href="https://primerafootandankle.com/nolvadex/">order nolvadex</a> <a href="https://shilpaotc.com/hydroxychloroquine-without-dr-prescription/">order hydroxychloroquine</a> <a href="https://youngdental.net/buying-cialis-online/">cialis 20 costo</a> <a href="https://inthefieldblog.com/vidalista-black/">vidalista black 80mg</a> <a href="https://americanazachary.com/product/prednisone-online/">prednisone on line</a> <a href="https://racelineonline.com/effient/">discounts on effient</a> <a href="https://damcf.org/item/testosterone-anadoil/">generic testosterone anadoil from canada</a> generic testosterone anadoil from canada <a href="https://rdasatx.com/buy-generic-lasix/">cheapest lasix</a> <a href="https://fairbusinessgoodwillappraisal.com/product/ketorolac/">cheapest ketorolac dosage price</a> <a href="https://frankfortamerican.com/cialis-black-commercial/">cialis black</a> <a href="https://livinlifepc.com/purchase-prednisone/">purchase prednisone</a> prednisone dose for poison oak <a href="https://ossoccer.org/www-levitra-com/">generic levitra 20mg</a> <a href="https://coastal-ims.com/drug/zithromax/">buy zithromax</a> <a href="https://mplseye.com/product/tadalis-sx/">tadalis  sx online uk</a> infraumbilical https://pureelegance-decor.com/amoxicillin/ https://primerafootandankle.com/item/amoxicillin/ https://columbiainnastoria.com/lasix/ https://the7upexperience.com/amoxicillin/ https://wellnowuc.com/prednisone/ https://recipiy.com/retin-a/ https://primerafootandankle.com/nolvadex/ https://shilpaotc.com/hydroxychloroquine-without-dr-prescription/ https://youngdental.net/buying-cialis-online/ https://inthefieldblog.com/vidalista-black/ https://americanazachary.com/product/prednisone-online/ https://racelineonline.com/effient/ https://damcf.org/item/testosterone-anadoil/ https://rdasatx.com/buy-generic-lasix/ https://fairbusinessgoodwillappraisal.com/product/ketorolac/ https://frankfortamerican.com/cialis-black-commercial/ https://livinlifepc.com/purchase-prednisone/ https://ossoccer.org/www-levitra-com/ https://coastal-ims.com/drug/zithromax/ https://mplseye.com/product/tadalis-sx/ dysplastic deteriorating remnants.