You can check out a demo here: http://gwt-phys2d.appspot.com/ (library/demo source code also available for download)
Starting with the Phys2d code, here’s basically what the “port” involved:
- Started a GWT/GAE project in Eclipse and imported Phys2d into it. Somewhat surprisingly, mostly due to never having used Eclipse or GWT before, this part took the largest amount of effort. Eclipse is really cool, although I’m still kind of weirded out by how many things it does automagically. I mean, if something’s wrong with your code, you can just right-click on it and have it automatically add in import statements (HUGE timesaver), declarations, etc. Freaky voodoo. I haven’t had a chance to play with it yet, but I really want to try the plugin which gives you vi functionality in Eclipse.
- Fortunately, most of the core Phys2d library didn’t make calls to library functions which weren’t already implemented in the GWT emulation libraries. There were a few classes which were reliant on GUI things, but I just removed these from the source.
- On the flip side, the actual demos for Phys2d are heavily reliant on AWT (a GUI toolkit for Java). This is of course not emulated in GWT. I instead used HTML5 canvas functionality to render the shapes, via the gwt-g2d library. I also learned that apparently Chrome doesn’t support the canvas line segment drawing, while Firefox does. Hrmph. I only ported one demo over, but it should be easy to do the same for the others.
- After finally getting things running (all on my MSI Wind netbook, which is coincidentally my primary development environment ;), I found that it ran godawfully slowly. GWT/Chrome’s Speed Tracer wasn’t anywhere near as helpful as I’d hoped it would be, so I instead figured out how to use Firebug. I used Firebug to find that most of my time was being spent in repeatedly-run loops for collision detection. It turned out that there were a number of “new” calls inside of these loops, creating gajillions of new temporary objects every frame, and I suspected that the occasional pauses observed while running the demo were due to garbage collecting all these objects. I’m still not sure if this is the ideal solution, but I instead created temporary objects as class members, which were reused in these loops. I did this for a couple of the functions where most of the time was being spent, and was glad to see that this improved the time spent in those functions and overall performance quite a bit.
Please feel welcome to use the library, although the source is in very much an alpha state and pretty badly organized — I basically just zipped up my source directories (I think there’s a half-hearted git repository somewhere in there) after I got things working and uploaded them. If there’s any interest, I’d be happy to clean things up and perhaps start a Google Code project. I imagine it’d be pretty cool to use in game engines and such. Since this was just a self-education exercise and I have no desire to actually write anything that takes advantage of the library, please do let me know if you’d be interested in taking over maintenance of the code!
Here’s a list of further stuff which could be done:
- Do version tracking starting from the original phys2d sources, to moer easily determine what changes I actually made to them.
- Port more demos
- Fix the demo canvas drawing and add support for drawing more shapes
- Improve repeating timer calls so that it doesn’t keep on trying to add more frames if a computer can’t keep up with the specified timer interval.