jME: Improved State Tracking

Back in July I talked about issues in jMonkeyEngine with tracking states across multiple OpenGL contexts. This has changed drastically with the latest changes checked into CVS last night. Now we have the concept of RenderContext and StateRecord. Basically, for each OpenGL context created in jMonkeyEngine, a RenderContext (RC) is also created. Each RC contains a number of StateRecords, each of which keep track of changes for a particular RenderState that have occurred in that given RC. This allows the individual RenderStates the ability to check if a state or value is already set in the current RC before making the expensive OpenGL call.

All of this eliminated the need for several hacks in our code:

• We were previously checking at the RenderState level if a state was already applied (using ==) This sped us up, but introduced artifacts because changes internally to the state could not be detected.
• Because of the problem with the hack discussed in point 1, we cleared the list of "currently applied states" at the end of every frame, meaning we had to reapply every state type every frame. Many states never get used in an app or game, and re-disabling them every frame was a big waste of time. Well, now we can track the state of OpenGL from frame to frame, so this is no longer an issue.
• Context changed required reapplying all of the default states every time just to make sure we knew what the current state of things were. Again, no longer needed.

The result? A lot less OpenGL calls - which translates into higher FPS - and no bleeding of states from context to context. The best part is, you don't need to do anything to use it... it "just works."

That said, I imagine there are still many bugs in this new code. Still, so far it has held up nicely in the tests and our game code. Give it a whirl today!

Demo'ed out

In the last month or so at work we've had a steady barrage of important people coming by to witness a demo of our game and/or toolset. This week we had two, last week we had one or two, and next week we have two, one of them being very big. So I guess you could say we are getting a fair bit of attention lately, hopefully moving us along towards a successful product. Scrambling at the last minute for a demo has become a fact of life lately though and I will be glad when that has subsided and we are back to a tighter focus on the products as opposed to the next dog and pony.

Still, we've managed to accomplish a lot technically in the last few weeks. The new jME gl state machine management stuff I've been working on has definitely moved the engine towards greater stability and quicker execution. Mark was a big help in testing and implementing that system, even as I got on his nerves from time to time. (Thanks, Mark!)

Another thing I'm proud of at work is a new terrain system and tool support that makes coloring, splatting and manipulating terrain both easy to do and capable of complex, high quality results. Like both Mark and I say in our blogs quite often, I can't wait until we can show this stuff off.

Mark has been working on an animation state machine that handles transitions between states and animation timing, etc. in such a way as to give our characters nice and smooth animation. I'm very impressed with it. He's also been very patiently weeding out bugs in a multitude of systems both on the front and back ends of the game which has kept our plethora of demos from fiery deaths.

Odds and ends... jInput tablet support was successfully petitioned for and should be tested and in there soon. There's a revamped jME sound system that I hope we can check in sometime soon. There's more state bug fixes and expanded state settings that will go in with the state management overhaul. Also, a new shader system is on the horizon (planning to begin in the next few months I'm guessing.)

Hmm, I guess despite the demos we were still able to be somewhat productive. :) Stay tuned for more.