Some core API design changes need clarify

I think I have working with jme3 for long time before about 7 months off and now I have to catch up with lastest changes in the core API. I just review those changes. Version 3.1 beta 3 to be specific.

That’s why some clarification may help me and other who need upgrade to the new core a lot.

  1. LegacyApplication is the new thing. Introducing this class will break few libraries which tied with Application in the past (tonegod gui, forester…). Luckily my framework tied with SimpleApplication also but can any core developer explain a little bit more about this breaking changes.

  2. Did we have custom bucket yet? The last time I read something about custom bucket and get very excited. Do we have such render with custom bucket?

  3. Any new features or idea in mind with LWJGL3 upgradation?
    LWJGL3 support (beta) (thanks @DannyJo)
    Improved OpenGL 3.2 core profile support
    JOGL backend improvements to support new unified renderer backend

  4. Did we integrate @nehon 's animation system yet? How it will impact the old animated character or animation controls?

Just skip the questions if not worth your time. Thanks a lot!

I’ll defer to Paul for the Application change. But for the rest:
2. No custom buckets no… Might come at some point but definitely not in 3.1.
3. An experimentation for now. I’ll defer to danyjo too.
4.monkanim is still an unreliable WIP. Will not be available in 3.1. It’s designed to not break the old system.

We had to make this change for a future refactoring of Application precisely because that would break everyone. Now as long as everyone writes to the interface they will be fine.

The issue was AppStates that depended on the Application class. Changing to something better in that case would have been pretty impossible. So we chose to break a few apps/libraries that follow bad practices (extending Application directly) so that we could improve things more generally later. The improvements were too big of a change for 3.1 but we could at least setup for it.

Everyone following good practices should only have to recompile. Application still exists but now it’s an interface with the Application class’s original methods exposed. Anyone extending Application directly (a bad practice) can now extend LegacyApplication instead.

Examples of improvements:
-better support for app states at a base level
-moving the built-in viewports and root node management into app states. (forwarding the existing interface methods like getRootNode() to those states)
-moving input manager, etc. to app states.

Essentially, a new AbstractApplication will become a bag of app states. There will be a new BaseApplication that folks can extend instead of SimpleApplication (though they can continue doing that also)… and BaseApplication will by default include the standard app states but subclasses will be able to tweak that set (like they can now with the super() constructor).

We need to get away from the “simple” in SimpleApplication because too many folks were avoiding using it because “my game isn’t simple”… and we need to get rid of all of the protected fields. They are nice for quickly writing an example but they ultimately confuse the users that they are trying to protect since those same users have no idea where these magic values come from. “How do I access ‘camera’ from my different class?” and so on.

4 Likes

It’s clear we make this breaking change for the great of good. I will update those libraries also because my games are still depend on them. Thanks for clarifying!