Implement dark overlay for menus and automap #547
Conversation
andrikpowell
force-pushed
the
dsda-dark-overlay
branch
from
84d3ea1 to
238cffd
Compare
|
I've done a force-push as I found an issue regarding the overlay menu and STBAR... However this force push fixes all the STBAR issues for Doom and Raven. |
andrikpowell
force-pushed
the
dsda-dark-overlay
branch
from
238cffd to
0323bd7
Compare
I've decided to extract this and place it into another pull request... It's not that related to this PR, and is honestly a separate issue altogether. |
|
Set to OpenGL mode, go to the general menu and wait a few minutes - the background will start to flicker. On my system it seems to happen more often with VSync turned off. |
|
So the map overlay keybind cycles thru these 3 options. I dont like that since I use overlay when playing, but when I want to check the map name, coords, etc, I switch to no overlay. This will make me have to cycle thru 1 more option. Its one of those small changes that affect the players in annoying ways. I think it would be best to have an option in the automap menu to decide if the overlay is faded or not. |
|
[Bug] Being in the faded menu, but then pressing CMD+Q (Mac keybind to bring up the "Are u sure u want to quit" prompt)and then cancelling: keeps the titlepic faded, and is only fixed after pressing Esc to bring up the menu again This doesnt happen with the Texture option |
|
Can you remove the animate logic altogether? Since its always false + it looks better with no fade |
|
I've removed (or extracted for Nyan Doom) the overlay fade logic. Point is it's now gone for DSDA Doom. In addition, I've fixed the Mac "CMD + Q" overlay issue. I spent a full day trying another approach for the overlay logic, but it wasn't very compatible with disabling itself when the automap overlay is present, so I think the current way is better... I really don't wanna talk about how long I spent on this... I plan on moving onto the revising the automap logic next :) |
|
Ready for automap dark overlay review |
andrikpowell
force-pushed
the
dsda-dark-overlay
branch
3 times, most recently
from
16765a0 to
bfb2739
Compare
andrikpowell
force-pushed
the
dsda-dark-overlay
branch
from
a5b30b4 to
448f03e
Compare
andrikpowell
force-pushed
the
dsda-dark-overlay
branch
from
448f03e to
b852a15
Compare
|
Ok, fixed up PR and simplified commits 👍 |
|
And I see that Textured only "kicks in" when going into sub-menus of Options, while Dark is straight when going into Options. Its inconsistent, but I kind of like it like this (and woof does the same). So no need to change this, just wanted to note it |
|
Thanks! |
This PR adds the dark overlay that Woof has.
I've implemented it via
V_DrawShadedwhich gets directed to two different functions depending on OpenGL or Software (this is how most render functions currently work in DSDA Doom)The
V_DrawShadedfunction includes a gradual fade option (dboolean animate) that's used in Nyan Doom, although I've set it to false in both instances that it's used here to match Woof's implementation.The automap now has 3 overlay settings in the same way Woof does: "No Overlay", "Overlay 1" (what DSDA already had), and "Overlay dark" which adds a translucent background. The dark overlay is also compatible with the DSDA Doom Minimap.
The final commit here is probably the most controversial, but I wanted to bring it up here. It's because of this commit that implementing the dark overlay was actually harder to get working for DSDA Doom compared to Nyan Doom. In order for Nyan Doom to support overlapping HUD icons and statusbar animations, I have the statusbar always refresh in Software just as it does in OpenGL. In my testing I haven't run into issues or slowdown by doing this, and it fixes many statusbar bleed issues with PWADs such as "Pirate Doom II" and "200 Line Christmas".