Modding, Mission Design, and Coding > FS2 Open Coding - The Source Code Project (SCP)

Possible new UI systems for FSO

(1/14) > >>

m!m:
The current systems for presenting a user interface in FSO are severely lacking. The first system is to one used to render the main UI (e.g. options menu, briefing screen, ...). It is limited to the two main resolutions and is unable to scale correctly to the screen size which means that this system is not usable for adding additional user interfaces and upgrading it would be a monumental task. The second system ist the WMCGUI which is used in the lab but that is a pain to work with. There is a third option which involves rendering the UI with Lua (and that has been done already by some recent mods thanks to the system developed by Axem) but I will take a look at that option later.

My primary goal would be to build a new system that could be used and extended by mods to provide custom UI screens. I have looked at a few third- and first-party solutions and I will list the advantages and disadvantages I see if we would use these systems. Here is my list (in no particular order):

* CEF/Chromium Embedded Framework This is basically the chromium web-rendering engine as an embeddable component. This allows to use HTML/CSS and JavaScript to create user interfaces. I already integrated it into FSO some time ago so most of the work is already done.
Pros:

* Extremely flexible. Since it uses modern web technologies the UI can be pretty much everything.
* Overwhelming amount of resources available online since web technologies are pretty much everywhere todayCons:

* No direct scripting support. All dynamic actions have to be coded in JavaScript and Lua can't influence the UI directly. If a custom UI would be implemented using this it would need to be developed in Lua and JavaScript.
* Uses a lot of resources. The chromium DLLs and resources are very big and would need to be distributed with FSO which increases the download size
* Uncertainty about what is contained in the code. There were a few instances in the past where Google added something to Chromium which compromised the users privacy.

* MyGUI: A relatively simple UI system which also has a WYSIWYG editor.
Pros:

* Self-contained solution with pretty small footprint
* Has a renderer interface so we could integrate it into our own rendering engineCons:

* Not widely used so it may have bugs or incompatibilities
* Limited amount of existing widgets
* No built-in Lua support so we would need to build that ourself

* CEGUI: A very mature GUI system that is used by a lot of other projects. Has a WYSIWYG editor.
Pros:

* Modular design which allows to use our own implementations for the renderer and resource loader
* Mature project. A lot of resources available online
* Seems to have support for Lua scripting but I am not entirely sure about thatCons:

* Development slowed done somewhat. Not necessarily bad since we might not need any new features
* Bigger footprint which may make is harder to integrate into FSO

* libRocket: A UI system which uses an HTML and CSS dialect to declare how the UI should look like.
Pros:

* Has a decent amount of documentation since it's also in use in other projects
* Designed for extensibility. Rendering backend can be exchanged.
* Designed to be used in game engines
* Has built-in Lua supportCons:

* Development slowed down a bit in the last few years and the main website has not been updated in a while
* Uses something that looks like HTML but is not entirely like it which may cause confusions

* Use an HTML and CSS renderer (e.g. litehtml) and build our own system around it
Pros:

* Has the advantage of existing resources without the overhead of an entire web browser in FSOCons:

* Requires a lot of implementation work
* Lua interface would need to be written by us
* May be missing UI elements

* Implement our own solution using Lua: Axem already demonstrated that the existing Lua interface can be used to create great UIs so we could extend that and integrate it into the engine.
Pros:

* No external dependencies
* Can be expanded by simply editing the scripts that draw the UICons:

* Requires some additional work to make the library universally usable
* The entire UI would need to be written in Lua
* Reinvents parts of the wheel

I have no strong preference for any of the solutions but IMO libRocket and CEGUI are probably the best solutions but I would like to hear alternative thoughts about that.

Those are all the solutions that I can think of at the moment. If you have an alternate solution then please add it below and I'll update this list. I would like to hear some thoughts from both coders and modders so we can find the best solution for everyone involved.

m!m:
I have done some research and it appears that neither CEGUI nor libRocket support animated images directly. I found some resources which describe how such a feature could be added but it is not supported natively (the custom HTML engine obviously also doesn't support it).

niffiwan:
Well that's a pain, like you I'd considered those two to be the best to integrate. Do all the other options support animated images?

m!m:
APNG support can be added to CEF but AFAIK it's not supported natively. There is a Chrome extension for APNG display so it is definitely possible with some JavaScript. EFFs will not work since they are a custom FSO format.

I haven't looked at MyGUI in detail but it's pretty simplistic so I wouldn't expect it to have support for that.

The Lua solution obviously supports it since that uses our rendering code.

Dragon:
TBH, I don't think that something as bloated as Chromium is a good idea for FSO. I don't know what exactly do you mean by "UI", but if it messes with either the HUD or the pause dialog, it needs to run in-mission and not degrade performance. And even if it doesn't, I certainly wouldn't want loading times to go through the roof just because of UI (models and textures make it long enough). One thing I noticed about Chromium-based browsers is that they tend to gobble memory (Opera 12 FTW).

Navigation

[0] Message Index

[#] Next page

Go to full version