Many of my coworkers who already worked with a c++ engine were using it. and seems it’s the no brainer choice when you do ui in 3D with C++.
However looks like you have not a lot of option for styles… which is ok when you do a technical application (like a graphic demo or debug ui for an engine) but for a game it can be an issue. I can be wrong but I couldn’t find a way to customize the ui much… but maybe there is.
The idea would be to hook it into jme of course, as jme is really missing a solid ui library for richt ui applications. (The ones we have all scale not good to large mmo like uis)
I currently use Lemur, and for example simple things like scrolling tables are missing (kinda a base requirement for inventoy and marketplace screens)
I’m currently evaluating if implementing that ui is simpler than extending lemur enough.
FYI: the ListBox, GridPanel, scroll, model separation was designed with tables in mind. For example, I think it’s possible to have like a list box per column with a single scroll bar unifying them. Not necessarily using the ListBox class directly but that’s the design.
I had some extensive problems with javafx performance for the tradeuis (aka several hundret of entries with images ect) Also javafx on linux is sadly in a near desolate state (software barely hardware accelerated)
Thats why i switched to lemur in the first place. Btw. have you found a way around the java9 breaking change thing i have in the back of my mind?
I used fxml extensivly, and i had issues, that creating a ui from it required several seconds for more complex ones. Mainly because the core implementation was using a shitload of reflection during creation. The other issue so far is, that the resulting imagebuffer needs to be copied on cpu, since javafx does not nativly export the opengl texturebind.
I beg to differ. If only I do stuff yes, but FXML was easily off-loadable to friends with only a little bit of introduction required. In fact this was a massive time saver. In fact this was so usefull, that I have a created a small lxml parser for lemur.
Another problem is the retaining of state. For my inventory screens I started to throw away all components each frame, as the hassle to synchronize the state over multiple thread barriers was really difficult. Just rebuilding it each frame did the trick, however this is already the mindset of a immediate mode ui library.
I could mix lemur and javafx, sure, but then I would also need to synchronize the styling that it does not look awkward, and ensure that the input handling does not create a lot of issues. And I would still ge tthe framebuffer copy as a fixed cost even if no ui is displayed.
For my current way of writing I think that a immediate mode ui is the better approach.
Updating an inventory screen was actually around 5-10 times as much code as creating it initially, especially since it could be changed from the ui and from other non ui based stuff, so I had to do a diff every frame between displayed and actual state. This was a real nightmare to do properly that I eventually gave up, and just recreated the entire ui every frame. This is already the concept of a immediate ui framework, so it is a better natural fit. This issue was magnified by the fact, that I cannot query my game state from the JFX thread, as it is not able to see a properly synchronized view. (game logic is multi threaded due to es), so I had to collect all state and send it to the jfx thread for the updating anyway.
Also javafx on linux is sadly in a near desolate state (software barely hardware accelerated)
