<== Continued from previous post
A new UI
I've looked into integrating RmlUi to determine which challenges are ahead in that area. I've experimented with replicating the look of the HUD in HTML, but so far i haven't been able to reproduce the exact method used which involves using a grayscale image colored with a specific value and whose alpha value is affected by the saturation of the color.
All of my findings are included in the Github issue:
https://github.com/SamVanheer/halflife-unified-sdk/issues/453
If there is a way to replicate the HUD's exact appearance in HTML then it probably won't work in RmlUi since it will likely depend on CSS features that RmlUi doesn't (yet) implement.
Until it's possible to render the HUD in RmlUi it isn't worth trying to integrate it into a mod.
I've also done some investigation work into how modern engines handle UIs to see if any of them provide their UI toolkits as standalone options that can be integrated into an engine this old.
My findings are as follows (not an exhaustive list):
- Unreal engine: Uses Unreal Motion Graphics, a tightly integrated toolkit that depends on other Unreal features like blueprints to function.
- Unity engine: Uses UGUI, a GameObject-based toolkit. Totally dependent on the engine to function and written in C#.
- Godot engine: Uses Godot UI, a tightly integrated toolkit that builds on Godot's class hierarchy.
- Source and Source 2 engines: Use Panorama, a tightly integrated toolkit that uses a web-like development stack using XML, CSS and Javascript. It integrates with the engine to allow features like particle systems and model rendering to be embedded in the UI itself. Panorama's XML is not strictly HTML; it's very similar but is an evolved form of VGUI (it uses `Panel`s just like all VGUI versions).
Panorama is the closest to RmlUi in functionality but like all toolkits listed is tightly integrated into the engine.
This integration allows engine functionality to be used in the UI but precludes integration into other engines. None of these toolkits are available for standalone use, and even if they were they all use modern graphics APIs which makes integration even harder.
All of these toolkits are optimized for use in games, which means they update and render once a frame.
Another alternative is Chromium Embedded Framework 3 (CEF3), used to implement the UI in various desktop applications like Steam, Discord and Visual Studio Code (using Electron, a desktop application framework built on top of Chromium).
Chromium is designed to power web browsers; its architecture is designed around this use case. In practical terms this means Chromium uses subprocesses to perform tasks to prevent a browser tab from freezing the entire application, to prevent one tab from using exploits to read another tab's memory and other security and performance-related issues.
In part because of the use of subprocesses Chromium uses a lot more memory. Steam for instance uses around 470 MB of memory when running idle in the background. Discord uses 315 MB. It's possible for Chromium to use more memory then the rest of the game combined.
Chromium renders frames on its own, out of sync with the application. It's possible for Chromium to render more frames than your application needs, but also less, and probably lagging behind which can be a problem in a real-time environment like a game.
Additionally since pages are handled by subprocesses exposing Javascript APIs to UI logic isn't as cheap as it is with toolkits like RmlUi and Panorama. Half-Life's UI code accesses game state and in some cases modifies it as well which is complicated by the need to also communicate with the main game process.
GoldSource uses CEF1, an older single-process version of Chromium to render the HTML-based message of the day in Counter-Strike and Day of Defeat. It's been out of support for 10 years and can't even display the official Counter-Strike website due to a lack of support for modern secure connection technology. This integration is limited to rendering frames for display in VGUI2; it can't allow interaction between a website's Javascript and the game itself.
There aren't many cases of games using Chromium for their in-game UI. Here are some articles and discussions that covers the subject in more detail:
I couldn't find any references to games that actually use Chromium but i have seen discussions about it in passing before.
A couple mod teams have attempted to integrate Chromium into mods before (GoldSource and Source) but it has always led to failure due to the problems listed above and overall technical challenges involved with such a complex framework. If you really want to use it, you'd better prove it can be done properly first.
Based on my findings i'd say trying to integrate a new UI toolkit is a waste of time unless you can guarantee these things:
1. You can replicate the UI in HTML exactly as in the original without performance issues
2. The toolkit of choice can be integrated into a mod and works properly on Windows and Linux and when using the OpenGL
and Software renderers (Software mode support can be dropped if needed, but for the Unified SDK in particular it's not an option without a major version change)
3. The implementation runs well in general and on older systems in particular. Given that Steam is dropping support for older platforms due to CEF as well this isn't a major challenge but Half-Life players tend to use older systems
Remaining work to be done
- MIT license all community-written Updated & Unified SDK code
- Move projects to twhl-community organization
- Add any required documentation on development process that is currently missing
I've run through all of the games again to test for any remaining issues. A handful were found and fixed and are listed above alongside fixes found by others.
This just about wraps up all work for V1.0.0. Everything that can be done in a reasonable timeframe has been done, all major issues have been dealt with and the last full test shows the games are working as expected. Once the remaining work listed above has been completed all projects are ready for a V1.0.0 release.
However, the full release of V1.0.0 will have to wait until after Valve has finished what they're working on to avoid having to release a patch in case there are any problems. People have noticed
activity in a new password-protected branch that indicates the games are being updated with better controller and Steam Deck support.
No details are available so to avoid potential problems V1.0.0's full release has been delayed until these changes have been released by Valve. Given that controller support is implemented in the client dll which is part of the SDK this will likely mean mods will have to update to get the same changes.
That's probably meant to release on the 25th anniversary which is a week from now, so it shouldn't be a very long delay.
Once all of that stuff is sorted out all three of the Updated projects and the Unified SDK will be part of the twhl-community Github organization and will be maintained by the community.
The map decompiler will also be moved over after i've double-checked all of its features and the text color bug in Avalonia has been fixed.
Half-Life Asset Manager V2.0.0 will also receive a full release shortly once all of the above has been dealt with after which i will begin working on V3.0.0 which aims to replace the graphics code with modern OpenGL and to hopefully provide a fully functional Linux version.
I'd like to thank everybody for helping to develop and test these projects and hopefully they'll be fully released soon for everybody to try out and play with!