11 March, 2007

Weekend Developments

I got quite a bit of work done this weekend. Animated sprites are working. They currently come in three flavors: forward, reverse, and ping-pong. They can loop forever or when done the animated actor will simply remove itself from the scene. This is useful for short-lived, sprite actors, and I'm now using them to add some nice explosions to Asteroids.

After adding animated sprites I worked on getting particles rendering. I decided to go the full-blown route here and really implement particle emitters. A particle system describes how the particles will behave. A particle emitter [actor] decides where and when the particles will be emitted, and the individual particles are finally advanced and rendered.

While there is a little bit of code cleanup left to do, I'm overall very happy with the results. I have added wormhole objects to the game, randomly appearing for 20-30 seconds, attracting the player and asteroids, and gaining intensity with each object that it swallows. A very cool effect.

I've cleaned up the OpenGLPresenter and OpenGLView objects, and they can now be used in the View Composer very easily to render any data desired. This is actually the first step of many to add some very slick game development tools to Dolphin (more on this at a later date), but in the meantime perhaps they will be useful to others as well.

On the downside, I'm finally starting to run into a few barriers that it looks like I'm going to have to address myself.

First up are the collection classes. I've had to create an UnorderedCollection class that will allow for O(1) removal of elements. It works very well, but it frustrates me to have to subclass a built-in class just to override a single function and implement it more efficiently. I rather wish something like this was already in there. I would have prefered to just add a #removeUnsortedAtIndex: loose method, but then #removeAll and similar methods wouldn't have worked as expected. I'm open to suggestions on this.

Next is the Point class. While I'm sure it works very well for 99.9% of all Dolphin users, it's extremely inefficient for my purposes. Running Ian's profiler reveals that almost 40% of all time is currently spent there. This means I'm going to have to go through a whole ton of code and adjust methods to take x:y: parameters instead. I'm also going to have to alter some of the code in the Point class to improve performance and add functionality (#rSquared and #normalized for use with intermediate results and #normalizedFast for not-quite-exact but really fast unit vectors).

Finally, with the particle system in and running, I've decided to really crank up the rate at which actors (and particles) are created and destroyed to test one other major concern: garbage collection. My own tests reveal that when a GC takes place, it usually takes between 30 and 40 milliseconds to run. This is an enormous amount of time. As progress continues, I'll be sure to post my findings.


tejón said...

That you've progressed to the point where profiling is a major focal point, really impresses me. :)

Having to insert #x:y: everywhere is going to suck at both ends. I don't have a browser open, is the Point class implemented as a built-in? I wonder if it would be worth corresponding directly with Object Arts about this and the UnorderedCollection issue.

Flatlander said...

Sounds like you are slowly starting to push Dolphin's performance limits and things are getting more interesting. I am especially curious about how well Dolphin's GC handles the pressure.

I have seen a very wide range of GC performance from some of the systems I have played with (mostly Schemes and Common Lisps, I haven't really pushed Squeak that far yet). Usually the problems quickly show up when you add more particles and objects to the scene. Some systems couldn't really handle it but at least Steel Bank Common Lisp does a very good job, even with a large number of objects.

So I guess that in theory it should work in Smalltalk too, but I'm still a bit suspicious how well it will perform when you do lots of vector math per frame. That sounds like a lot of consing and message sends...

BTW how often does that 30ms GC happen and what is exactly going on in the scene?