The GUI library situation

Meta
1

So I have been talking about the possibility of switching GUI libraries, again (sorry). Mainly because of a few really hard to fix issues (that no one has offered to solve, so I would have to spend a lot more time on them):


This is the same issue as above:

There are some problems with HTML and/or CEF:


So while making GUIs with HTML and CSS is more approachable than CEGUI where there is really no up to date information about it anywhere and there are really arcane properties you just have to know to do some thing, there are some technical problems with it. And of course there is the performance aspect as it takes about a second to startup the GUI and it takes a few hundred megabytes of extra memory and probably cause more CPU load than other GUI solutions. And the release is 100 megabytes bigger because of including it.

So I’d like to hear some opinions about what is the best way forward. For now until this is solved I also suggest that we refrain from doing a lot of work on the GUI as if we change the GUI library the GUI needs to be redone anyway and that is a good opportunity to redesign it completely.

Here’s my thoughts about the situation:
I feel like the issues with CEF are really, really hard to solve and once the game is stable enough that many players would reach multi-hour gaming sessions, it will (almost) be an absolute show stopper that the GUI just stops working completely after an hour. And I’ve already had very arcane problems with it in the past (https://magpcss.org/ceforum/viewtopic.php?f=6&t=16313). And from having experience with CEGUI it isn’t much better in terms of weird font height issues, crashes due to bugs in their font implementation and the overall large amount of different configuration files needed to make it work. And CEGUI development has been recently pretty much on hold.

I haven’t used MyGUI, which is probably the only other as portable GUI library that might suit our use.
And then there are a few random unknown GUI libraries but I don’t think they have a very good chance at being overall better than what I have tried. But feel free to suggest good ones if you know of any.

Finally we get to what I think is the solution: writing a GUI library myself. This is in many ways not optimal and has some issues that I need to resolve before I can get working, namely per object clipping with Ogre 2.1, proper z-ordering, and a good approach to text rendering (I’ll probably have to use FreeType and atlas textures). But if I get around those then the only problem left is that it is just very time consuming to make a good GUI library. It would be heavily integrated to Leviathan so I can save a lot of time compared to writing a really general library.

So here would be the main design points for the new GUI library, which should make it the easiest it can be for artists to make prototype GUIs in engine instead of just drawing impossible things (I’m kidding about the impossible part):

  • Well integrated editor right in the engine. So at any point you could just hit F10 and enter GUI editing mode allowing you to directly just drag the GUI elements around, hopefully making it very easy for non-programmers to make GUIs
  • Powerful resizing modes for the GUI elements to automatically fit almost any screen size
  • Composable widgets (so making new widget types from existing ones with ease)
  • All GUI scripting would be with AngelScript and the GUI objects would have simple exposed methods to make scripting the logic easy. And we can reuse the existing GUI updating logic with event listening support in the GUI

I’m not going to start on any of this (other than the basic research, I’ve already read many hours about font rendering) right now, but hopefully soon. I think it would also be possible to have a period where some GUI views could use CEF and some could use my new system to reduce the amount of initial problems.

This got pretty long but I hope at least someone reads this.

1 Like
2

About zooming not working, when i added the scrollbar to the help menu it worked fine and that wasnt taking up the whole page, same with the editor organelle menu.

3

But does the scrolling work with the mouse wheel (it has never worked for me)? That’s the real issue, because right now the switching between sending the scroll to the GUI vs the microbe code, is the problem.

4

Writing a library from scratch sounds like a bad bad idea…
Are the problems you mention solvable by wrapping the current gui components in a leviathan-friendly object?

1 Like
5

Right now CEF is a huge behemoth that basically works through a few callbacks and custom message packs being sent to the chromium render process. And it’s very hard to tell what’s going wrong with it. There’s also the current cursor issue where it sometimes on linux ends up showing the wrong cursor image.

6

I suppose not. But i feel like writing a new gui library is a bad idea, we rewrote the game and it took a year to get a release out, i think what we have now works pretty good aside from some minor issues which can perhaps be solved by doing some engine things. This “if we have bugs , we have to completely switch our library everytime” mentality will cause alot of delays and has caused alot of delays.

Not knocking on you at all, what we have is awesome, but i think we should avoid switching libraries to fix bugs at all costs, this means you may have to put work-arounds in the engine, but its better then switching to a whole new library each time.

At least at this point.

7

At this rate we’ll end up writing our own compiler by the end of 2020…

1 Like
8

The current whole implementation of detecting when keypresses (and scroll events) should go to the GUI is a massive hack with javascript being injected into each loaded GUI document to monitor what the active element is and if the mouse is over something that can be scrolled. And the problem is that not even that works and I’ve already spent more than a day’s worth of work on it. And I’m reaching a breaking point with the arcane belgium related to CEF where the documentation is sparse and many bugs and weird stuff is “it’s chromium’s fault, go tell Google to fix their browser.” With CEGUI at least I was able to fix the actual bugs and implement missing stuff but they have so much indirection and random stuff from over the years that it is very difficult to understand. Including a huge issue with supporting multiple different resolution windows at once.

9

The good thing about this is that if I do the few engine issues I have queued up for 0.4.1, it doesn’t actually slow down the development, other than I’m not working on other issues.

10

But if we switch to a new library we have to completely rewrite all our gui, again, for like the third time. Thats where the delay will come, yeah we have me and a few others doing game code now(mostly me :stuck_out_tongue: ), which means different programmers can focus on different things. But its not ideal, and there is no such thing as a “perfect” library, CEGui will have some other bugs we have to deal with.

11

You not working in other issues is like half the active programming team from 0.4.0 doing something else, plus there’s still integrating it with thrive (which would take some time) and we would still have to fix all the bugs that pop up. And we would have to mantain it, like adding every widget that we might need (which i assume chromium already has).

1 Like
12

It has just the basic html forms stuff, but JavaScript libraries for nice looking controls are available.
Right now we only have buttons, bars and text as the GUI widgets, and scrollable content areas. So it’s not as bad as it sounds.

13

I think the direction is that we will at some point want to base our future GUI on the drawings by @Minegamer117. So there is anyway a huge GUI rewrite coming up. I do agree that it is a bit more work with a new GUI library to do that.

But I want to keep the design of the GUI library very light and the only probable bug prone areas is the text rendering and clipping / RTT. So we shouldn’t hit any worse bugs in Ogre than the banana backgrounds as we already have.

14

maybe to fix some of the bugs we can keep using chomium, but grab a javascvript GUI library https://www.slant.co/topics/3286/~best-javascript-libraries-for-building-a-ui#8

15

Yeah, right now, but we’ll soon want to add an options menu (which means combo boxes and sliders), some way of seeing the microbes on a biome (for the agent system and such) which would require weirdo button layout stuff which images

16

I did a bit of reading on the Ogre forums and it sounds like others are struggling with the same issue.

There’s Ultralight but maybe that wouldn’t have the right licence for us. MyGui hasn’t been updated since 2015 which is a bit worrying.

I think it might be good to post for help on the Ogre forums before committing to anything, not that they are very helpful.

Can I ask, if you were to write your own library what is the minimum viable product. Like how much work would it be to get a basic gui that can show up and have clickable buttons? Having a whole complicated editor sounds good but what’s the least we could do to get by?

I’m sure you could write a great library, I guess the question is around how long it would take.

I agree that using JS + HTML seems to work well for the team.

1 Like
17

I highly, highly doubt that that can resolve the input consuming issue and the fact that the whole GUI freezes up and renders some leftover garbage from the GUI on screen.

1 Like
18

And also text boxes to name your cell

1 Like
19

Are either of these any help? Or something similar which just renders html + css in some simple way?

https://lexborisov.github.io/Modest/

20

That was one of the last things I read yesterday before deciding to make this topic.

I’m planning on asking about the best approach for making 2D clipped rendering on the screen, but I didn’t ask yet.

For that I’d like to first try replacing the microbe stage HUD. So it would need just a few basic buttons, image drawing and some basic bars. So it wouldn’t take that many months to get something ready for playtesting.

Basic text boxes aren’t that different from just static text.

That’s why it is such a shame that CEF has so many issues and no one seems to want to help with them.

1 Like