<== Continued from previous post
New UI: preliminary research
I've been looking into RmlUi a bit more. There has been work done recently to refactor its render backend which would make it easier to integrate in a Half-Life mod.
I see two possible implementations:
The second option is probably more efficient but means dropping Software mode support. To prevent users from reporting this as a bug i'd have to add a forced quit command when the engine is started in Software mode (
The best of both worlds is to use OpenGL when the engine is loaded in OpenGL mode and the VGUI1 workaround in all other modes (D3D mode returns 2, though it obviously won't ever do that now since it was removed).
This work is planned for RmlUi 5.0
(currently at 4.4) with no ETA so i don't expect to be doing this any time soon.
In the meantime i can make a standalone test program to see how feasible it is to make a HUD with it. That's a quick way to determine if the library is an option here at all.
I'm not planning to add a new UI in V1.0.0 so it's not a big deal if it takes time. I've given them some feedback on CMake modernization they want to do to help them along.
I've also looked into how VGUI1 and VGUI2 handle TGA loading. Both use the same backend that boils down to
calls, it doesn't pass through the engine's texture loading routines which handle loading, filtering, resampling and rescaling.
VGUI1 supports very large textures (134,217,727 RGBA32 pixels max) but doesn't free the main RAM buffer. VGUI2 limits textures to
256 x 256
pixels but doesn't keep a buffer allocated.
All backends support 24 and 32 bit uncompressed TGA with no custom origin coordinates (only
use a non-default origin, and
can probably be changed since it's used by Steam and not the game), so sticking to that format will work regardless of which option we use.
This means we'll need a tool to take the sprites and convert them to TGA. For animated sprites we'll need a framework-specific solution: RmUi has sprite sheets (single large texture divided into rectangles for each frame) but VGUI1 and 2 don't have a built-in feature so that'll require splitting frames into separate textures either at the file level (
, etc) or at file load time.
Either way a separate file is needed to specify animation frames. It is possible to just use sprites here if we handle loading ourselves but i'd like to get away from the limitations of the sprite format (256 colors for all frames combined, variable framerate sprite frames which aren't supported by the engine anyway, etc).
Some other container format could work, even Source vtf might work here but i'd prefer to keep things simple and RmlUi has its way of specifying sprites already.
Only once a decision has been made on where to take the UI can i figure out how to deal with the Opposing Force image replacement problem. This depends on the UI framework since the manner in which images are referenced differs between them.
Regardless, the actual directory structure will likely be:
The default UI will go in the
directory, with Opposing Force-specific UI images going in a subdirectory, matching the structure used for other file replacements already in use.
The choice of framework will also influence how other UI-related issues will be handled, so there isn't much to gain from discussing that now.
Remaining work to be done
- Merge pull requests into repository (done)
- Implement new sentence playback system, add all sentences (done)
- Review malortie's work and provide feedback (done)
- Global sound replacement (done)
- Global sentence replacement (done)
- Rework the client command registry to eliminate use of shared pointers
- Rework game configuration system to no longer rely on
std::any to harden the API against incorrect use
- Update Packager tool to provide list of files not included in the package to spot missing files more easily
- Update changelog to include all changes
- Write documentation for all new features (partially complete)
- Investigate making the wiki accessible for pull requests to allow direct modification or make the wiki part of the repository Vcpkg does this, albeit for their website)
- Review all changes
- First alpha build
- Stress test the three campaigns and fix issues that show up
- First beta build
Work expected to be needed in the future (in no particular order):
- Networking system (transfer contents of replacement files, precache lists, possibly other immutable data): work in progress
- New UI (including HUD image replacement for Opposing Force): being researched
- Versions of Opposing Force-only HUD images that have the scanline effect removed: some preliminary research done, needs more investigation
- A way to start all three campaigns from the main menu. Probably the same solution as used in Condition Zero Deleted Scenes (menu button that starts a map that opens an SDK-level menu that enables campaign and training selection). Depends on the new UI
- Unknown unknowns
There has also been more work done on the Updated projects with bug fixes and improvements which i'll list when i release the next set of beta builds. I need to investigate a couple more things before i can do that.
Many thanks to a1batross, hammermaps, Shepard, BryanHaley, Ronin4862 and malortie for helping to get this project much closer to its first release. I couldn't have done this without you.