With the successful completion of the explode effect, I decided to build on the code used to split the node into pieces. I split the code in half and thus created a new generic function, dojox.fx._split that returns an animation object that splits the node into args.rows and args.columns and applies args.pieceAnimation() to each piece. This function takes the piece, its x and y location in the grid of pieces, and the dojo.coords of the original node as arguments and returns either an animation object or an array of animation objects to be combined.

I missed my update last week, so this post actually covers the past two weeks.

Hi dojoers,

I am thinking to put my analysis document for GFX 2.0 (this document has been updating from the first time discussion with my mentor Mr.Eugene Lazutkin). You can read the document to know more about abstract design of GFX 2.0... At the moment, I am writing document to explain thoroughly about GFX 2.0 implementation, it will be described about:
- Assumption implementation (for example, no color texturing, no light feature, etc)
- Implementation detail (including design diagram, improvement made to increase performance)
- Problem (algorithm, feature that hard to implement)

Link for the analysis document can be read in this link

I created a nice animation effect that splits the element into an arbitrary number of rows and columns, then sends them flying away from the element's center. The user can specify whether or not the pieces fade out as they move, and whether or not the distance and duration of each piece's animation should be randomized.

The effect is accomplished by cloning the node once for each piece and combining each piece's animation together. The original node's opacity is set to zero onPlay.

Hi dojoers,

Finally, after bugging around with algorithm to change Quaternion to Euler rotation system... The Opera implementation for GFX 2.0 is out... It is around 90% though (I need mathematician who understand about good camera management).

Since the Firefox and Opera implementation are already out... So I already achieved the unification API feature of GFX 2.0... After mid evaluation, I want to jump into high level of GFX 2.0 to make interactive 3D module... such as loading 3d model... and easy 3d environment loader file... I also want to make a real world example...

Hi dojoers,

There we go! A new demo page, it has realtime script execution, so you can play around with the library. Notice that, I put some predefined script already as example script... You can change it or do your own in custom script... The purpose of this demo page is to determine whether my API is good or not... Not forget to mention, I will post the class diagram for you to get an abstract idea about the API... Try your best not to see the source code... try to guess from the argument parameter name... I am sorry I cant provide full HTML documentation right now since I will do it later on this project lifetime...



Please go to this to see the demo page and this to see the class diagram...



I would really appreciate if you give some comments, suggestions, or critics... Thanks!

I've been playing around with the idea of a user-friendly way to make a toggle-able animation, meaning the user creates a single animation object, and when that object is played, the animation either plays forward or backward, depending on the animated node's current position or animation status. If the animation is played while it's already running, it would stop and then play in reverse from the current position.

There was a delay in my project, I didn't do much last week - there were
final exams in the university and I had to prepare well. Now, when I finally
finished this term, I can concentrate on the project and be productive.

There were updates on the code since my last blog post.
I added a simple implementation of grouped tokens handling. It can be used
for the cases when you need to treat a set of equal tokens, which go one after
another, as a one big separate token.

Wow, it's been two weeks since my last blog. I'll be sure to update this regularly from now on.

I've been experimenting with a method to solve the "stale values" bug in sizeTo but when I realized that the goal of my project is to provide a "toolset," not a bug fix, I decided to forget about trying to solve the bug in dojox.fx and focus on cranking out new animations that handle interruptions and dynamic initial values. Instead of using the defective sizeTo, I'm using animateProperty.

So this past week I've been working on a new data flow for our d-rails helpers in rails. I've implemented most of the dojo.fx functionality with this new flow, since it's a relatively small subset of functionality that would give me a pretty good idea if this was going to work well or not.

So let's start.