Adapter classes? about libgdx-screenmanager HOT 2 CLOSED

Hey @Frosty-J!

In libGDX, we have the likes of public class InputAdapter implements InputProcessor. Would something like this be sensible for libgdx-screenmanager?

The "idiomatic" approach in libgdx-screenmanager would be to define your own Screen class, i.e. MyCoolGameBaseScreen, which extends ManagedScreen and then use that in your Game class as follows:

public class MyCoolGame extends ManagedGame<MyCoolGameBaseScreen, ScreenTransition> {

   // ...

}

This has the advantage that one can add various other useful (game-specific) features to the base screen. But I can see that for most smaller games (and probably for jam games in particular) that is just more boilerplate code. Hence, I think adding a screen adapter makes sense and also aligns the library closer to the way libGDX itself is structured.

I've never used create() (don't see much advantage to it over a constructor)

The create() method has one main advantage: it allows you to defer initializing the screens. This can come in handy if you are using a loading screen to load your assets first (the loading screen can then call ManagedScreen#initializeScreen() which internally calls create()) or when you want to defer loading until the screen is first shown (by default create() is called after the screen is first pushed).

from libgdx-screenmanager.

I've kinda lost touch with libGDX as of late, but next time I'll make my own base Screen and see how that goes.

from libgdx-screenmanager.