Further Android Development

So, I spent some time last night trying to figure out how to duplicate some of The Render Engine's functionality in Java.  Unfortunately, this is no simple task since JavaScript is such a flexible language and Java isn't.  While converting the Engine class to Java, I ran into my first problem.  It needed to deal with PooledObject, and that uses the "create" method to reduce garbage collection.

However, the "create" method is a class method on PooledObject and is actually inherited by objects which derive from it.  Overall, the complexity of the method could only be matched by either a factory class, or using reflection.  I don't want to have a super complex factory, and I also don't want reflection (which can be slow), so I got to thinking.

Maybe the objective here should be to determine what parts of the engine are slow and try to speed those up by re-making them in Java.  When I profiled the engine, on all the platforms, the largest amount of time is spent rendering objects.  So, the first tests I work through tonight will be creating an AndroidRenderContext which wraps the SurfaceView and Canvas Android objects.  Hopefully this will result in some speed ups.  If that proves out, I will see about re-making some of the components as Java implementations to see if that adds to the performance.

After speaking with a friend of mine today, he agrees that rendering is probably where 90% of the time is spent (and the numbers back that idea up).  He feels that things like math, input, collision, etc. are probably not taking up as much time as rendering.  Thus, if I can create a context which takes advantage of the Android, somewhat natively, I should be able to gain the performance I need without having to rewrite everything.

Android Development

Originally I had figured that it would be nice to have a simple way to package the engine and a game as an installable package for the Android platform.  However, after doing some testing and preliminary benchmarking, I've determined that running a game in an engine completely written in JavaScript isn't going to perform well on that platform.  So I've expanded the task to develop a launcher app into a complete port of The Render Engine to the Android platform as an app.

I know it might sound foolish, but most people aren't as interested in extending the engine as much as they are to use it.  Instead of running the engine in JavaScript, I plan to create a simple prototype to test implementing the engine in Java and using the WebView to expose the engine to a game.  The methods will all be the same, but the internals will run in native Java rather than JavaScript.  It's going to take some time, but the eventual plan is to be able to write a game for The Render Engine which runs in any web browser, plus the Android app, without changes.

What this would encompass is rewriting the engine in Java and creating interfaces to the parts of the engine using the Java to JavaScript bridge.  If this proves, a) plausible, and b) practical, then the result might be to have games that run quickly on Android and take advantage of the hardware more natively.  As such, I'm expecting most of the processing to speed up and for games to run without feeling sluggish.  Eventually, it would be possible to navigate to a game (or possibly distribute it through the Android Market Place) which runs the same on any desktop browser, and with the best possible performance on Android devices.

If all goes well with this, I might see if I can either develop (or commission) someone to do this for the Apple iPhone.  However, don't cross your fingers yet since that might violate their policies and allow people to develop apps for iPhone which aren't iTunes-approved.

Performance Notes

This morning I decided to add back the DOM rendering context into the "bounce the ball" demo.  How it got removed, I'm not sure, but it's back now in trunk.  You simply enable it by appending "context=dom" in the URL -- by default, it uses the canvas context.  After doing this, and relating to a blog post I read last night, I decided to get some performance numbers using this demo.  Now, realize that this is still very early in v2.0 development and their will be time to optimize, but I wanted to see where some browsers were at regarding engine performance.  The test was simple and not super scientific, but I ran the demo at 30fps (33ms available frame time) and added bouncing balls until the metrics topped out at an engine load of ~100%.  Below are the quick results:

Chrome 6.0.472.41
-----------------
DOM Context - 32 balls
Canvas      - 66

Firefox 3.6.8
-----------------
DOM Context - 17 balls
Canvas      - 17

Firefox 4.0b3
-----------------
DOM Context - 17 balls
Canvas      - 21

Computer specs:

Windows XPsp3

Intel Core2 Quad CPU (Q9300 @ 2.50GHz)

4GB

While this doesn't really tell much, it does show that Chrome's canvas rendering is pretty amazing.  66 physically animated balls bouncing around is pretty intense.  Especially considering that the best Firefox could muster was 21.  Like I said, not very scientific but still interesting none the less.  This points to the fact that The Render Engine's scene graph needs to be optimized a bit.

Understand that the physics demo really puts a strain on any computer.  While it performs quite well, considering how much it does, it's still performing a ton of calculations each and every frame.  It's currently set at 10 integrations per frame to calculate collisions, so I could lower that in favor of more speed for less accuracy.  There is a lot of tuning that could be done to eek out as much performance as possible, but it's still going to really test the capabilities of the engine.

Once all of the features are in the engine for v2.0, I plan on spending some time optimizing The Render Engine for each platform it supports (within reason, of course) to get the most performance out of it.  Some things will be major wins for all platforms, while others will be specific tweaks per browser.  By far, Chrome is still the best when it comes to performance.  I'm still amazed at how much horsepower the V8 engine can put out.

User Interfaces

Started working, in earnest, on the new user interface objects.  It will consist of a manager class to load UI's, an object which represents a loaded UI in game, and a set of base UI elements.  While creating the UI manager class, I decided to embark on creating a multi-resource loader.  This resource loader class can take the place of many resource loaders by lazy loading the ones you need, and then managing the instances for you.  When you need to access a single type of loader, you instead address the multi-resource loader and tell it what type you want to use.

This will allow for the UI manager to load resources from multiple sources automatically.  Your user interfaces will be able to have sprites, images, sounds, and more all in play.  A JSON object file is used to describe your UI, which makes creating user interfaces simpler and faster (I hope).  It's still pretty early in development, so it isn't ready to use even though it's in the source repository.  Everything is in flux, and subject to change as you probably already know.  As things come together, I'll either put together some screenshots or a simple demo to show off the new UI stuff.

End of Week Summary

Here it is, the end of the week, and what do I have to show?  Well, get yourself a chair and take a seat... You may have played around with The Render Engine when it was a child -- back in v1.0.  Additionally, you probably took a look at the "bounce the ball" demo and thought it looked pretty jittery and not very well simulated.  You'd be right on both counts.  Here, take a look:


http://renderengine.googlecode.com/svn/tags/v1.0/demos/wii_test/index.html

Well, v2.0 of The Render Engine is starting to grow up... Mind you, this wouldn't be possible without the fantastic JavaScript port of the Box2d physics library, but it's just another example of how flexible The Render Engine really is.  Everything is still in flux, at this point, and is subject to change in the future so don't count on this being the final implementation.  However, take a gander at the new "bounce the ball" demo:

http://renderengine.googlecode.com/svn/trunk/demos/wii_test/index.html


So, when anyone asks what I did this week, just point them at that there link and smile... I know I will.

Gettin' There

I have got physics working... almost.  The link below is a very rough version (early, early) of the "bounce the ball" demo using the Box2d physics code.  It runs surprisingly well, but as I said it is still quite rough.  There are a number of things to do to get this to where I want it to be for v2.0 of The Render Engine, but it's getting there.  This is untested on the Wii, so I wouldn't run out and try it on that platform.  However, it does run quite nicely on Chrome and Firefox.  Give it a go and send me some feedback.  I'm interested in hearing what people think of this particular update.

http://renderengine.googlecode.com/svn/trunk/demos/wii_test/index.html?metrics=true

Let's get Physical!

I've gotten the physics module loading, but it's still not working yet.   I don't get any dependency errors, so the files and classes are all loaded and configured.  The thing that I don't see is a physically animated object.  It's not a big deal -- the big deal is that it all loads without errors!  Now to try and get a physics object into a demo and play with it a bit...

In other news, I've been playing around with how to do UI's for The Render Engine.  I've got ideas about a couple of approaches.  The first would be to just use a div layered over the render context and have jQuery do the layout for me.  Another option is to create renderable components for the context itself.  I'm also fighting with how to represent UI objects for quick loading.  JSON just doesn't seem like a good fit, but it doesn't require a lot of parsing since it's inherent to most browsers.  I may still change it to be a textually descriptive format.

Physics and Billboards

Having a hell of a time integrating Box2d-JS into The Render Engine, right now.  I'm not saying it can't be done, but it's proving to be a major pain in the neck.  Soon I hope to get the bouncing ball demo re-written to use the new physics module, but for the time being everything to do with it is a little broken.  I wouldn't go trying to use the physics module just yet... I'll let you know when it's in there.

You may wonder how Billboards and Physics are related -- well, they aren't.  But one thing that was recently completed in v2.0 is the introduction of the BillboardComponent.  This component allows an object to render itself to a billboard (2d picture) and present that to the render context rather than re-rendering each and every frame.  Things like the vector text renderer benefit from this since it doesn't have to redraw each character's glyph for each frame.  It does it once, and from then on (or at least until it changes) it uses the billboard to draw itself.  This, my friends, is another win for speed!

Containers, rewritten

There have been a number of things, recently, that have come up during v2.0 development that could negatively affect performance in the future.  Additionally, these issues had started to manifest themselves in Chrome and Firefox 4.0.  So, to try and fix the main issue I rewrote the Container class to be a linked list, rather than a simple array.  It may seem counterproductive to change from the native Array object, especially since it has all those fantastic methods for filtering and such, but overall I've seen a slight improvement in performance.  It isn't huge, but it's there...

Doing so also allowed me to update the Iterator class so that it would not be negatively affected by changing the backing container.  As such, the iterators can be safely used without needing to worry about whether an object in the container has been destroyed.  This is due to the fact that iterators will intuitively detect which objects are included in the iteration and skip over those that should be excluded.

Unfortunately, as with any change to a core class such as Container has its drawbacks.  One such issue is that when a container is destroyed, it no longer destroys the objects it contains.  This isn't a big issue, as you can still call the cleanUp() method of Container.  But it will be a sticking point for some who've already started using The Render Engine for their game development and choose to work from the SVN trunk.