Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: prometh on November 24, 2013, 06:36:41 pm
-
Could use a stripped down WebKit. JavaScript is very fast and CSS3 can handle a lot (even 3D tilting) and rendering speed is always increasing. Would just need to place the HTML5 app on a layer above the game, and maybe below any "filter" layer (like post-effect glows, etc).
Using HTML5 can produce much faster results in the interface department.
Please don't get mad if this is a terrible idea technically or if it pollutes your source code with other languages.
-
This seems like a very odd suggestion. What problem exists with the FS interface/HUD that HTML5 (most likely a serious refactor of any interface code) could solve?
-
It's worth consideration, in the mix of possibilities. But at present I think we are pretty happy working and developing the in game UI as is.
We do utilise HTML5-esque features in the new Standalone server WebUI (http://www.hard-light.net/wiki/index.php/FS2_WebUI_Standalone). It could very well replace the server on all platforms in the coming months.
-
There are several problems with the old interface, not the least of which is the simple issue of it requiring over a thousand not-quite-similar files to be created and distributed, with a lot of hardcoded constraints. Like, for example, only being able to offer interface graphics either in 1024x768, or 640x480.
The problem with HTML5 and other interface engines is that they are massive libraries we would have to incorporate, and there's a lot of glue code that would have to be written in order to make it functional. So, while a more flexible interface is certainly something we would really like to have, the amount of work required to do it is prohibitive.
If a rewrite happens, it is much more likely that we'll stick with things we already know how to do in the code, like adding more extensive lua scripting support or adding flexibility through better tables.
It's worth consideration, in the mix of possibilities. But at present I think we are pretty happy working and developing the in game UI as is.
We do utilise HTML5-esque features in the new Standalone server WebUI (http://www.hard-light.net/wiki/index.php/FS2_WebUI_Standalone). It could very well replace the server on all platforms in the coming months.
I would argue that those two are not at all comparable. Generating HTML and parsing and displaying it are two rather different things.
-
I actually experimented with that a while ago but as The E already said it requires a quite big set of libraries and executables to work and getting it to work as a replacement for the FS UI will require a lot of work or might not event be possible at all because of the special file formats that are used.
Here is a screenshot of the results:
(http://imageshack.us/a/img827/7936/awesomiumtest.png)
For those interested, here is the source: https://github.com/asarium/fs2open.github.com/tree/awesomium (https://github.com/asarium/fs2open.github.com/tree/awesomium)
-
I'm not sure if this particular variation has been suggested, but it could possibly be the least intrusive way code-wise:
Render the custom interface on top or instead of the old one, and whenever the user moves the mouse or clicks on something, the screen position gets translated to the position of the corresponding UI element in the old interface (the custom interface would provide the necessary coordinate mapping) and the actions passed down directly to the old interface. The new interface wouldn't need to actually hook into almost any of the existing interface code, only capture the actions the user does, translate the coordinates and invisibly pass them to the underlying old interface.
It might sound hacky, but it could also be almost entirely isolated from the existing code.
-
I'm not sure if this particular variation has been suggested, but it could possibly be the least intrusive way code-wise:
Render the custom interface on top or instead of the old one, and whenever the user moves the mouse or clicks on something, the screen position gets translated to the position of the corresponding UI element in the old interface (the custom interface would provide the necessary coordinate mapping) and the actions passed down directly to the old interface. The new interface wouldn't need to actually hook into almost any of the existing interface code, only capture the actions the user does, translate the coordinates and invisibly pass them to the underlying old interface.
It might sound hacky, but it could also be almost entirely isolated from the existing code.
HACKS! I CALL HACKS!
That sounds pretty ugly, to be honest. Not only in conceptual terms, but also in terms of what the code would look like in the end. In order to get any interface rewrite going, we have to first go through the existing code and do a strict separation of interface and business logic; Once that's done, it will be possible to define an API that one can hook into (using lua or something), I would estimate this to be mostly trivial except for a few special cases where we are doing nonstandard interface things (like the briefing viewer, or the techroom viewer). It's just a lot of grunt work, and little of it will reap visible benefits for a loooong time.
-
Or we could actually use HTML to render individual interfaces by simply replacing the old interface. If no custom interface is provided then we would simply use the old code without any changes. That way we would also not have to worry about backwards-compatibility as the old code is still there.
-
There is that. But one thing I would like to have from an interface rewrite is the ability to redefine what is shown on a given menu screen. Being stuck with how the interface is designed now in terms of its menu flow is not ideal, to say the least.
-
If we design the API right we wouldn't be stuck with the current flow. Instead we could define a "general" stage which would contain pretty much everything and leave the interface design to the modder. We would have to expose the right bits of the FSO API via JavaScript to make it work for every case but I can't see how this could possibly go wrongTM.
-
Law of Murphy
-
Please don't get mad if this is a terrible idea technically or if it pollutes your source code with other languages.
Uber is doing exactly this thing for all their UI in Planetary Annihilation, so it actually may be worth considering.
-
Uber is doing exactly this thing for all their UI in Planetary Annihilation, so it actually may be worth considering.
Small issue: We are not a development studio with paid staff and a budget. Solutions that are workable for these are not immediately applicable to us.
-
true, but they might be doing it because it's the easiest way to do it.
granted they are in a position of having no UI and needing to make one, and FSO is in a position of having a functional UI.
all said though I can see making an HTML5 UI for FSO as a isolatable project someone who wanted to do badly enough, could do on their own in such a way as to not break backwards compatibility. so the question is, are there any volunteers?
-
I'm definitely interested but there are still more important projects to be completed although this project is probably not complicated.
-
There are several problems with the old interface, not the least of which is the simple issue of it requiring over a thousand not-quite-similar files to be created and distributed, with a lot of hardcoded constraints. Like, for example, only being able to offer interface graphics either in 1024x768, or 640x480.
But if the interface were replaced with a WebKit instance on a layer, most, if not all of those images would be replaced with CSS and SVG. It'd be scalable to any resolution, even with images.
Even the hangar views could be built with HTML. Mods could be built a lot faster.
-
But if the interface were replaced with a WebKit instance on a layer, most, if not all of those images would be replaced with CSS and SVG. It'd be scalable to any resolution, even with images.
Even the hangar views could be built with HTML. Mods could be built a lot faster.
I'm sorry, but did you actually read the entire thread, and the discussion about how this is nice in theory but would require a lot of reorganizational work in the engine that will take a prohibitive amount of time to complete? Because it's not the capabilities of an HTML-based interface we're questioning, it's our capability to manage that big a feature in a reasonable timeframe.