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.
smart choice IMHO.
ReplyDeleteI think the renderengine would benefit more from a specialized android renderer than from a full java rewrite which probably most users wouldn't use. I mean there are probably a ton of other good performing java game engines out there, but what makes your cool is it's js and it's hackable really easily, which java isn't.
cheers!