Support CstDoom3 GUIs for aspect-ratio-independent HUD #641
+572
−37
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
those GUIs are aspectratio-independent doesn't properly work yet, esp. together with my hack that makes sure menus are rendered in 4:3
In idWindow::Redraw(), I had to make sure the menu scale fix (which, if enabled for a window, renders that in 4:3 with empty or black bars on the side if needed for widescreen etc, instead of stretching it) is disabled if a window uses CST anchors, because the CST anchor code also adjusts for the display aspect ratio and if we do both, things get distorted in the other way. The biggest change is that idDeviceContext::DrawStretchPic(Rotated) now has code to adjust the coordinates for both CST and the menu scale fix, so idDeviceContext::AdjustCoords() is mostly obsolete - it's only still used by idRenderWindow. Unlike DstDoom3 now that extra adjustCoords argument to those Draw functions indicates that any coordinate adjustment should be done, so if it's set by a caller, it's set to true. I removed idDeviceContext::AdjustCursorCoords() because it was only used in one place anyway
incl. backwards compat for older savegames. only partly useful: old savegames only work if you didn't change the gamedata, with the CstDoom3 .gui files, loading them crashes. I don't think that can be avoided, apparently Doom3 has no way to detect that the GUIs have changed?
This was referenced Jan 18, 2025
|
Testbuilds for Windows under Artifacts: https://github.com/dhewm/dhewm3/actions/runs/12840240228 |
|
Note that neither CstDoom3 nor dhewm3 with those changes has widescreen menus or a widescreen PDA. But the HUD is widescreen now. It might be possible to create a widescreen-compatible main menu and/or PDA with thist CstDoom3 anchor stuff. They didn't do that though, and I have no time/motivation to try it myself. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As requested in #324.
You won't see any difference unless you use CstDoom3's GUI files. But note that you can't just use their .pk4 files, because they contain other things incompatible with dhewm3 (I didn't port any gameplay changes from CstDoom3).
For the basegame I prepared this .pk4 (rename the .zip to .pk4 after download, Github doesn't support attaching .pk4 files): z_cstd3_guis.zip
It's for the base game, so put it into
Doom3/base/, next topak000.pk4etc.Also note that old savegames will stop working once you add
z_cstd3_guis.pk4.I'd appreciate if someone else could create cleaner .pk4s with .gui files for both the base game and d3xp and upload them somewhere, so I can link them on the dhewm3 page once this is merged.
I'm not gonna ship them with dhewm3, for license reasons and because so far dhewm3 could avoid shipping any own gamedata and I'd like to keep it like that, if possible.