Support CstDoom3 GUIs for aspect-ratio-independent HUD #641
Conversation
|
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. |
|
Hi Daniel! many thanks for your effort! I really appreciate it! I've tested with dhewm3-1.5.4 1305 and dhewm3 1.5.4pre 1305 without z_cstd3_guis.pk4 with z_cstd3_guis.pk4 z_cstd3_guis.pk4 log i'll try to fin what happens and ill tell you. |
|
Thanks for testing! :) However,
those are old versions, it should be 1.5.5pre, and you specifically need to use the dhewm3.exe from https://github.com/dhewm/dhewm3/actions/runs/12840240228/artifacts/2450198235 (that I linked above), because all others don't have the CstDoom3 code |
|
this time the pk4 load fine, but still don't have effect on HUD. |
|
oh right, one thing I forgot: you have to set the |
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?
If GUIs with CST anchors are there, they should be displayed correctly. With standard GUIs this doesn't make a difference, so it doesn't hurt.
|
Does it work with the CVar set to 1? Anyway, the updated binaries for Windows can be downloaded here (under "Artifacts"): https://github.com/dhewm/dhewm3/actions/runs/12878746410?pr=641 |
|
Hi Daniel, sorry for don't answer you. I've tested the cst_hudAdjustAspect 1 and yes! this work flawessly! |
|
Thanks a lot for testing, good to hear it works for you as well! |
|
but... there's a chance to implement com_gameHz and com_preciseTic on this branch? 😌 |
|
I will eventually rebase the code of #585 to the then-current master branch so it will include this. |
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.