Tuesday, June 22, 2010

The Shintaz Project

I've started a new project called Shintaz, also named after one of my character from the same series as Rusher. Shintaz is a scripting engine, consisted of a compiler and a virtual machine. As you may know, the virtual machine behind Flash Player is called ActionScript Virtual Machine (AVM), and the Shintaz Virtual Machine (SVM) is going to be running on AVM. That's right, a VM running on another VM.

Actually, I took a compiler course this semester in order to help me understand how to develop a compiler and a virtual machine. It really helps a lot!

The main purpose of developing Shintaz is to integrate it with Rusher, making Rusher a game engine equipped with a scripting engine capable of compiling and running scripts at run-time. This helps the debugging process and may allow people to do lots of dynamic stuff with the game.

Shintaz's compiler is half-complete, and its virtual machine, SVM, is almost done. SVM is already capable of executing bytecode consisted of opcodes. Same as Java Virtual Machine (JVM), SVM is a stack machine, meaning its memory takes the form of one or more stacks.

Here are some code snippets for generating an opcode array, converting it to Shintaz-compatible bytecode object, and executing the bytecode with SVM.

The following code declares a variable "x", and assigns it a value of 10. Note how the value 10 is first pushed to the memory stack and then popped to be assigned to "x".


There're also some opcodes for program counter jumping and branching. The following code skips the assignment of a value 20 to "x".


That's it for the opcodes. Who wants to program with opcodes anyway? Shintaz provides a compiler that accepts scripts with a grammar similar to JavaScript and ActionScript. I'm still working on the parser, but here's how things will turn out.

The code below does exactly the same thing as the first code snippet, declaring a variable "x" and assigning a value 10 to it, but with high-level scripts.


Function declaration and class declaration are on its way. I'm trying to find more information on these topics, and then I'll start working on it.

Lastly, and one of the most important feature of Shintaz, although still work in progress, is symbol linking. What's a scripting worth if it cannot communicate with other objects and functions outside of the virtual machine? Shintaz provides a way to link symbols in the scripts with other ActionScript objects and functions.

The following code shows how. The trace function is linked to the symbol "print", so any occurrence of the identifier "print" in the script is regarded as a reference to the trace function.


Oh, I almost forgot. I'm also planning on adding serialization and deserialization features to Shintaz, allowing conversion between compiled Bytecode objects and ByteArray objects. In this way, people can save compiled bytecode to files, and later load and execute them during run-time, saving the time of compilation.

That's it. I hope I can finish Shintaz before my presentation for the PTT Flash Workshop this year on July 24.

Monday, June 7, 2010

Switching Stardust Particle Collection Type



Stardust project homepage

Paq from WonderFL made a quick performance test with different particle collection types provided by Stardust, and the result turned out to be quite different from my own previous tests. I think the difference is due to the fact that we conducted the tests with different numbers of particles. Hence, it's reasonable to choose which particle collection type to use according to the roughly estimated number of particles that will be present.

For this reason, also as one of the new feature of Stardust version 1.1.161, I've added the Emitter.particleCollectionType getter/setter to allow users to switch between different particle collection types. Valid types are mapped by integers defined in the ParticleCollectionType class.

Now the Emitter constructor accepts a second parameter for the integer corresponding to a particle collection type, which is the ParticleFastArray class by default.

This is how you set the underlying particle collection type of an emitter to a linked list.


And this is how you switch an emitter's particle collection to a different type, say, an array.


There's no specific rule in deciding whether a collection type is the best for your specific particle system. In terms of performance, fast arrays are approximately as good as linked lists. However, if you insist on finding the exact best one, you just have to try them all and then determine which works the best.