CJ's Blog

Moving to a New Blog

2011-01-23T00:37:00.000-08:00

I’ve registered a new domain, and I've moved to a new blog.
Future posts will be posted there.

Stardust 1.3 Released!

2011-01-07T11:25:00.000-08:00

Stardust project homepage

Finally! Stardust version 1.3 is released!

I've updated all the examples, so they all work perfectly with the new particle handlers.

I'm currently working on the integration of Stardust and Minko, a new 3D engine that will support the Molehill APIs. Paq is working on the integration with Alternativa3D and Away3D, whilch will also support the Molehill APIs. I'm really looking forward to Stardust being used in Molehill-powered applications (especially games, of course), enriching the visual experience with 3D particles!.

Particle Handlers for Stardust 1.3

2011-01-03T04:23:00.000-08:00

Stardust project homepage

As a quick notice, Paq has joined the Stardust development team. He'll be working on plugins for Alternativa3D and Away3D, and Japanese localization. Horray!!

I'm currently working on the most important new features of Stardust 1.3, switching from renderers to particle handlers.

Previously, the particle data in Stardust are read and visually presented by the Renderer class, whose particlesAdded, particlesRemoved, and render methods take in ParticleCollection objects as parameters, and traverse them to retrieve particle data, resulting in almost twice the processing overhead for particle traversal.

I've found this extra traversal effort quite unnecessary. Since a complete traversal of the internal particle collection of each emitter is already done in each emitter step, so why not "embed" the rendering process into the emitter step? This is how I came up with the idea for particle handlers.

The skeleton of the ParticleHandler class looks like this:

The stepBegin method is invoked at the beginning of each emitter step.
The stepEnd method is invoked at the end of each emitter step.
The particlesAdded method is invoked when a new particle is added to the emitter.
The particlesRemoved method is invoked when a dead particle is removed from the emitter.
The readParticle method is invoked when a particle is fully updated by all actions.

You may override these methods to create your own handlers. The concept is quite similar to that of the renderers, only that particle handlers do not require extra (and unnecessary) particle collection traversal. Everything is done in one single traversal.

A particle handler is assigned to an emitter through the Emitter.particleHandler property, which is quite straightforward:

You may find the similarity between the code above and the use of its renderer counterpart:

Not until I finished the ParticleHandler class did I realize how easy it is to implement a polling station as a particle handler, favoring those developers preferring polling over events.

For your information, a polling station is like a passive database. You access the data only when you need to, which is the opposite to an event system. An event system, as most Flash developers are already familiar with, is an active database, "pushing" data to you whenever there is new data available.

Some framework is designed to better work with polling stations rather than event systems. Thus, I've written a PollingStation class that works as a polling station, recording all the relevant particles in each emitter step, and exposing an interface for data polling.

My Weird Dream - Thriller Game Story Concept

2010-11-27T06:31:00.000-08:00

I was taking a siesta in my girlfriend's house, and I had this very weird dream. The story of the dream was bizarre yet inspirational. It might serve as a game or movie concept. I thought I should type it down before I forget it.

So here goes my dream.

***

My girlfriend and I were some sort of secret agents sent by the government to investigate a mafia overload. We managed to get invited to his party held at his mansion, as undercover guests of course. His mansion was located in a small remote village in deep mountains, so it took us hours to drive there.

It was a very dark night. The mansion was extraordinary, like the ones you see in most movies. Most of the guests consisted of mafia members, and so began our investigation throughout the mansion.

Somehow I was noticed by a guard. He gave me a full tap-down and found my concealed gun, so our secret operation was blown. My girlfriend and I were held and watched by guards in a small room, with their boss standing aside planning how to torture and interrogate us. Both of us could simply thought about our hopeless future.

Suddenly, that was when something really wrong went on.

Without any warning, the entire village experienced a complete black-out. We could hear the screaming form the guests from everywhere in the mansion. We could even hear the shrieking voices from the entire village in the mountains, as if they were chased and attacked by some unidentified beings.

Then the lights came back.

The mansion was a mess. Shattered glasses, plates, and furnitures were scattered everywhere. Most of the guests were gone, and the rest were just too terrified to even say a word, with their mind completely left blank, not knowing what exactly to do next. People who managed to get to the garage and tried to drive away from the mansion, from the village, all mysteriously ended up either crashing into obstacles or falling into cliffs, with no survivors.

The mafia boss, my girlfriend and I, and the guards watching us, were the only people left who had remained conscious and were all thinking what to do next. Then we heard the sound.

Like thousands of high-pitched squeaking mice all coming at once, we can feel a swarm of unknown beings approaching extremely fast from outside of the mansion window.

"Quick! Shut the windows!" I yelled.

Two of the guards rushed to the open window and slammed it closed. But they were not fast enough. Some of the creatures leaked into the room. They were huge bats, or at least I thought they were. Those black-winged creatures soared in the room, attacking all the people inside, trying to bite us with their fangs and mauling us with claws.

I told the boss and the guards that this was not the time for making enemies. They should free us immediately so that we could work out a way to survive. And so my girlfriend and I were untied. Each of us picked up what we could find as a weapon in the room.

After a lot of yelling and wielding, all of us managed to kill every single flying creature in the room, shivering and panting.

"So, I think we DO need to cooperate in order to live." said the mafia boss.

It seemed that the the entire village had been wiped out, and we were the only survivors, for we could hear not a single voice from the village outside of the mansion.

"Yeah, I think so." I said.

And so began our escape from the mansion.

***

This is where my dream ended.

I can still remember us fighting our way through some unearthly and carnivorous creatures in my dream. It was as if those creatures were kind of manifestation of the fear and nightmare of each of us.

This can be some inspiration to a thriller adventure game. I hope more idea could come along.

MicroPlanet Game Concepts

2010-10-22T11:35:00.000-07:00

Currently I'm training in the School of Political Warfare, since I've passed the test for political officers. After two more months of training, I'll be working in the army as a political officer, hopefully having a much better and easier life than other ordinary soldiers.

In case you don't follow me on Twitter, I'm accepted into DigiPen's Bachelor of Science in Game Design program. This means I'm going to learn some real hard-core game development skills from the professionals after I get out of the army. I think I shouldn't waste my time on the boring and hollow training classes in the School of Political Warfare, so I've been constantly sketching game concepts in classes.

Recently, I've come up with this game concept, called MicroPlanet. The story takes place on a galaxy of microscopic planets, where there are bunny-like fungus creatures trying to expand their territory and fighting against opposing tribes.

Here's the first concept art I've drawn.
(Click on the image for larger view)

Basically, it's a 2D real-time strategy game. The player can only control the creatures, making them gather resources and building stuff, in order to expand the colony and destroy opposing tribes. The creatures cannot directly attack those from the opposing tribes, and vice versa. They can only build weapons, such as tanks and missile silos, to destroy enemy structures. Each tribe has a main building that produces new fungus creatures. When this building is destroyed, the game is over.

Below are some concept arts for the main menu screen. The smaller two on the bottom are two different designs for the main menu options.

Here are some quick sketches for various units, resources, and buildings.

And below are some more sketches. So far I've come up with three different types of resources: thermo energy, water, and metal. Thermo energy core are like miniature suns floating in the air; the Thermo Absorber is a ring-like structure that absorbers the thermo energy radiating from the core. On micro planets, water appears as floating blobs; the Water Station gathers water resource from below using an erect pipe.

There are two types of planets: solid planets and gas planets. There are some planet-specific buildings and resources, which I'm still working on.

On the top left you can see a quick concept sketch of the in-game screen, where a minimap is present and the character is selected.

That's it for MicroPlanet concept so far. I'll go as far as I can when I'm in the army, and I'll try get directly down to some coding when I'm home. Or at least I could do some CG concept arts.

My One-Year Compulsory Military Service

2010-08-07T22:47:00.001-07:00

I'm about to fulfill my compulsory military service tomorrow (August 9), and it ends in mid-July 2011. During my service, I can only have web access perhaps every one or two weeks, or even longer. So the updates and fixes to my projects will become far less frequent than normal. You may still email me if you've got any problems with the projects. I don't guarantee a quick response, but I'll reply as soon as possible.

I've applied for the "Bachelor of Science in Game Design (Fall 2011)" program in DigiPen. The result will come out several weeks later. I hope I could make it :)

P.S. I've shaved my head for the army, and it takes only 10 seconds to dry it after shower!

Using MVC Pattern in Rusher

2010-08-01T07:43:00.000-07:00

Rusher project homepage

Rusher is now version 0.6 Beta. One of the most important changes is the extraction of entity-related code from the Engine class into the EntityManager class. So instead of writing things like:

you write:

I've also added a new MVC Pattern example. Actually, it was one of my experiments to try implementing the MVC Patern in Rusher. This one turned out nice, so I've committed it to the repository. This example is simply a proof of concept, and I might find out other better approaches to using the MVC Pattern in Rusher.

View example demo
View example source

This example is a very simple painter application, consisted of a color chooser, a clear button, and a bitmap canvas where you can draw with your cursor.

The entire application is represented by the Context class, which extends the Entity class. There are four components added to this entity: Signaller, Model, View, and Controller.

Context

The Context class is pretty simple. It creates four components and adds it to itself. Another important modification to Rusher in version 0.6 is the one-clock-cycle-delayed invocation to the Component.onAdd() method. In this way, the order in which the components are added to the entity does not affect whether accessing other components in a component's onAdd() method yields a null value.

Signaller

The Signaller component is pretty much a "signal hub" consisted of several CJSignals signal objects. These signal objects dispatch application events listened by other components. Also, other components can cause these signal objects to dispatch events.

Model

The Model component contains the underlying application data, a BitmapData object representing the canvas. Also, this component defines several public methods that modifies the bitmap data. These methods allow users to change the line color, move the drawing pen position, draw a line, and clear the entire canvas.

View

The View component constructs and displays the visual representation of the application. In addition, this component listens for the mouse event dispatched by these display objects and relays these events to the signal objects in the Signaller component.

Controller

The Controller component listens the signal objects in the Signaller component and maps them to command objects. These command objects invokes the public methods provided by the Model class to modify the underlying bitmap data.

Finally, below are the command classes.

This is the LineColor command that changes the line color.

This is the MoveTo command that moves the position of the drawing pen.

This is the LineTo command that draws a line.

And this is the Clear command that clears the entire bitmap data.

You may view the source of this example in its entirety here.

Performance-Improving Techniques Employed in CJSignals

2010-07-07T21:24:00.000-07:00

CJSignals project homepage

CJSignals is an observer framework I released a couple of days ago, based on Robert Penner's AS3 Signals.

For some performance comparison of the native event system, CJSignals, and AS3 Signals, you may check out my previous post. Here I'm going to describe the performance-improving techniques employed in CJSignals.

This technique can also be employed elsewhere when massive objects are added and removed from an array very rapidly, where the array must be sorted and performance is vital. Rusher also uses this technique to manage prioritized active components.

Listener Array

For each listener functions added, a corresponding ListenerData object is created and stored in the internal array, which contains a reference to the listener, a boolean variable indicating whether the listener is a one-time listener, and an integer variable for keeping track of the index of the ListenerData object in the array. Also, a mapping relation between the listener and the ListenerData object is added to an internal dictionary for fast lookup.

Adding Listeners

CJSignals keeps track of the index of the first empty cell of the listener array with an integer variable, i.e. keeping track of the first null element. When a new listener is added, its corresponding ListenerData object is inserted to the array cell corresponding to the index, and then the index is incremented by 1. If the array is full, then its size is doubled. This approach assigns elements directly to an array cell by index, instead of invoking Array.push() every time a new listener is added.

Removing Listeners

Listeners can be removed from the array very efficiently. When a listener is removed from a signal, the listener dictionary is used to quickly retrieve the listener's corresponding ListenerData object. From the ListenerData object, the index of the object in the array can then be obtained (A). The index of the first empty cell is decremented by 1, thus pointing to the last non-null element (B). Cell A's content is replaced by cell B's, and cell B's content is replaced with a null value, so the first-null-element index is now keeping track of the new first null element.

Priority Sorting

Adding and removing listeners sets a listener-array-dirty flag to true, indicating the necessity to sort the listener array according to the listener priorities. The sorting is not necessary until the next signal dispatch or retrieval of the internal listener array through the public getter method get listeners(), the flag set back to false afterwards. Thus, multiple calls to the Signal.add() and Signals.remove() methods do not cause the array to be re-sorted; it is deferred to the point when the sorting is really necessary. After the array is sorted, the ListenerData objects are informed of and updated with their new indices.

I guess the native event system sorts the array every time a new listener is added, resulting in the huge performance difference between the system and CJSignals.

One good thing about the Array.sort() method is that it always pushes null elements to the tail of the array, so it's okay to keep a sparse array, as long as the index of the first null element is kept track of.

CJSignals - My New Observer Framework

2010-07-04T23:18:00.001-07:00

CJSignals project homepage

You might be able to tell from the project name that this project is inspired by Robert Penner's AS3 Signals. Yes, this is the case, indeed.

I've studied C# before, and played with Qt in the last semester. I felt the same thing Robert felt about the Event System in C# and the Signals/Slots System in Qt. It makes much more sense to extend an observer framework with composition rather than inheritance, and it makes code cleaner and more comprehensible if an object dispatches events of just one type, which is not the case for the ActionScript 3.0 native event dispatchers, for they can dispatch multiple types of events.

With CJSignals, each type of event corresponds to a Signal object "owned", a term for composition, by the subject. For instance, you can write code like this.

The parameter types of the listener matches those specified in the signal constructor. For information on the actual usage, you may check out the tutorial wiki page.

I built CJSignals from the ground up, using my own implementation of signals to boost performance, mainly performance concerning listener priority management and listener removal. I used the fast-splicing array technique I mentioned in this post, which is also employed by Rusher for active component priority management. And the priority sorting is only executed upon signal dispatch and if necessary.

Here's a comparison chart of the performance for the native event system, CJSignals, and AS3 Signals. Although CJSignals places second or third in some tests, the actual numerical results do not pose as bottleneck. What is more important is that CJSignals has the best worst-case performance: the worst test result for CJSignals is merely 13ms, whereas that for the native event system is 681ms, and AS3 Signals 5717ms.

The Shintaz Project

2010-06-22T06:10:00.000-07:00

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.

Switching Stardust Particle Collection Type

2010-06-07T08:43:00.000-07:00

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.

Stardust Supports Flare3D

2010-05-25T07:04:00.000-07:00

View example

View example

Stardust project homepage
(example source can be found on the project homepage)

You heard it. Stardust Particle Engine now supports Flare3D, a brand new 3D engine just released a couple of days ago. Awesome!

Flare3D includes a 3DS Max exporter that can export much, much more than just mesh data, such as complex materials (environment map, texture map, etc), animations, and bone animations. For the first example, I exported the star model and gold material entirely in 3DS Max, and the data can be correctly rendered in Flare, without writing a single line of code. The Flare3D team really has the love for 3DS Max users :)

The Flare3D extension for Stardust mainly consists of three initializers, Flare3DPivot3DClass, Flare3DPivot3DClone, Flare3DSprite3D, and two renderers, Flare3DPivot3DRenderer, and Flare3DSprite3DRenderer.

The Flare3DPivot3DClass and Flare3DPivot3DClone initializers work pretty much like the original DisplayObjectClass initializer, only that they assign Pivot3D objects from Flare3D to the Particle.target property, and they have to be used along with the Flare3DPivot3DRenderer. The first initializer creates new Pivot3D objects from a reference to a Pivot3D subclass, while the second initializer creates Pivot3D objects by cloning an existing one. The Flare3DSprite3D initializer creates 3D sprites and has to be used with the Flare3DSprite3DRenderer.

I hope you enjoy playing Stardust with Flare3D :)

Stardust v1.1 with Fast Array Splicing

2010-05-21T07:54:00.000-07:00

Stardust project homepage

The initial release of Stardust Particle Engine version 1.1 is now available (yep, no more betas). The major difference of the current revision from the previous one is the use of fast-splicing arrays (I made up this name, because I don't know if there's a formal or correct name for it).

Before Stardust employs linked-lists as default internal particle collections, ordinary arrays are used. Arrays are known to be fast to traverse and sort; however, arrays are also notoriously known to be ultra-slow when it comes to splicing large arrays. This is why I switched to linked-lists, which can perform much faster splicing operations by simple node-link manipulation.

I've come back to arrays and use a new method to perform splicing, and this turns the tables again. Now Stardust uses fast-splicing arrays as internal particle collections.

So, what are fast-splicing arrays anyway? Well, they're are no different from ordinary arrays except that they perform splicing quite differently. As any programmer familiar with ordinary array splicing knows, ordinary splicing first creates a new array of the size one-cell-smaller than the original one, and then copies the original elements, except for the spliced out one, into the new array. This is very CPU-consuming when dealing with large arrays, since a new large array is created every time a large array is to be spliced, not to mention the fact that rapid splicing is a fundamental nature of particle engines.

The figure below illustrates the splicing process for ordinary arrays.

Fast-splicing arrays do the job differently. Each of them always keeps the last cell empty, to allow iterators to tell whether they have reached the "tail" of the array, and it double its size when the last empty cell is to be used. Also, each array keeps track of the index of the last occupied cell. When a particle is to be removed from a cell, the last particle is then moved to the now-empty cell, and then the index indicator is decremented, i.e. moved left. No new arrays are ever created for splicing.

The order of the array has been disrupted you say? As long as no mutual action is in place, the order of the array is of no significance. Even if mutual actions are involved, requiring the particles to be sorted according to their x-coordinates, the emitter sorts the array automatically before further processing in this case, so the order is still not problem.

This splicing approach is even faster than linked-list splicing, since it only involves two assignment operations and one integer decrement operation, as opposed to four assignment operations for linked-lists (or maybe more...argh, you do the math).

Moreover, arrays are faster for adding particles, because they simply assign references to their cells, and, on the other hand, linked-lists have to create new nodes to hold references to particles added and subsequent nodes.

I think I don't have to say anything more about the sorting operations. Arrays are the fastest, 'nuff said.

Here's a table that compares the performance of particle adding, traversal, splicing, and sorting operations for different particle containers. I believe that you can clearly understand why I prefer fast-splicing arrays over linked-lists.

Monica WINS!!

2010-05-19T07:40:00.000-07:00

Monica WINS by ~cjcat2266 on deviant ART

Play Monica: Nightmare

It's been too long since I got the third place in the Creative Game Design Contest held by Gamer. Today the finally sent me the certificate for the award. I felt like drawing Monica being excited about the certificate, so here it is :p

Heineken with Zedbox

2010-05-11T08:49:00.000-07:00

Visit site
ZedBox project homepage

I'm happily informed by Milkmidi from Medialand that Mark Vann, also from Medialand, has built a Heineken website using ZedBox, my 2.5D billboard engine.

I've never imagined I could use ZedBox to create such stunning visual experience with massive cans of Heineken beer, although at some points the website does consume a lot of CPU resource. I think the performance could be improved by caching, or pre-rendering, the bitmaps, accounting for their different rotation angles, instead of changing their rotations directly at run-time. Anyway, Mark's definitely done a pretty darn good job on this one.

Nice job, Mark. And thanks a lot for supporting ZedBox :)

My Most Wanted Flash Features

2010-05-11T02:32:00.000-07:00

I've seen a lot of most-wanted-Flash-features articles. So I decided that I might as well write one :p

Full GPU Rendering Support
Currently, Flash Player 10.1 only supports hardware acceleration for the full-screen feature and video playback. I've always wanted to see Flash Player being capable of rendering all the display objects with full GPU acceleration. It'll be a huge boost on the performance. I believe lots of people out there also want this feature very badly.

Function Overloading
ActionScript is the only one among the object-oriented languages I use that does not support function overloading. This can sometimes lead to frustrating experiences while designing frameworks. Sometimes I just want to provide functions with different sets of parameters that do the same job; however, due to Flash's lack of support for function overloading, I have no choice but to use lots of optional wild-card-typed parameters and depend on their types to perform differently in a single function.

Complete Generics Support
The Vector class supports generics. However, I'm talking about COMPLETE generics support. That is, developers are able to write classes with whatever class templates they want, instead of only playing with the little Vector class provided by Adobe.

It is so tempting to write classes with generics. Just imagine if you could write a following generic class:

There'll be no more type casting issues, and the following code is definitely legal.

Data Container Framework
What naturally comes after the generics support shall be a data container framework like that in Java. I hope Adobe can provide a set of containers of basic data structures, such as linked lists, stacks, hash maps, hash sets, etc. Currently the Dictionary class acts like a object-to-object hash map, and is not strongly typed, which requires lots of casting being done. With a generic data container framework, we are able to write code like this:

And it's guaranteed to be type-safe, so you don't have to cast the evaluated value of map["mapSprite"] to Sprite anymore.

I like the Java container framework very much, especially the support for iterators. Iterators make traversing abstract containers even extremely easy and intuitive. I hope Adobe do consider adding a container framework seriously. I know there are already some neat container frameworks out there, like as3ds, but it's always nice to have official support, isn't it?

That's all I've got for now. I'm sure I'll come up with more wanted Flash features.

Loading with Commands

2010-05-07T05:09:00.000-07:00

View tutorial

This is a sequel to my previous tutorial, Thinking in Commands part 1 and part 2.

This time I talked about how to encapsulate external data loading functionalities into commands, so that they can be arranged together with other commands. Also, I've introduced the DataManager class, which essentially acts like a global variable aggregator. However, as Rich pointed out in the comment. This class is not type-safe, thus requiring type casting through the entire application. Actually, I also think this could be a problem for large applications. When I was writing the class, I was thinking of the Proxy class from PureMVC. The class also acts like a global variable aggregator that is not type-safe, since this is how you obtain a reference to a custom proxy object.

Not type-safe as it is, it actually served me quite well in most applications. But yet I agree with Rich that it's not friendly in large applications. Unfortunately, this is the best solution I can come up with right now. I'll see if I can conceive something better in handling data.

New Scripting Engine in Progress

2010-05-01T07:54:00.000-07:00

Yup, I'm currently working on a scripting engine, named Shintaz, which is the name of another character in Rusher's series. You can check out the complete character lineup here.

The motivation is twofold: first, it is my term project for the compiler course I'm taking this semester; second, my ultimate purpose is to integrate this scripting engine with Rusher Game Framework, so that you may open a console, like those where you can enter cheat codes in many Valve games, and enter scripts. This is mostly for testing and debugging purposes.

The project SVN is already opened on Google Code. Here's the source folder and the documentation. I use the ASUnit framework for unit testing Shintaz. You can check out the testing project here.

The scripting engine is still a work in progress. So far, I've finished the scanner. There's still a long way to go, with the parser and virtual machine to be finished.

Here I'll show some code snippets for the scanner.

This is how a scanner is initialized. The parameter passed to the constructor is a string of script, or code.

Tokens of the code can be obtained by repeatedly calling the IScanner.getToken() method until the method returns null. Each token is consisted of a token type, an integer value, and a token value, whose data type depends of the token type. Here's what a piece of actual scanner code would look like.

The Token.toString() method is overridden to show both the token type and token value. This is what will be displayed on the output panel.

That's it. This is my current progress on Shintaz. I'll begin to work on the parser as soon as I can. Hopefully, the entire engine can be completed by the end of this month.

Run Rusher Run

2010-04-18T02:28:00.000-07:00

Run Rusher Run by ~cjcat2266 on deviant ART

This is Rusher, the character Rusher Game Engine is named after. I haven't been drawing him for a very long while, and I felt like trying to draw him in a different style. So here it is, run Rusher run!

Thinking in Commands

2010-03-29T06:28:00.001-07:00

View part 1 of 2

View part 2 of 2

As I developed the Command Utility for Rusher Game Framework, I have come up with this idea of spreading the love for Command Pattern :p

I've already delivered three presentations on this topic, and written a two-part tutorial for ActiveTuts+. In the tutorial I've briefly covered the Command Pattern and showed how to build a minimalistic command framework, which is kind of a lite version of the Command Utility in Rusher. Also, you can find in this tutorial about how to further make use of this command framework to create a scene management framework, which is also a lite version of one of Rusher's features, the State Machine.

The concept of commands would really simplify things out when working on huge projects. If you've got problems dealing with large applications, such as messing up with complicated code that is hard to maintain, just go check out the tutorial. It's gonna help you a lot. I promise :)

Third Place in Game Design Contest

2010-03-23T10:35:00.000-07:00

Play Monica: Nightmare
View all entries

That's right. Monica: Nightmare got the third place in the Creative Game Design Contest held by Gamer. I'm pretty glad that the first game created by Rusher Game Framework could make it this far. Being involved in this contest was the main driving force for me on the development of Rusher. Had it not been for this contest, I think Rusher would have been still a mere idea in my mind by now.

However, I've still got several things to complain about. The graphics and music aspects make up 20% of the total score, and yet the runner-up still got 85 out of 100? I'm not unable to afford to lose. There are reasons why I'm saying this. Come on, the drawing skill is obviously...primitive, consisted of line segments and simple geometric shapes, let alone the fact that the framerate is 12FPS (that's eye-killing, really). And the music is nowhere near original, its background music for the menu scene is from Star Wars; how could Gamer not notice that? After all, use of proprietary assets is prohibited in this contest! I've sent Gamer a mail, requesting that they reveal the score every entry has got on each aspect. I hope they take this seriously; otherwise, just showing the final total score is far from convincing.

Alright, enough with the complaining. At least Monica: Nightmare gets the third place and is being displayed in the first row. This means Rusher is going to get more exposure, which is my ultimate purpose :)

My First Game Built with Rusher Game Framework!

2010-03-08T05:04:00.000-08:00

Play Monica: Nightmare

Finally! My first game built with Rusher Game Framework! Escape from Monica's nightmare as fast as you can!

Monica: Nightmare is a 2D side-scroller evasive action game. You're right, no fancy attack moves. Just run! This is an entry to the Creative Game Design Contest held by Gamer. The theme of the contest is "Escape", hence the absence of attack moves. I tried to make the opening and ending look like it is SOME console game :p

I used Box2D for collision handling. The game flow control is heavily making use of the Scene Manager (now State Machine) feature of Rusher.

You can press the "+ (plus sign)" key to toggle the console panel to view debugging messages, and press the "- (minus sign)" key to toggle the Box2D debug view.

It's still quite buggy, I know. I had been working very hard to eliminate all the bugs, but the deadline did not allow me to do so. I slept at 6 in the morning on the due date and woke up at 8:30 to mail the disk to Gamer. I apologize if the bugs bother you during the gameplay.

Next time I'm gonna use all of my game-related frameworks: Rusher, Stardust, and ZedBox!

Stardust 3D Paritcle Effects Tutorial

2010-03-05T06:17:00.000-08:00

View Tutorial

I've written another Stardust tutorial on ActiveTuts+. This time it's about how to create 3D particle effects with Stardust's native 3D engine and Papervision3D.

To combine Stardust with different 3D engines, all you need to do is use a different engine-specific renderer and initializer for particle appearance. It's well explained in the tutorial. So what are you waiting for? Just go check it out!

Conditional Commands for Rusher Game Framework

2010-02-25T21:51:00.000-08:00

I showed one of my classmates the Command Utility for Rusher Game Framework. He gave me a quick thought about conditional commands, which execute different commands depending of different conditions. I thought the idea was great, so when I turned on my laptop I directly rushed into creating conditional commands for Rusher.

Below are the conditional commands that are now available in Rusher, which is now version 0.5 Alpha.

If Command

The If command executes a "true subcommand" if the return value of the test function is true, otherwise the alternative "false subcommand" is executed. Additional parameters for the test function can be passed as an array.

While Command

The While command repeatedly executes a subcommand until the test function returns false.

DoWhile Command

Pretty much like the While command, the DoWhile command repeatedly executes a subcommand until the test function returns false, except that for the first time the subcommand is always executed regardless of the test function.

For Command

The For command is consisted of two subcommands: the "initCommand" is executed first, then the "loopCommand" is executed repeatedly until the test function returns false.

Switch Command

The Switch command contains a index function, which returns an integer, and an array of subcommands. It executes the subcommand in the array corresponding to the index returned by the index function.

Repeat Command

The Repeat command repeatedly executes a subcommand for a specified number of times. This command basically does not count as a conditional command, but it certainly is equally useful.

Scene Manager for Rusher Game Framework

2010-02-23T23:46:00.000-08:00

The scene manager for Rusher Game Framework is now complete. It makes use of Rusher's Command Utility to achieve scene transitions, i.e. intro and outro.

One engine core contains one scene manager, which is accessed from the Engine.sceneManager property. The SceneManager.setScene() method sets the current scene for the engine core. The scene transition is handled by the Scene.introCommand and Scene.outroCommand properties. When the engine core is switching from scene A to scene B, the outro command of scene A is executed, the intro command of scene B is executed, and then finally the scene transition is complete. This scene transition command structure was inspired by Progression Framework.

Here are some code snippets for the scene transition. You can view the final result here. Click the black square and watch the scene manager do its work.

The document class is quite simple. It starts up the engine core and sets the scene to a HomeScene object.

And below is the code for the HomeScene class. It extends the Scene class and assigns two command objects to the introCommand and outroCommand properties. The _block property simply holds a reference to a Sprite with a square appearance.

The intro command makes the block fade in from zero alpha and a random position to another random position, while the outro command fades out the block to zero alpha and another random position.

The AddChild command adds the block to the container sprite. The TweenNanoFrom command is making use of the from() method of the TweenNano class from GreenSock Tweening Platform. The Trace, SetProperties, AddEventListener, RemoveEventListener commands do what their name suggest: tracing messages, setting properties, adding event listeners, and removing event listeners, respectively.

When the block is clicked, the scene tells the SceneManager to switch to another scene, in this case, still another HomeScene instance.

There are more commands integrated with GreenSock Tweening Platform not shown in this example: TweenLiteFrom, TweenLiteTo, TweenMaxFrom, and TweenMaxTo. I believe their names tell you everything about what they do.

I'm quite happy with how the Command Utility turned out. Managing how the program flow by using parallel and serial commands is very easy, and, more importantly, it is achieved with simple, clean, and readily maintainable code.

Command Utility for Rusher Game Framework

2010-02-21T01:36:00.001-08:00

I've added a Command Utility to Rusher Game Framework. Each engine core now has a reference to a CommandManager object; this object allows you to execute commands, be it single commands or composite commands.

There are two types of composite commands: ParallelCommand and SerialCommand. The parallel command executes all its subcommands simultaneously, while the serial command executes its subcommands sequentially. Also, each command has a delay property (the time a command "waits" before execution), which you may make use of to have advanced control over the command execution timing.

Here are some code snippets for Rusher's Command Utility.

This TraceCommand class is a very simple command consisted of a delay time and a trace message. Note that the execute() method is where all your command goes, and the complete() method should be called when the command is finished.

Here's the document class. The two commands "ps" and "sp" are a parallel command with a serial subcommand and a serial command with a parallel subcommand, respectively. The first constructor parameter of the parallel and serial commands is the delay time, and the subsequent parameters are subcommands.

This shall trace out "ps0", "ps1", "ps2", "ps3", "sp0", "sp1", "sp2", and "sp3" sequentially with a time gap of one second. The complete source code for this example can be found here.

One engine core is supposed to be used for one game level, or one scene in a game. I'm aiming for creating a utility for handling the entire game, including opening, menu screen, main game, ending, credits, etc. The Command Utility is just one part of it. You can think of it as something similar to Progression Framework.

Arrow Walker Example for Rusher Game Framework

2010-02-12T17:56:00.000-08:00

Oooh. Look at the fresh new logo I made :p

View SWF
View source

I've written a tutorial on the basic usage of PushButton Engine. It demonstrates how to create a simple 2D arrow-key-controlled game character (well, if you'd call an arrow a character).

This time I'm going to recreate the exact same example, but using Rusher Game Framework, which is my own experimental game engine inspired by PushButton Engine.

This is the document class. The Player entity is the keyboard-controlled character, and the Scene entity is in charge of update the arrow display object's position and rotation according to the Player entity's 2D spatial data.

The engine core with the key "main" is obtained through the Engine.getInstance() method. Entities are added to the engine through the Engine.addEntity() method. The Engine.stage property must be set to a valid Stage reference in order to enable keyboard and mouse signal capture. And the engine core's main loop is invoked repeatedly through the Engine.clock.tick() method, by the enter-frame event.

This is the Player entity class, consisted of three components: 2D spatial data, render target, and controller.

The 2D spatial component contains data for position, rotation, and scale, while the scale data is not used in this example.

The render target component holds a reference to a target display object whose position and rotation will be updated according to the spatial data, accomplished by setting the render target component's positionRef and rotationRef properties to PropertyReference objects that reference the spatial data by name. The useOwnContainer property is set to true, so the display object remains in its original container set up in Flash IDE, instead of being added to the renderer's internal container sprite.

The controller component listens for keyboard signals and updates the 2D spatial data accordingly.

This is the Scene entity, which is pretty much consisted of a single component: the renderer component. This component updates the spatial value of display objects referenced by render target components.

Here's the Controller component that updates the arrow's position. The onTick() method declared in the ActiveComponent superclass is invoked on each main loop call. The engine property is a reference to the engine the owner entity is added to.

Note that the s variable is set the a value of SPEED * time. The time parameter passed to the onTick() method is the elapsed time between two main loop calls in seconds. Multiplying the SPEED constant by time, the arrow will be moved at the speed of 400 pixels per second, independent of the frame rate. So if the frame rate is set to, say, 30 fps, instead of the original 60 fps, the arrow will still move at the speed of 400 pixels per second.

Okay, this is kind of the basic usage of 2D spatial data, render targets, renderers, and active components for Rusher Game Framework. Next time I think I'll post some sample code for using Rusher's Box2D package.

Rusher Game Framework

2010-02-12T08:28:00.000-08:00

I have been very quiet lately. That's because my friends and I are busy preparing for the Creative Game Design Contest held by Gamer. The theme of the contest is "Escape", and that's the only limitation. There's no limit on the game genre and gameplay.

Originally, I was thinking of using PushButton Engine. However, as Ben Garney, the creator of PushButton Engine, points out in the forum, that he is still working on transforming the engine from single-core to multi-core. My game requires a multi-core game engine, so I decided to develop a light-weight component-based experimental game engine myself. This is the advent of Rusher Game Framework. There's no stable build available in the Downloads section, but you can grab the latest revision from the SVN repository. There are two primitive examples available in the "tests" folder.

The name Rusher comes from a character I designed when I was in high school. Here's what Rusher looks like. Rusher is still in alpha, and I think it'll become beta after we release our game.

Since Rusher is component-based, it's rather easy to extend custom functionalities. Rusher already has a built-in Box2D component package, which works with Box2D 2.1a, the latest version. I developed this Box2D package because we're working on a 2D platformer.

Here I'll briefly demonstrate some code snippets for Rusher.

Similar to the Multicore version of PureMVC, each core is referenced by a key. The Engine class servers as the facade of the game framework, pretty much like the Facade class in PureMVC. The getInstance() method is how you get a reference to an engine core.

Instead of providing something like a start() method, I'd prefer make the user call the main loop function manually, just like what I did for Stardust. Each engine core has a reference to a Clock object. The Clock.tick() method must be called repeatedly to keep the engine running. This method can be directly used as an event listener, just like the Emitter.step() method in Stardust.

The Entity class represents a game entity, be it concrete as a character or abstract as a game scene. An entity is consisted of multiple components, each representing a basic module of data or behavior. The ActiveComponent class represents a behavioral component that is to update the entity repeatedly. The ActiveComponent.tick() method is called in each main loop iteration. For this to work, the entity must be added to the engine.

Each component has a name property, so that it can be referenced by name. One entity cannot possess two or more components with the same name. To reference the data (or properties) of a component from another component, the PropertyReference class is used. The concept of the PropertyReference class is actually from PushButton Engine. Referencing components and properties by name is very convenient and flexible. For instance, you can swap a component containing 2D spatial data with another special component with 2D spatial data, which works with Box2D, not interrupting the 2D rendering components which reference the 2D position data by name.

Alright, this is pretty much I can say about Rusher so far. I'll post more details about Rusher once it's matured.

Let's Shoot Some Stars with Stardust!

2010-01-25T05:11:00.000-08:00

View article
Stardust project homepage

Finally, my Stardust tutorial article has been published on ActiveTuts+. They must have been very busy there at ActiveTuts+, since I had waited one week after the submission of the article for an acknowledgement and another week before it got published.

If you are interested in Stardust and are too lazy to go through the nearly 50-page PDF manual, you might want to check this article out. It's short, and yet after reading it you'll be able to create particle effects with Stardust!

I'm planning on writing more articles in the future about custom initializers/actions/renderers, 3D particle effects, and XML serialization.

Stardust Umbrella & Depth of Field

2010-01-15T09:01:00.000-08:00

View Blog Post

I just came across two Stardust demos that are pretty neat. The first one was made by Hasegawa (name spelling corrected, sorry about that :p), using a circle deflector to simulate umbrella blocking snow. The deflection looks quite nice. It's the first demo I've found to use objects other than just a boring circle to make circle deflectors look tasty. By the way, there's somehow a huge performance difference for Stardust deflectors between the Release version and Debug version of Flash Player. The Release version performs better than the Debug version. On my laptop, the performance difference for this demo is almost 50%.

View SWF & Source

The other demo is created by paq on WonderFL. This demo uses plane deflector in combination with Papervision3D to create this bouncing-planes-with-depth-of-field effect. Note that the main class extends the ReflectionView class provided by Papervision3D, which makes the demo even more beautiful.

Stardust v1.1 - Now with Linked Lists

2009-12-26T11:31:00.000-08:00

Stardust project homepage
Particle collection documentation

After a few days of struggle, I've finally done it! Now Stardust implements linked lists internally for particle collections instead of arrays. Linked lists are better than arrays for rapidly adding and removing elements at random positions, theoretically. I found the performance to remain pretty much the same after this major change. However, the internal particle list implementation is now hidden from clients, which makes it much safer, preventing direct access to the particle array as in version 1.0.

To iterate through particles in a particle list, you use the ParticleIterator interface. You shall be familiar with this interface if you have worked with the C++ STL library or the Java collection APIs.

I'll illustrate this iterator interface by some sample code. Here's how you set all the particles' positions in an emitter to (0, 0), the origin.


var particles:ParticleCollection = emitter.getParticles();
var iter:ParticleIterator = particles.getIterator();
var particle:Particle2D;
while (particle = iter.particle as Particle2D) {
    particle.x = particle.y = 0;
    iter.next();
}

And this is how you add completely-customized particles to an emitter.


var particles:ParticleCollection = new ParticleList();
for (var i:int = 0; i < 100; i++) {
    var p:Particle2D = new Particle2D();
    p.x = 100 * Math.random();
    p.y = 100 * Math.random();
    particles.add(p);
}
emitter.addParticles(particles);

Pretty clean and self-explanatory code, isn't it? I'm quite satisfied with how the interface ended up. From now on, I can tweak the internal implementation and algorithm of the particle list without having to change the code outside of the black box. Gosh, I should have done this long ago.

Stardust Video Tutorial - More On The Main Loop

2009-12-22T08:44:00.001-08:00

View Video
View playlist
Stardust project homepage

It's been a long time since my last update for Stardust video tutorial. Thanks a lot to Clockmaker - his article introducing Stardust gave me a great motivation boost to get down to recording more new vids. Clockmaker inspires me a lot, including tilting illustrations in blog articles for 5 degrees :p

This video covers more in-depth details on the main loop, including emitter events, initializer/action priorities, and particle masking, which are very important must-knows if you really want to do some serious coding and complex behavior handling with Stardust.

Clockmaker's Stardust Butterfly Demo

2009-12-21T05:20:00.000-08:00

View Clockmaker's article & demo
Stardust project homepage

I'm very honored to come to know that Clockmaker, one of my favorite Japanese ActionScripters, has gotten his hands on Stardust! He's created a couple of awesome Stardust demos at Wonderfl, a Japanese ActionScript community that provides online Flex compiling service. You don't have to have the Flex compiler to test your ActionScript code: just type the code on the website and see it work the magic on the fly, literally. You can check out his demos in his Wonderfl gallery.

Clockmaker's Stardust Butterfly demo is very, very astonishing. The glow effect, the fluid butterfly motion, and the reflection...they've all left me in silent awe. Just watch the demo on his blog and you'll know that I'm not joking!

Boundary Collision Sparks

2009-12-12T04:21:00.000-08:00

View SWF
View source
Stardust project homepage

That's it. I've always wanted to create an action trigger that is triggered by "collision" with a deflector, or "deflection" with a deflector not acting as an obstacle. Now I've finally got it done :)

The magic behind the scene is quite simple: the Deflect class is modified so as to map a deflector to a boolean value, a flag for determining if a "collision" or "deflection" has occurred, through a dictionary object; the DeflectorTrigger class then simply check the flag to determine if the trigger is triggered.

However, extra caution is now required when creating custom deflectors. If you decide that a deflector does not "deflect" a particle, the overrided calculateMotionData4D method must return a null value instead of a "new MotionData(particle.x, particle.y, particle.vx, particle.vy)" copy of the particle's original position and velocity, which tells the DeflectorTrigger class that it should not be triggered.

My next target should be creating a trigger that can detect interparticle collision, which would not be an easy task. Well, it's easy, but what I mean is that it's not going to be easy to implement it with action trigger structures; at least now I don't have the slightest idea about how to do it. I'll try and figure out a way to do it cleanly and efficiently.

Stardust + ZedBox Example: Duo Firewheel

2009-12-10T02:52:00.000-08:00

View SWF
View source
Stardust project homepage

I've always felt like the ZedBox extension for Stardust has been left out for quite a while, so today I decided to spent some time revising the extension by improving the performance, and add a couple of new features, one of which being the ZBBillboardOriented action, which is essentially a ZedBox version of the BillboardOriented action.

This example demonstrates the use of the ZBBillboardOriented action and the use of a custom gravity fields, the VortexField3D class. It also makes use of what the native Stardust 3D engine cannot do: hierarchical object structures. The two wheels are actually rotated "disk" ZedSprite objects added to the display list of a parent ZedSprite. These two disks originally lied on the XZ plane ,Y axis being the horizontal axis on the screen.

I'm planning on using the ZBBillboardOriented action heavily on one of my personal projects. I'll bring it into public once it's finished.

Asynchronous Computation

2009-12-07T00:51:00.000-08:00

Trevor McCauley's article about asynchronous ActionScript execution provides a brilliant way to distribute CPU-consuming computation from one frame to multiple frames. I was so excited when I first read this article, eager to try it out so much, and finally, today I had the chance to give it a try.

One of my classmate was working on a project for a course on social networks. He used ActionScript for his project, trying to parse an XML file representing a graph of over 80 thousand nodes and reconstruct the graph using his own classes. If you, whether intentional or not, had somehow make your Flash program enter an infinite loop, you might know that Flash Player throws a time-out error if a single frame takes more than 15 seconds to render.

His XML file was so big that even parsing it from string to the AS3 internal XML type took a couple of seconds, let alone instantiating his own classes representing nodes and edges for that graph, and as I expected, he was faced with the 15-second-error nightmare.

I applied Trevor's idea to solve this problem by factoring out the instantiation of his classes and distribute it across multiple frames, and things worked out perfectly and beautifully!

Thanks Trevor. Love you :)

Here's some code snippet:


//loader for loading external XML file
var loader:URLLoader = new URLLoader();
loader.addEventListener(Event.COMPLETE, onLoad);

//start loading the XML file
loader.load(new URLRequest("myXML.XML"));

//XML variables
var xml:XML;
var nodes:XMLList;
var edges:XMLList;

//graph model
var graph:Graph = new Graph();

//asynchronous computation variables
var currentIndex:int; //this index keeps track of the progress of asynchronous computations
var length:int;
var startTime:int;
var allcatedTimePerFrame:int = 16; //approximately 60fps

//loader complete event handler
function onLoad(e:Event):void {
    xml = XML(loader.data);
    nodes = xml.node;
    edges = xml.edge;
   
    //initialize asynchronous computation variables
    currentIndex = 0;
    length = nodes.length();
   
    //start building nodes asynchronously
    addEventListener(Event.ENTER_FRAME, buildNodes);
}

//asynchronous computation for building nodes
function buildNodes(e:Event):void {
    //take a snapshot of the current time
    startTime = getTimer();
   
    for (var i:int = currentIndex; i < length; i++) {
        //build nodes in the graph model
        graph.createNode(nodes[i].@name);
        currentIndex++;
       
        //check if the computation is complete
        if (currentIndex == length) {
            //stop this listener
            removeEventListener(Event.ENTER_FRAME, buildNodes);
           
            //initialize asynchronous computation variables
            currentIndex = 0;
            length = edges.length();
           
            //start buliding edges
            addEventListener(Event.ENTER_FRAME, buildEdges);
            return;
        }
       
        //check if the time spent on this loop exceeds the allocated time per frame
        if (getTimer() - startTime() > allocatedTimePerFrame) {
            //display the current progress in a text field
            progress_txt.text = "building nodes: " + 100 * (currentIndex / length) + "%";
            return;
        }
    }
}

//asynchronous computation for building edges
function buildEdges(e:Event):void {
    //take a snapshot of the current time
    startTime = getTimer();
   
    for (var i:int = currentIndex; i < length; i++) {
        //build nodes in the graph model
        graph.createEdge(edges[i].@node1Name, edges[i].@node2Name);
        currentIndex++;
       
        //check if the computation is complete
        if (currentIndex == length) {
            //stop this listener
            removeEventListener(Event.ENTER_FRAME, buildEdges);
           
            //we're done!!
            //display the graph on the stage
            graph.buildView();
            addChild(graph.getView());
           
            return;
        }
       
        //check if the time spent on this loop exceeds the allocated time per frame
        if (getTimer() - startTime() > allocatedTimePerFrame) {
            //display the current progress in a text field
            progress_txt.text = "building edges: " + 100 * (currentIndex / length) + "%";
            return;
        }
    }
}

Synchronized Movie Clip

2009-12-03T01:04:00.000-08:00

View SWF
View source
Stardust project homepage

The new SynchronizedMovieClip class is a StardustMovieClip subclass, which is for "time step synchronization" I mentioned in this article. In this demo you can notice that there's a slider bar for tweaking the time scale of the particle simulation (which tweaks the Emitter.stepTimeInterval property).

In the absence of the SynchronizedMovieClip class, the movie clips will play at the original speed even if the simulation time is scaled down, which is pretty logical since the frame rate is not changed, only the internal time scale for simulation changed.

Now the movie clips are SynchronizedMovieClip instances and the emitter has a StardustSpriteInit initializer and StardustSpriteUpdate action added to it, the movie clips can be synchronized with the particle simulation time scale. The StardustSpriteInit initializer stops the movie clips at the very beginning by calling the init() method defined in the IStardustSprite interface, which the StardustSpriteMovieClip class implements, and the StardustSpriteUpdate action sets the movie clips' frames according to the simulation time scale through the update() method, also defined in the IStardustSprite interface.

This is how the synchronization of movie clips and Stardust particle simulation is done.

Stardust Movie Clip

2009-12-02T00:13:00.000-08:00

Stardust project homepage

If you've played with Stardust for a while, you might notice that there's an Emitter.stepTimeInterval property which allows you to dynamically adjust the particle simulation timescale. Here's one demo showing you the adjustable timescale feature in action.

Now that you can adjust the timescale of particle simulation, the next problem is how to synchronize your movie clips with the timescale.

Originally, there was only a StardustSprite class that extends the Sprite class. My original intent was simple: allow a display object to respond to each Emitter.step() method call and to have access to timescale information, in turn updating itself correspondingly. If a particle's display object is a subclass of the StardustSprite class, and the emitter has a StardustSpriteUpdate action added to it, then the display object's update() method is invoked upon each emitter step, with a reference to the emitter, timescale information, and a reference to the particle's data passed in as parameters.

In order to synchronize movie clips with the dynamically adjusted timescale, I wrote the StardustMovieClip class, which pretty much is just a movie clip version of the StardustSprite class, and I extracted the update() method into a separate interface, the IStardustSprite interface. Now if you use a movie clip that extends the StardustMovieClip class for the particles and add the StardustSpriteUpdate action to the emitter, you can handle timescale change by overriding the update method() in your class. I'll write a base class just for this purpose when I have time. But for now, you can try it yourself if you're interested.

Another addition to the StardustSprite family is the IStardustSprite.init() method. My original intention was to provide a way to "reset" recycled display objects for particles initialized by the PooledDisplayObjectClass. Since used display objects are recycled into a pool and taken out again for future use, they indeed need a way to reset themselves when they are taken out from the pool and used again. For instance, you might want reset the playhead of your movie clips back to the first frame. To invoke the IStardustSprite.init() method, add the StardustSpriteInit initializer to the emitter.

Pooled Display Object Initializer for Stardust

2009-12-01T23:49:00.000-08:00

Stardust project homepage

One of the major CPU consumption cause of Stardust is the display object instantiation, since new display objects are created rather rapidly along the particle simulation. So I think using an object pool to store display objects that are no longer needed for future use is a nice way to improve performance.

The new PooledDisplayObjectClass and PooledDisplayObjectClass3D initializers are "pooled" versions of their counterparts, the DisplayObjectClass and DisplayObjectClass3D initializers, respectively.

I've run a quick performance test, and found that when using the PooledDisplayObjectClass initializer to initialize particles with display objects, the performance improves by approximately 10%~15%, compared to the original DisplayObjectClass initializer. It's not a significant improvement, but at least it's better :)

Pyronova 1.0 Beta & Butterfly Example

2009-11-18T00:00:00.001-08:00

Pyronova project homepage
View documentation

I lied. I cannot wait until my midterm ends to finish Pyronova :p
Now it's in 1.0 Beta, and supports XML serialization.
Also, it's currently half-documented. I'll complete the documentation ASAP.

I've created this example combining Pyronova and Stardust. I think the outcome looks pretty nice :)

View SWF

The logics behind this effect is rather simple: the butterflies are created using Stardust (well, that's another story); the HueNode shifts the hue of the butterflies, and the BlurNode blurs the butterflies to create the glowy effect.

Pyronova Logo

2009-11-17T08:54:00.001-08:00

Pyronova project homepage

View logo in full size

Whew, I'm kind of all-thumbs with Illustartor. It took me quite a while to get this lousy logo done :p

How do you think?

New Project for Post-Processing FX

2009-11-13T10:31:00.000-08:00

View SWF

I'm starting a new project called Pyronova, which is a post-processing FX framework. It features a network-based design, which allows you to connect "Pyro nodes" as you like to create your own post-processing effects. The project is still under development, so the source you find in the repository is just its prototype.

Here's the network diagram for this example.

A BitmapDataNode represents a BitmapData object. A PerlinNoiseNode generates Perlin noise bitmaps. A DisplacementNode takes two inputs: one regular input and one as a displacement map. A BlurNode, as its name suggests, blurs a bitmap up. A RedrawNode redraws a bitmap with additional settings such as transformation matrices and color transforms. "Pyro layers" are final destinations for post-processing networks, each layer having one single root node as its "final appearance".

In this example, a BitmapDataNode is used to hold reference to the Bunny-In-Black (BIB) bitmap data. The BlurNode blurs the BIB bitmap (previously processed by the DisplacementNode with Perlin noise distortion) and then pass it to the RedrawNode. The RedrawNode is assigned a ColorTransform object with RGB multipliers of values 1.3, essentially lightening things up. Finally, Layer 2 presents this final "blurred and lightened-up" bitmap and is assigned an ADD blend mode, serving as a "glow overlay" to the original bitmap, which is displayed through Layer 1.

Here's some sample code that sets up the network:

I'll push this project into Beta as soon as possible.

PushButton Game Engine Example: Arrow Walker

2009-11-08T08:26:00.000-08:00

View SWF
View Source

This example is my first attempt to try out PushButton Engine, an AS3 component-based game engine. I must say that the guys working on this project really have done a fantastic work. This engine is highly flexible, highly extensible; moreover, it supports XML serialization and advanced asset management (such as run-time loading).

In a component-based game engine, everything is regarded as an entity, be it as concrete as characters, obstacles, or as abstract as scene, renderer. If, you might ask, everything is regarded as equal, how may their behaviors differ? The answer is component. Each entity can possess different set of components, which can store properties like position, and carry out behaviors such as moving. This component-based structure would solve the problems present in inheritance-based designs. If you are interested what problems can be caused by inheritance-based designs, you can check out this video by Ben Garney, the lead developer for PushButton Engine.

Alright, that's enough for the introduction. Now let's get down to the example. This example , called Arrow Walker, is basically just an arrow that can move around, controlled by the arrow keys.

NOTE: This example is built with the latest PushButton Engine, revision 615 so far. And the code shown in this post is partially stripped out and modified from the original source for clarity. You can check out the complete source code here.

First off, use the PBE.startup() method to start up the engine. This method essentially tells the engine which Stage instance is the main stage. Then for a most minimalistic example, at least a scene and an object are needed. In this example, I split the codes for these two entities apart for clarity (the setupScene() and setupArrow() method).

The allocateEntity() method is the method that must be used whenever you want to create a new entity.

Now lets look at the setupScene() method. All that we need for a scene is a DisplayObjectScene component. This component renders entities with a spatial component, which stores spatial information including position and rotation, and a DisplayObjectRenderer component. A SceneView object is a sprite the renderer can render onto.

Next, let's look at the setupArrow() method. The DisplayObjectRenderer component points to a movie clip named arrow_mc, which would be constantly rendered by the scene entity after the DisplayObjectRenderer component is added to the DisplayObjectScene component of the scene entity. The PropertyReference objects tell the renderer to query a specified spatial component for position and rotation information. For instance a property reference with a string "@spatial.position" assigned to it tells the renderer to look for a component named "spatial" and check the component's "position" property, in order to obtain the entity's position information. The same logic applies to a property reference with a string "@spatial.rotation" assigned to it.

Finally, let's look at the SimpleController component, which controls the arrow's moving behavior and handles border conditions, confining the arrow within a 640x480 rectangle region. This component extends the TickedComponent class, whose onTick() method is called every "frame". The _keyMap property is a dictionary object for storing key data (whether a key is pressed). You can check out the source code for this class to see it's complete implementation.

Note that the "frame" here doesn't mean the frame in Flash Player, but the PushButton Engine's own internal frame system handled by the ProcessManager class. It's designed this way so that the game's numeric data can update independently of the Flash Player's current framerate.

Alright, we're done. You can view the result here and check out the source code here.
For those advanced PushButton Engine users, this example seems to be way too easy.
But for those who are interested in this engine and are about to try it out, I hope this example helps understand the basic usage of PushButton Enigne.

Stardust Video Tutorial on Actual Coding

2009-11-04T08:47:00.000-08:00

04 - Basic Workflow part 1
05 - Basic Workflow part 2
View Complete Playlist

Stardust project homepage

At last, the video tutorials have begun covering actual coding. If you've watched the video of my speech for the 2009 PTT Flash Workshop, you might have noticed that I used a tablet to hand-write in OpenCanvas, using it as a digital whiteboard. The second half of the 4th episode of the video tutorials is actually a remake of the whiteboard hand-writing, in a form of an *cough* elaborate *cough* PowerPoint animation.

Enjoy :)

Stardust Video Tutorials!

2009-11-01T08:19:00.001-08:00

01 - Introduction
02 - Class Responsibilities
03 - Getting Started

Stardust project homepage

Finally! I've started recording video tutorials for Stardust.

This is my first time trying to use PowerPoint in video tutorials. I think using premade slides does make the videos look better, and, more importantly, helps me remember what I should say :p

I haven't gone to the parts where actual coding takes place, but still, these videos are worth watching, since they give you a full understanding of Stardust features and class responsibilities.

My Speech on Stardust for PTT Flash Workshop 2009

2009-10-26T09:31:00.000-07:00

Actually this workshop was held a couple of months ago (Aug 31st to be specific).

PTT is the most popular bulletin-board system in Taiwan. This workshop was for the PTT Flash forum members and people from the Taiwan RIA industry. I gave an one-hour speech on Stardust for this workshop. And here's the vid: WATCH VIDEO.

This was a workshop in Taiwan, so I spoke in Chinese :p
I'll start recording video tutorials on Stardust in English as soon as I have time.

Stardust Tutorial And Examples by Matt Eley

2009-10-22T08:59:00.000-07:00

Matt Eley has recently written a tutorial and some examples for Stardust!
Thanks a lot, Matt :)

View tutorial

Check it out! Matt has written this very detailed tutorial on the nitty-gritty of Stardust. He covered all the things you need to know to build a Stardust particle effect from the ground up, including initializers, actions, emitters, clocks, and renderers. I think reading this tutorial might help learning Stardust even more easily than reading the Stardust Manual. It's probably because I'm not a native English speaker...oh well, this gives me a rather nice motivation to practice English harder :p

View example

In this example, Matt showed the magic of combining bitmap filters with Stardust, creating this fantastic glowy spaceship thruster effect.

View example

I have to admire Matt for creating this example. He's done a brilliant job on integrating Stardust with Papervision3D, using particle effects to bring 3D Flash into an even higher level!

Thinner Builder, Smaller Stardust

2009-10-22T08:22:00.000-07:00

Stardust project homepage
Stardust Manual (PDF)

I should have done this long time ago.

As listed in the feature list, Stardust supports XML serialization. The XMLBuilder class is in charge of converting a particle system to XML representation and reconstructing a particle system from a give XML representation.

How does the XMLBuilder class know the mapping from an XML tag's name to an actual Stardust class? The answer is the registerClass(), registerClasses(), and registerClassesFromClassPackage() methods. The XMLBuilder relies on these methods to acquire the knowledge of which XML tag name maps to which actual class.

These methods have to be called by the programmer: the more classes you wish the builder to build from XML data, the more classes you must register. The more classes you register, the larger the compiled file size, since more classes are linked together.

The registerClassesFromClassPackage() method is worth mentioning in particular. Subclasses of the ClassPackage class, which is essentially a collection of classes for convenience, all override the populateClasses() method to populate the classes (an array) property with class references. The registerClassesFromClassPackage() would register all the classes in a ClassPackage object in just one line of code. There are already several build-in class packages at your disposal: CommonClassPackage, TwoDClassPacakge, ThreeDClassPackage, ZBClassPackage, PV3DClassPackage, and ND3DClassPackage. All these class packages provide a getInstance() method to return a singleton object, since it's not necessary to instantiate a collection with a fixed set of elements yourself.

Class packages are convenient. But please beware: it's very likely that you would not use all the classes in a class package during XML deserialization, thus wasting some file size. It doesn't matter when the file size is of no concern; however, when you are working with a file-size-sensitive project, such as banner, file size becomes critically. In such circumstances, I would highly recommend you register classes one by one through the registerClass() method, just registering the class you would like to use when deserializing from XML data.

Originally, the XMLBuilder class registers the CommonClassPackage, TwoDClassPacakge, and ThreeDClassPackage by default. I've removed this default action in the latest revision (1.0.110 Beta), which I should have done long time ago.

You can see this class registering process in action in the 6th step of the XML reconstruction example in the Stardust Manual on page 41, which I just updated today.

CJLibrary Java - Client/Server and Signals

2009-10-12T11:20:00.000-07:00

I chose Java as primary language for my Internet & Multimedia Lab class, and I decided to start the CJLibrary Java project. Eventually, I'll port some useful code from my CJLibrary (for AS3) to CJLibrary Java.

Here's the documentation for CJLibrary Java.

Currently the project mainly consists of the idv.cjcat.net and the idv.cjcat.signals packages; the former is for client-server connection and the latter is an Observer Pattern framework inspired by Robert Penner's AS3 Signals project.

The idv.cjcat.net package encapsulates complex client-server connection handling and exposes a set of user-friendly interface, including the use of the idv.cjcat.signals package.

Here's a quick look at how the idv.cjcat.net package works.

//creates an EchoServer object and starts the server on port 2266
Sever server = new EchoServer(2266);
server.start();

//creates two clients that connects to the server
Client client1 = new EchoClient();
Client client2 = new EchoClient();
client1.connect("localhost", 2266);
client2.connect("localhost", 2266);

Note that the Server and Client classes are both abstract. You have to extend them to create concrete subclasses. The createListener() method is the only method that has to be implemented. In this method you should return your desired SocketListener object, which is also abstract and whose mainLoop() method should be implemented.

Here's the EchoServer class:
(Sorry for the ugly intending. I'm still unable to get the code highlighter to work properly.)

public class EchoServer extends Server {
public EchoServer(int port) {
 super(port);
}
@Override
protected SocketListener createListener() {
  return new EchoSocketListener();
}
}

As you can see, this concrete class is only overriding the createListener() method to tell this server which socket listener it should use, which listens to socket input.

The same logic is the same for the EchoClient class:

public class EchoClient extends Client {
@Override
protected SocketListener createListener() {
  return new PrinterSocketListener();
}
}

Now let's take a look at the EchoSocketListener, which sends back, i.e. echoes, whatever it receives.

public class EchoSocketListener extends LazySocketListener {
public EchoSocketListener() {
  onReceive().add(new SignalListener() {
    @Override
    public void update(Signal signal) {
      getWriter().println(signal.getMessage());
    }
  });
}
}

This class extends the LasySocketListener class instead of SocketListener, because the LasySocketListener class further encapsulates the socket IO, providing a getReader() and getWriter() accessors to give user an even easier way of socket IO handling.

This class also demonstrates the usage of the idv.cjcat.signals package. The onReceive() accessor returns a Signaller object that dispatches signal objects of the Signal class. The add() method adds a listener that listens to signals of the Signal class, therefore the listener must implement the SignalListener interface and implement the update(Signal signal) method. This listener object simply tells the writter to print whatever message the signal is containing, which is the direct message sent over by the other end of the socket.

Finally, here's the PrinterSocketListener class for the client, which simply prints out whatever message received.

public class PrinterSocketListener extends LazySocketListener {
public PrinterSocketListener() {
  onReceive().add(new SignalListener() {
    @Override
    public void update(Signal signal) {
      System.out.println("client received: "+ signal.getMessage());
    }
  });
}
}

Now in the main program, the following additional lines of code would cause the two clients to send messages to the server and receive messages that are echoed back.

//sends messages to the server
client1.send("Hello. I'm client #1.");
client2.send("Hello. I'm client #2.");

And this is what you'll get from the console output:

Hello. I'm client #1.
Hello. I'm client #2.

These are messages that are echoed back by the server, and the order might be reversed, since the two clients have independent socket listener threads.

Star Fish - A Game That Uses Stardust

2009-09-24T09:12:00.001-07:00

Play this game
Stardust project homepage

Richard Davey created this fantastic game. The gameplay is very smooth, and the graphics is very appealing. The game rule is rather simple: get all the starfishes without hitting other fishes.

The bubbles in the background is created with Stardust Particle Engine. The bubble's motion is controlled by a Gravity action and a RandomDrift action. When the bubbles hit the stage boundary, they're killed by the DeathZone action with a RectZone as the death zone. Richard also added a little details to the bubbles in the menu scene: the bubbles bounce off the fish upon collision. This is probably achieved by using a CircleDeflector that follows the position of the fish.

Cute as the fishes may seem, the game is actually kind of hard to play as it gets to later levels, or it's just because I suck at playing games :p

Brilliant Fireworks

2009-09-23T12:39:00.000-07:00

View SWF and source
Stardust project homepage

This is my entry for the 3rd WonderFL Checkmate Contest.

What could be better than a fireworks effect to show the power of Stardust?

I've subclassed an initializer (or spawn action) and an action for each of the four particles: Seed, Streak, Fireworks, and Spark. I've also extended the Renderer class to create a LineRenderer class, taking charge of drawing particle trails.

I think this is a good example to demonstrate the flexibility and extensibility of Stardust.

Stardust Now Available on WonderFL

2009-09-09T11:42:00.001-07:00

WonderFL homepage
Stardust project homepage

Yep, you're right. Stardust is now available on WonderFL!!
I've created a couple of easy examples. You can check them out here.

Being in a rush, I only created 2D examples.
I'll be working on some 3D examples when I have enough time :p

Particle Snapshot Restoration

2009-09-07T10:12:00.000-07:00

View example
Stardust project homepage

Click anywhere in the demo to explode particles, and click the "Restore Image" button to see the magic of snapshot restoration!

I mentioned this "snapshot" restoration stuff on my previous blog post.
This feature is now complete. You can grab it from the SVN repository.

The logics behind are pretty simple: the Snapshot class stores particle states (i.e. "snapshots") using an internal VO (value object) class, SnapshotData, and the SnapshotRestore class simply uses the easing equations to tween particles back to the previous taken snapshots.

I've also provided a ParticleRestoreFlag class for you to specify whether you want to restore the positions, rotations, scales, or more than one of these properties of the particles.

Left Out Stardust Template: Random

2009-09-04T09:36:00.000-07:00

Get Stardust templates for FlashDevelop
Stardust project homepage

Oopsy. I just found out that I've left out a template for the Stardust template pack for FlashDevelop: the Random template. I've added the template and committed it to the SVN repository.

And for some info on the Stardust current development, I'm now working on a "snapshot" functionality for Stardust, which allows you to take "snapshots" of the current particle states, and then tweening particles back to this state afterwardg. You can optionally choose your restoration to work on position, velocity, rotation, angular velocity, or scale, and you can choose the easing equation at work as well.

My motivation for this functionality came out of a talk with Mark Vann from the ActionScript division at Medialand, back in the middle of August. He said he would like to create an effect using Stardust, causing shattered pieces of a bitmap to regroup. It involves no pro coding to create such effect, but he would like to have it done in Stardust; so I'm working on it now, trying to push the limit of Stardust another step further.

Linked List Failure for Stardust

2009-09-01T11:15:00.001-07:00

Stardust project homepage

This is my second attempt to try using a linked list for particle engine. The first attempt was for Emitter, and this time it's for Stardust.

Theoretically, a liked list data structure is the best choice for a particle engine. Linked lists are well-known for their efficient removal of arbitrary nodes from the list. There's no way knowing the dying order of particles in a particle list, hence no way knowing the order of particle removal from the list. It seems that using a linked list for a particle engine's particle list is a good idea, but after my experiments, it turned out not to be the case.

I've tried to use a linked list for Stardust's particle list, and then recompile some of my existing examples. The result showed that the performance didn't improve; actually, it's quite the opposite: the CPU consumption got even higher (approximately 5% higher than the original).

I'm pretty sure when the number of particles is large enough, linked lists shall yield far better performance than arrays, but for common particle effects and daily uses, the number is simply not that large, thus the result. I got the exact same result from the attempt to use linked lists for Emitter.

The original array version of Stardust makes use of object pools to improve performance; however, I encountered some difficulty in implementing object pools for the linked list version (yeah, I'm just an amateur programmer). I think the performance gained by using object pools compensate for not using linked lists. I'll just stick with arrays for Stardust, unless I somehow get motivated to make my third attempt to try linked lists for particle engines (this really is time-consuming).

If you are interested, I've saved a copy of the linked list version in the SVN repository. Click here to download the RAR archive.

PureMVC Painter

2009-08-28T10:09:00.001-07:00

View demo
View source

Whew...I just finished my very first PureMVC project. It's just a simple painter application, with standard pen, eraser, and clear functions, not appealing at all.

I've gone through PureMVC classes and documentations a couple of times, but never taken my time to actually try using it to build a complete application. Finally, I've put things together and create this little app. You can take a look in the source files if you're interested.

Stardust FlashDevelop Templates

2009-08-28T00:07:00.000-07:00

Get Stardust FlashDevelop templates
Stardust project homepage

I've created a FlashDevleop template pack for Stardust. Now you can extend Stardust at ease without worrying about forgetting which methods to override. The templates include all abstract methods that need to be overridden for you.

Particle System XML Reconstruction Example

2009-08-25T03:31:00.000-07:00

View manual (PDF)

I've added an XML Reconstruction example chapter after the Working with XML chapter. This chapter gives a brief example demonstrating how to reconstruct a Stardust particle system from XML data. And at the end it shows you the power of tweaking parameters of a particle system without recompilation, simply by modifying the external XML file.

Blizzard

2009-08-24T23:58:00.000-07:00

View example
Stardust project homepage

Believe me, it looks much better in motion.

This example uses Perlin noise to create turbulence and a UniformField to pull particles toward the bottom left, preventing particles from being "blown" too far away from the intended direction by the turbulence. To add some flavor to the interactivity, I've also created a circle deflector following the mouse cursor.

Stars & Sprinkles

2009-08-24T20:05:00.001-07:00

View example

View example
Stardust project homepage

I've ported these two basic examples from Emitter.
I think these effects are also very common.

The first one involves a SinglePoint zone following the mouse cursor, acting as the zone for the Position initializer.

The second example uses the Damping action to slow stars down, creating a damping effect.

Stardust Example: Drips

2009-08-24T09:27:00.000-07:00

View example
Stardust project homepage

I saw this Flash & Math article, and tried to use Stardust to imitate the dripping & splashing effect :p

I though I could go back and make some simple Stardust examples unlike the recent fancy ones. After all, we all do need easy examples to help us get started, don't we? So here it is, a very simple drip-and-splash particle effect.

Waypoints

2009-08-23T08:08:00.000-07:00

View example
Stardust project homepage

I've added a new action: FollowWaypoints.

Used along with the Waypoint class, this action causes particles to follow waypoints in series, creating a path-finding behavior. There's also an option for whether particles loop back to the first waypoint after passing through the last waypoint. A 3D version is available as well: the FollowWaypoints3D class.

The algorithm used by the FollowWaypoints class was inspired by the Path Finding section in the Steering Behavior chapter of AdvancED ActionScript 3.0 Animation, by Keith Peters.

Masked Collision & Turbulent Pixels

2009-08-22T09:48:00.000-07:00

View example

View example
Stardust project homepage

Here are two more examples for Stardust.

The first one demonstrates the particle masking feature: each particle is assigned an integer mask, and two particles would only collide against each other if the bitwise-AND of their masks is non-zero. In this example, red particles are given a mask of (1 | 2 | 4), green ones 2, and blue ones 4. The result is that each particle collides with others of the same color; moreover, red particles also collide with particles of the other two colors. You can notice that a green particle does not collide with a blue particle, since the bitwise-AND of 2 and 4 is zero.

The second example shows the PixelRenderer class in action. This class renders pixels into a BitmapData object. The turbulence effect is created using Perlin noise along with a BitmapField object used as a gravity field.

ZedBox Carousel Effect with Depth-of-Field

2009-08-21T11:53:00.001-07:00

Launch Site
ZedBox project homepage

Milkmidi at Medialand created this carousel effect using ZedBox, my 3D billboard engine.
He also used the BlurZFilter class to create a depth-of-field effect.

Using ZedBox, to create this carousel effect simply involves placing objects into a parent container, and tweaking the parent container's rotationY property.

Pixel Star Fireworks

2009-08-18T23:33:00.000-07:00

View example
Stardust project homepage

I've added a Color initializer and PixelRenderer renderer.
As the renderer's class name suggests, it draws pixels into a BitmapData object.
This example was inspired by this Flint example.

Stardust Class Inheritance Diagram for Kids

2009-08-17T01:33:00.000-07:00

View diagram

That's it. I've had enough of UML class diagrams.
They look professiona, but are visually...uh...tasteless.
So I decided to create class diagrams of my own style for the Stardust manual.
This is the class inheritance diagram in the manual.

Stardust Manual

2009-08-16T11:58:00.000-07:00

View manual (PDF)

Behold! It's the Stardust manual!
Although it's still not complete, it has already covered the features and class responsibilites of the engine.
And it also includes a minimalistic example at the end. I'm sure this will help understand the basic usage and workflow of Stardust.

Stardust Particle Engine Goes Beta

2009-08-13T21:02:00.000-07:00

Project homepage

Yes, Stardust goest beta!
There are already a bunch of examples to watch, source files provided.
Check them out on the project homepage or download them directly.
I've also added a very abstract class diagram.
I'll make more diagrams and tutorials to help you understand and use Stardust :)

Here's the class diagram.

View Stardust class diagram

Pink Triangles

2009-08-11T09:04:00.000-07:00

View example
Stardust project homepage

This is a test for the CalculateScreenVelocity BillboardOriented actions for Stardust 3D (the Stardust native 3D engine). The CalculateScreenVelocity action projects a particle's velocity vector in 3D space onto the screen, yielding a 2D vector. The BillboardOriented action then align 2D display objects' rotation values to these 2D vectors.
You can pause the example by pressing the "Pause" button at the bottom left. The simulation will stop, but the particles will still align to their projected 2D velocities as you rotate the camera.

The source files for this example can be found here.

Stardust Sakura 3D

2009-08-10T23:18:00.001-07:00

View example
Stardust project homepage

After the Sakura examples for ZContainer and Emitter, this is the third generation of Sakura example, for Stardust! It's seems that Sakura demo is a must for all my engines now.
I didn't use the ZedBox, Papervision3D, or ND3D extension. Stardust has a native 3D rendering engine.

You can press the "Pause" button at the bottom left to pause the petals, and rotate around the camera to look around. Enjoy the bullet time :p

The source files for this example can be found here.

Exploding Image

2009-08-09T22:03:00.001-07:00

View example
Stardust project homepage

Looks familiar? Yes, it's imitating this example from Flint Paritcle System.
The only difference is that Flint uses a static method defined in the Particle2DUtils class to create particles from a bitmap, and Stardust uses the BitmapBurster class, a subclass of Burster, to do the same thing.

The source files for this example can be found here.

Uniburst Is Back in Stardust!

2009-08-09T05:32:00.000-07:00

View example
Stardust project homepage

As a left-out feature from the upgrade of Emitter 1.0 to 2.0, Uniburst is back in Stardust!
Now there's a Burster class whose sole responsibility is to allow user to create custom particles with full control over the particle properties, which means you can create particles that shows randomness (which is pretty much what Stardust is doing) or particles whose properties conform to a regular, uniform pattern. The latter is what Burster is mainly meant for. So far there's only one subclass, the PointUniburster class. It works just like the uniburst() method of the PointSource in Emitter 1.0: it bursts out particles spreading out at uniformly distributed angles. I'll make more Burster subclasses in the future.

The source files for the example can be found here.

Stardust Example Screenshot Wall

2009-08-08T00:09:00.001-07:00

Right on! This "wall of examples" sure looks attractive, doesn't it? And I'll add more tiles to it!
Things to do: complete documentation and official tutorial website.

Two More Stardust Examples

2009-08-08T00:02:00.001-07:00

View example

View example

One of the best features of Stardust is the Spawn action (and yes, there's a 3D version, I'll make an example of it as soon as possible), and I made a fireworks example out of it.

Also, the ZedBox extension is now complete, so I made use of the BlurZFilter provided by ZedBox to create the depth-of-field example.
If you are using a debug Flash Player, you'll notice that there're some errors being thrown, something concerning FocusManager class in the fl.* package. This happens when you use Flash UI components with ZedBox. I have no idea how this happens, but you can simply ignore the error since it has no impact on the Flash movie.

The source files for these examples can be found here.

Stardust Documentation

2009-08-07T08:06:00.000-07:00

View Documentation

Finally, the first documentation of Stardust has come out. Although it's not fully documented, it's there, and you can still browse the available classes, proeprties, and methods much easier than directly staring at AS source files. Whew, there are in total 214 classes so far - the biggest project I've ever done.

I'd had some problems dealing with ASDoc. The "-doc-sources" and "-exclude-dependencies" options cannot be used together, which means I had two options: either including all related classes in the documentation (ZedBox, Papervision3D, and ND3D), or using the "-exclude-classes" option to filter out classes ONE BY ONE (there are hundreds of unwanted classes). Fortunately, later on I discovered that using compiled SWC libraries as sources, the classes in the SWCs would not be included in the final documentation by ASDoc. ZedBox and Papervision3D already had compiled SWCs provided, so I compiled the SWC file for ND3D my self using the compc.exe compiler shipping within Flex SDK.

After hours of struggle, I've finally got everything right and here's the documentation. Enjoy :)

Turbulent Blast

2009-08-07T02:40:00.000-07:00

View example

After some experiment with the BitmapField class, I made this turbulent fiery thing. It looks cool, and the performance seems to be pretty decent.

The source files for this example can be found here.

Text Spark

2009-08-07T02:07:00.000-07:00

View Example

GMG (sorry I don't know your real name) asked me if it's possible to use Stardust to create effects like this.

The answer is yes.
Now Stardust supports fields and zones based on bitmaps, so you can make particles spawn at positions corresponding to non-transparent areas of a bitmap.

The source files for this example can be found here.

Bitmap Turbulence

2009-08-06T23:16:00.000-07:00

View example

Inspired by the algorithm from ClockMaker's work, I tried to replicate the same effect with Stardust, and this is what turned out. The main idea is very simple: prerendering 360 pieces of bitmap data of a display object rotated at 0~359 degrees. All the visible particles are Bitmap objects, and they change their bitmap data according to their rotation values, each picking up a bitmap data from the 360 prerendered ones.

Simple, but produces much better performance than using vector graphics alone.

The source files for this example can be found here.

Stardust ND3D Extension

2009-08-04T10:21:00.001-07:00

ND3D Official Homepage

Yesterday I mailed Lars, the author of the light-weight 3D engine, ND3D, asking him if it's okay to include an ND3D extension in Stardust, and he agreed. Hence, now I'm working on the ND3D extemsion for Stardst. As soon as I finish all of the four Stardust 3D extensions - Stardst native 3D, ZedBox, Papervision3D, and ND3D - I'll move on to create more demos and examples.

Stardust is near its completion. Cheers!

P.S. I'm also under the pressure of the upcoming PTT Flash forum workshop this month. I said I would demonstrate Stardust in the workshop (the COMPLETE Stardust of course) and I WILL do what I promised.
(PTT is the biggest BBS site in Taiwan)

Oriented3D & Collide3D

2009-07-30T09:53:00.001-07:00

View demo

View demo

Two important classes for the Stardust 3D version, Oriented3D and Collide3D, are complete. As you can see, the Oriented3D class aligns the 3D objects directoin to their velocities, and the Collide3D class handles what it name suggests, 3D collision.

The source code for these two examples can be found along with th other examples at the Stardust example SVN repository.

Stardust Papervision3D Extension Demos

2009-07-29T21:29:00.000-07:00

View demo

View demo

Here are two Stardust Papervision3D extendsion demos. This extension supports both billboard and DisplayObject3D particles.

The basic initializers and actions for 3D particles are complete, including Position3D, Velocity3D, Rotation3D, Omega3D, Move3D, Spin3D. Common initializers and actions also work on 3D particles, such as DeathLife, Alpha, Scale, AlphaCurve, and ScaleCurve. I'll go on finishing the other 3D initializers and actions, and working on the ZedBox extension. I'm also thinking about developing an ND3D extension.

There seems to be some memory leak issues with DisplayObject3D. Only the DisplayObject3D demo continues to eat up memory without releasing it.

Bunny Republic

2009-07-28T08:11:00.001-07:00

View full image

It's my third Illustrator class, and this is what I drew in during the class. The teacher taught us how to use the mesh envelope distortion tool and wanted us to draw a flag in the wind. Other people used either Taiwan's or U.S.'s flag; I decided to do something different: I used the Bunny Republic's flag instead.

Not bad for a person who has only finished three classes, huh?

Stardust Sneak Peek Examples

2009-07-27T08:20:00.000-07:00

View example

View example

I've made two sneak peek examples for my currently working-in-progress particle engine, Stardust. The first one demonstrates the support for multiple particle sources as in Emitter, and the second one shows the new ScaleCurve class that essentially does what the initScale, finalScale, scaleGrowRange, and scaleDecayRange properties do in Emitter. Stardust completely encompasses all Emitter features, and supports a lot more.

Note that in both examples, there's that "Show XML" button. Click it and it'll show the complete XML representation of the system. Yes, Stardust supports generation of XML representation and parsing of existing XML data for reconstruction of a system. The XML workflow is much easier than in Emitter. I'm very happy about this.

Oh, and here's a good news: the 2D part of Stardust is now complete. Now I'll move on to the Papervision3D and ZedBox extensions.

Stardust Particle Engine Logo

2009-07-20T09:57:00.000-07:00

I've decided to develop a whole new particle engine from scratch. It's called Stardust, and that's also the mascot bunny's name.

I've tried something different for my engine this time: designing a mascot character for it. I hope this will bring the users closer to the engine. Since there's a solid character image, people may visualize the character in mind when thinking of the engine.

So far the engine's 2D functionality is complete. Now I'm working on the XML and 3D parts. After the engine is finished and a full tutorial & docmentation are ready, I'll bring this engine into public.

The class structure of Stardust is inspired by Flint Particle System. Stardust is designed with flexibility in mind: users can easily extend Stardust to create a custom branch. I'll complete the 3D extension that supports ZedBox and Papervision3D before the initial release.

The Ray Monster

2009-07-06T06:16:00.000-07:00

View Flash clip

We interns at Medialand are required to write internship diary everyday.
And we have to create some sort of "enter our blogs to view our diary" thing, so they can post it on their official blog.

Previously, Medialand had never had ActionScript programmer interns. Their links to interns' blogs were just static images. Being their first ActionScript intern, I decided make a difference: a Flash clip.
After some discussion, we decided to use the theme "Medialand intern rangers V.S. The Ray Monster". FYI, Ray is our CEO.
The subtitle below the logo says "You think we're just here for internship?"

The design interns did the character design, and I did the animation, special effects, and interaction programming.
By the way, the white radiation background was created using my particle engine Emitter.

CJ's Internship at Medialand

2009-07-03T08:35:00.000-07:00

I've got an ActionScript programmer internship at Medialand, which is a company mainly providing RIA solutions for internet promotion. The intern ship will last two month, from July 1st to August 31th. They require us interns to write an internship diary everyday on a blog, so I've created a new blog for that: CJ's Internship at Medialand.

Medialand is an easy workplace. People here are nice, and the environment is pretty comfy. I guess I'll have a nice time having internship here during my summer vacation.

Using TortoiseSVN to check out files from Google Code repositories

2009-06-27T08:36:00.000-07:00

Alright.
I believe there are still many people out there who don't know how to obtain source codes from a Google Code project homepage if the project owner does not provide a download link in the download list.
Project owners may decide to pack a stable release of source codes in a compressed file and upload it to the download list, or provide related files in the list as well. But in some cases, they somehow choose to keep the source files in the SVN repository, without providing the files in the download list.

What's an SVN repository? SVN stands for Subversion, which is a version control system. SVN repositories are places project owners put there source files in, and these repositories are "version controlled". An project owner can "commit" source files to a repository, "check out" the files to another computer, modify the files in that computer, and "commit" the modified files back to the repository. The complete process is overseen by the SVN system. The system keeps track of every single modification to the source files, and completely backups every older versions after a modification. So it's possible for the owner if he or she wants to "revert" the repository back to an earlier version, or revision.

Google Code provides two different version control systems: SVN and Mercurial. I only use SVN, so I'm not very familiar with Mercurial. Here I'll just talk about the SVN system.

A Google Code project owner has a password to the project's SVN repository, which allows the owner to modify the repository. Others can only "check out" files from the repository. But how to check out the files?

You can either use the commandline method to communicate with the SVN repository (which I certainly do not prefer), or use graphical-interface tools like TortoiseSVN. I use TortoiseSVN to commit and check out files.

You can get TortoiseSVN here.

Ok, here's how you check out files from an SVN repository.
(I use Windows XP)

1. Download, install TortoiseSVN, and restart your computer.

2. Create a new folder for checking out files.

3. Go to the project's SVN repository.
If a Google Code project page's URL is http://code.google.com/p/NAME,
then the repository's root directory URL is http://NAME.googlecode.com/svn
You may want to navigate several layers down in the hierarchy (usually to the "trunk" directory).

4. Copy the directory's URL.

5. Right click on the new folder you created in step 2, and select SVN Checkout.

6. Paste the directory's URL and click OK.

7. Wait for the files to be checked out.

8. You're done!! Whenever you want to update the files to the latest revision,
right click on the folder and select SVN Update.

FenoFSM examples

2009-06-25T21:00:00.000-07:00

I've made some examples for FenoFSM.
Hope this helps understand the usage of FenoFSM.

Project homepage

The examples are available at the download list.

Multistate Button

State Chart

FenoFSM - Finite State Machine Framework

2009-06-25T03:15:00.001-07:00

Project homepage
View Documentation
Download source files and docs

I've separated the finite state machine framework from CJLibrary CS4's idv.cjcat.fsm package.
It's now a new project called FenoFSM!

Also, I've written some tutorials:
Basic Usage
Using XML

I'll create some fancy examples and record video tutorials later on :)

Rabbit Shit

2009-06-10T04:49:00.001-07:00

I was bored.
And my classmate came up with this stupid idea.

ZedBox video tutorials

2009-05-23T22:31:00.000-07:00

Yup, video tutorials available on the second day of release.
Now how cool and fast is that?

Here are the vids.

01 - Basic Usage
02 - Nested Object Structure
03 - ZFilters

The complete playlist

ZedBox 1.0 released - 2.5D Billboard Engine

2009-05-23T07:45:00.000-07:00

Go to project homepage

Finally.
I've been always to develop a 2.5D engine with camera. And here it is, ZedBox.
Different from the ZSprite engine in CJLibrary CS4, ZedBox actually supports 3D camera, which means no more fixed camera direction.
You can set the camera to point to whatever direction you like.
ZedBox also supports nested DisplayObject structures, giving you more control over object structures.
Moreover, ZedBox supports ZFilter, allowing you to create effects such as depth-of-field effects.

In the future, I'm going to combine Emitter with ZedBox; that is, ZedEmitter!
ZedEmitter would be capable of creating 2.5D particle effects.
I'm looking forward pretty much to it :)

Oh, and here's an example for ZedBox: Satellites.

Download SWF
Download FLA

Video Tutorials on Emitter 2.1 New Features

2009-05-21T23:17:00.000-07:00

Two major new features to Emitter version 2.1 are composite behavior triggers and XML supports.
I've recorded some video tutorials to cover these features.
Also, I've recorded a tutorial on timeline-animated particles.

11 - Timeline-Animated Particles
12 - Composite Behavior Trigger
13 - XML
14 - More on XML

Alright, the total length of the video tutorials has reached an hour.
Probably I can name this playlist "Emitter in An Hour" :p

Sprite 2009 CNY Website

2009-05-06T05:51:00.000-07:00

The Sprite 2009 Chinese New Year website used the Emitter engine to create the sparkles in the loading Sprite bottle and the big bubble effects in the main menu.

Yet 3 more Emitter video tutorials

2009-05-03T08:15:00.000-07:00

I'm on a video tutorial recording frenzy >:]
So here are three more Emitter video tutorials.
Hope you like it~

08 - Custom Behaviors
09 - Deflectors
10 - Impulse

3 more Emitter vids

2009-05-02T09:35:00.000-07:00

I'm just so excited about making Emitter video tutorials.
So here are three more tutorials!

05 - Deflectors
06 - Behaviors
07 - Custom Behavior Triggers

I actually like the last one pretty much.
It covers the how to create custom behavior triggers by extending the BehaviorTrigger class, which is one of the major new features of Emitter 2.0.

Emitter video tutorials!

2009-05-02T02:39:00.000-07:00

I'm a big fan of Lee Brimelow's Flash video tutorials.
So I decided to make my own video tutorials on Emitter!
Hope you like it :)

01 - Introduction
02 - Basic Usage
03 - Gravity Fields
04 - Burst & Damping

The complete playlist

More video tutorials coming up~

Emitte 2.1 released

2009-04-28T09:33:00.000-07:00

Go to the Emitter project homepage

Emitter is now version 2.1!!
New features include:

Complete XML support

Particle, ParticleSource, Emitter, Field, Deflector, Behavior, BehaviorTrigger classes now all implement the IEmitterXML interface, which provides a toXML() method. This method returns an XML object that completely represents an object of the aforementioned classes. This XML object can then be parsed, producing an object that is exactly the same as the original one. The main application of this feature is that you can load an external XML file representing an object; this XML file can then be loaded in to a SWF movie to be parsed in order to reconstruct an exact same object that generated this XML data. Adjusting the values in the XML file doesn't require a recompilation of the SWF file, producing more flexibility for using the Emitter engine.

Composite Behavior Trigger

Now you can compose multiple behavior trigger into a single trigger by the CompositeTrigger class, either in AND or OR mode. In AND mode, the composite trigger triggers behaviors only if all the triggers in the composite are triggered; in OR mode, the composite trigger triggers behaviors if one or more of the triggers in the composite are triggered.

Velocity Overriding

You can define a gravity field by the Field class. Now you can also define a velocity field for a Particle object by the Field class. Through setting a Particle object's velocityField property to a Field object, any single particle's velocity is determined according to its current position, depending which Field object is used as its velocity field. By extending the Field class, you can design your own velocity field and have total control over the particles' motion.

Getting The Greenwich Mean Time (GMT)

2009-03-15T08:03:00.000-07:00

Someone asked this on a Flash BBS:
"How do I get the Greenwich mean time instead of the local time on the client's PC?"

My first thought was to find a web page that gives the current GMT.

And I found this!
http://www.timeanddate.com/worldclock/

The rest is rather simple.
Just load this page using the URLLoader class and do whatever you can come up with to splice out the GMT information.

My approach is through regular expression:


d{1,2}:\d{1,2}:\d{1,2}
//This means two colons splitting three blocks of one to two digits.

So here's the complete code for getting the GMT:


var loader:URLLoader = new URLLoader();
loader.addEventListener(Event.COMPLETE, traceTime);
loader.load(new URLRequest("http://www.timeanddate.com/worldclock/"));

function traceTime(e:Event):void {
  var str:String = URLLoader(e.target).data;
  var time:String = str.match(/\d{1,2}:\d{1,2}:\d{1,2}/)[0];
  trace(time);
}

Oops, later on I found out that Google and Yahoo already provide a GMT inquiry service.
So my method was an overkill :p

Emitter Editor Sneak Peek

2009-02-14T08:00:00.001-08:00

No, it's not finished yet.
But here's a screenshot of the current development progress.

Once the Emitter Editor is finished,
you can save and load external XML files representing particle design.
So you can save your own presets and share them with others.

This entire workflow would be far less time-consuming and much more user-friendly.
I'm really looking forward to the Editor's completion :)