Noel,
Thanks for the article it was very informative. My reasoning behind developing BlitzScript3D was similar to Rik's with one additional facet. I wanted the Scripting Engine to be written in Blitz3D. No Dlls. This would serve as a learning tool and show that Blitz3D can meet the challenge. This is ultimately my goal with all my projects.
John J,
My idea of implementing SELECT...CASE is also similar to the IF...ELSEIF...THEN.
Conditional Loops. I do have a primitive form of looping using labels and goto commands. Its easy to home brew your own conditional loops but, too unconventional. I plan to implement FOR...NEXT, Repeat...Until, While...Wend loops based labels, jumps, and if...then contructs. I will also going to experiment with Hyper SELECT...CASE based on Label Jumping. The reason behind this is to reduced the number of instructions to evaluate conditions.
I haven't quite figured out how I will implement Functions less alone overload them. So I'm going to think tank for this. With BlitzScript3D being datatype-less, it may be difficult to implement overloading. The only way i can see this is if i implement them like methods in class and it will be limited (based on number of parameters vs type of parameters).
The way you implemented Custom Types looks very interesting. This is were I can see BlitzScript3D datatype-lessness making implementation easier. If I do pursue types, I will most likely pursue simple object classes in which you can package properties and methods under a object name. I always been a fan of the (.) syntax:
I'm very interested in how you plan to implement the VM. I assume your compiler will convert scripts to opcodes and the VM loads in opcodes for processing. My compiler converts scripts directly into pcode (a byte representation of the opcodes). This is the compiled version of the script. BlitzScript3D can either recompile the script at loadtime or just load the compiled script. This allows you to totally remove human readible scripts and just used the compiled versions.
Thanks for the article it was very informative. My reasoning behind developing BlitzScript3D was similar to Rik's with one additional facet. I wanted the Scripting Engine to be written in Blitz3D. No Dlls. This would serve as a learning tool and show that Blitz3D can meet the challenge. This is ultimately my goal with all my projects.
John J,
My idea of implementing SELECT...CASE is also similar to the IF...ELSEIF...THEN.
get varname ;select If var=value ;first case ElseIf var=value ;next case ElseIf var=value ;ditto . . . Else ;default case EndIf ;end selectSELECT CASE will most like be my next feature to add. I noticed that your IF...THEN can handle multiple lines. However, the following line concerns me.
If GSC_TokenType = TOKEN_IF Then GSC_AddWarning("Ambiguous coding style (may cause unexpected errors - see language manual)").This suggest that the implementation does not support nested IF..THEN. Please correct me if I'm wrong. Handling Nested SELECT...CASE is also something to consider.
Conditional Loops. I do have a primitive form of looping using labels and goto commands. Its easy to home brew your own conditional loops but, too unconventional. I plan to implement FOR...NEXT, Repeat...Until, While...Wend loops based labels, jumps, and if...then contructs. I will also going to experiment with Hyper SELECT...CASE based on Label Jumping. The reason behind this is to reduced the number of instructions to evaluate conditions.
I haven't quite figured out how I will implement Functions less alone overload them. So I'm going to think tank for this. With BlitzScript3D being datatype-less, it may be difficult to implement overloading. The only way i can see this is if i implement them like methods in class and it will be limited (based on number of parameters vs type of parameters).
The way you implemented Custom Types looks very interesting. This is were I can see BlitzScript3D datatype-lessness making implementation easier. If I do pursue types, I will most likely pursue simple object classes in which you can package properties and methods under a object name. I always been a fan of the (.) syntax:
object = New model object.entity = entityload("dude.b3d") object.rotate() vs object.model = New model object\entity = entityload("dude.b3d") object\rotate() ;doesent existI would also build in ID Reference Management for fast access to individual objects. Custom Type implementation depends on how it impacts performance.
I'm very interested in how you plan to implement the VM. I assume your compiler will convert scripts to opcodes and the VM loads in opcodes for processing. My compiler converts scripts directly into pcode (a byte representation of the opcodes). This is the compiled version of the script. BlitzScript3D can either recompile the script at loadtime or just load the compiled script. This allows you to totally remove human readible scripts and just used the compiled versions.