Well, very nearly. All that’s left to do perform a few more tests and clean up the documentation. When that’s done I’ll write up a summary of what’s changed and how to use the new main-loop classes. It should, I hope, make writing tests a fair bit simpler.
Off to dinner!
Just a heads up: I’ll wait until tomorrow evening to post to CVS, unless anyone wishes to review. I have an exam tomorrow anyhow, so I’ll be busy enough.
Wow, that all sounds great Eric. Sounds like there is a lot more control in the main system now. As long as all the old stuff works the same way it did, I really don’t have a problem with you going ahead and uploading to CVS. Unless someone else wants a review first.
Okay, so here’s a quick overview of the new package structure:
AbstractGame defines a common series of methods for implementing game functionality. In other words, AbstractGame is a framework for the methods a game should have. No implementation details are provided, merely utility methods. Specific main-loop implementations are now handled by subclasses of AbstractGame. Client applications should subclass the implementations, not AbstractGame.
Current implementations available (with more on the way):
- SimpleGame -> identical in functionality to the original AbstractGame; using this class you can continue to write things as you're used to
- FixedFramerateGame -> maintains a fixed framerate, updating logic at the same rate
- FixedLogicrateGame -> keeps a consistent gameplay speed regardless of the framerate acheived by the visuals
[/list:u]
I would suggest using the FixedLogicrateGame. No need to worry about updating based on a variable timestep, while rendering as fast as hardware permits. Just be certain to interpolate between frames, otherwise you'll be rendering the same frame multiple times. (I may need to implement some utility methods to have the new classes mesh with the existing way of doing things. Tell me what I'm missing, and I'll add them post-haste. It may even be as simple as determing the time for one frame in the fixed-framerate class, but whatever...)
The PropertiesDialog behaviour has also changed. One method now handles it all: setDialogBehavior(int). So, if you always want the dialog to display you'd now call setDialogBehavior(ALWAYS_SHOW_PROPS_DIALOG); This method also handles custom logos. You can call setDialogBehaviour(ALWAYS_SHOW_PROPS_DIALOG, "mylogo.png"); to have the dialog display your custom image.
Also included are a few additions to Timer. There is now a method to directly grab the time according to the timer, and find it's resolution. Very useful for the main-loop stuff, and I figure it could be used elsewhere too.
There's still some stuff to do: add FPS calculators to SimpleGame and FixedLogicrateGame. I'd also like to convert a few tests to the "new style" as an example.
One last thing (whew!): where should I post the source for review? I'll only post the app classes, but I have converted all the existing tests to SimpleGame.
Great, I look forward to it.
After you check this in, I think all the current tests need to be improved to be consistent and look the same. I’ve noticed that all my tests (in my haste to check if something worked or not) has all these little bad habits that we don’t want to spread to those learning the library. Using “lwjgl” explicitly for example, and many other things I did from cutting and pasting other tests.
It might also be a good time to change the main-loop style so users can get a feel for using the different options available. It wouldn’t be hard at all to convert FixedFramerateGame. In fact, it will probably make things simpler in the long run.
Oh, and as always, if you find you’re missing any functions in the classes, feel free to make the necessary changes, or just tell me and I’ll do it.
When are you planning on committing the app package?
Changes are comitted. I suggest everyone grab the latest source from CVS, 'cause there have been a fair number of changes. Saves you having to resolve all the conflicts later! 
Just finished playing with it a bit. Works pretty damn well. I love how you are able to simply swap out AbstractGame implementations and change the running without any code change (other than the extends part). Very nicely done.
Thank you! Flexibility was one of my main goals in rewriting the package - glad it’s useful. Hopefully I’ll soon have some more loop implementations to play with - specifically one using a variable timestep format found in the “old style” programs. It’ll integrate the functionality of Timer and the old AbstractGame - update(float) will now contain the timestep, eliminating the need for Timer.
I’ve added the new implementation: VariableTimestepGame. I also updated some of the documention that was mistakenly cut and pasted resulting in … err, rather senseless comments.