-
Is it possible to make KtxGame render multiple screens overlayed? For example i have a GameScreen and a GameUIScreen. I'd add them both, and the first one added gets rendered first, and the second one added gets rendered over top the first screen. |
Beta Was this translation helpful? Give feedback.
Replies: 7 comments
-
Not out of the box, but it's trivial to implement.
|
Beta Was this translation helpful? Give feedback.
-
As a side note, if you need more functionalities than just the rendering, I'd consider using a single screen with multiple managers and renderers for each section of the game logic. Things start to get complicated when you have to track resizes, input, etc. I think your best bet would be to use a common base class with some shared data that delegates some of the logic to appropriate managers (a variation of the 2nd approach). |
Beta Was this translation helpful? Give feedback.
-
Thanks for the really quick answer. This gives me some good ideas. I do need to handle input on the ui screen first, and block it from being sent to the base screen in some cases. For example clicking on an ingame enemy vs clicking on a ui element. If I click on a ui element, I don't want to also click on the enemy behind the ui element. However there might be some elements where its desirable to pass the input such as a transparent chat box. For me it kinda made sense they would be separate screens with different cameras/spritebatches so that the scaling of the game and the ui don't affect each other. |
Beta Was this translation helpful? Give feedback.
-
I don't think you need a separate screen for that, just split the logic into a few classes used by a single screen. You might want to look into If you'd still like to give the overlay screens implementation a try and come up with something pretty generic, I could review it and add to KTX as a utility. |
Beta Was this translation helpful? Give feedback.
-
I think you are right on using a single screen, so I'm going to try that route first. Also would you recommend lml or using the dsl? I'm familiar with javafx so splitting the view from the logic seems nice. |
Beta Was this translation helpful? Give feedback.
-
KTX DSL is more stable, thoroughly tested, validated at compile time and much more powerful. It supports 100% of the Scene2D API, as it's just a thin layer with some syntax sugar. With LML you don't have to recompile the application to change the views and you have a clear separation of the game logic and the UI. You could even dynamically create widgets from editable strings, as showcased in the official examples. However, I don't support LML anymore - it never reached a similar maturity level or popularity to KTX (and GWT support still wakes me up at night). There are some features of LML that you won't see in KTX, but if you want my honest opinion, I'd choose KTX in a personal project simply because of the comprehensive test suite. I'd only consider LML if I wanted to support custom scripting of the game - HTML-like system for custom UIs seems easier to grasp than Kotlin code (not to mention there's no need to recompile the game). |
Beta Was this translation helpful? Give feedback.
-
Thanks for your answers, they helped a ton |
Beta Was this translation helpful? Give feedback.
Not out of the box, but it's trivial to implement.
KtxGame
overrideYou can store an additional
Screen
inKtxGame
and overriderender
to draw it before the current screen:This way you're keeping the base screen logic in a single place, but you do have to mess with the
KtxGame
API.Screens composition
You can pass a re…