Dege wrote on 2026-10-23, 17:28:

It's needed for DX11 as well, independent on the backend API.

My playthru before this post was done with Best API, afaik it defaulted to DX11 when I measured stuff with RTSS, but I don't remember using 16BitDepthBuffer setting.
Maybe I just forgot I enabled it tho...

Dege wrote on 2026-10-23, 17:28:

Well, the rendering in dgVoodoo is a 2-phase process: […]
Show full quote

Well, the rendering in dgVoodoo is a 2-phase process:

• The first is producing the game output image internally through Glide or DX, this involves rendering at a forced resolution at Glide/DX level.
• The second is the general Presenter that maps the game output image (whatever it is) to the screen according to the scaling mode.

[Glide/DX game rendering at forced resolution] -> game-output image -> [Presenter mapping the image to the screen according to the scaling mode]
...
Btw, see the Quick Guide, there is an explanation with a figure for this: https://dege.fw.hu/dgVoodoo2/QuickGuide/

I'm rather familiar with all of this since I've used dgVoodoo for quite some time, and across many games and settings (so thank you Dege, you deserve the praise).
It's more that there are 999999 old games with 99999 iffy behaviors, and dgVoodoo is also getting patches, so there might be a curveball every now and then.
Then again, maybe I'm the curveball this time 😁

Except what 'Max' meant in exact X*Y, that's a new one to me.

Dege wrote on 2026-10-23, 17:28:

As far as I remember the DX verison of the game is purely software rendered.
So, you force the resolution to whatever with no avail, only the game rendered 800x600 image will be stretched to the image with the size of the resolution you forced (e.g. 1440x1080) (first phase) and that will count as the game output going to the screen according to the scaling mode (second phase). No actual 3D rendering takes place.

But if it's DirectX, why is it software rendered?
I mean sure, you need an API to display things but is that all that DX means to this game?

BTW this game has a DOS only version, and a Windows version (where Glide is also included), sounds just a bit strange for a 1997/1998 Windows game to just use a software renderer in DX mode, well at least above 640x480 that is, by that time I'd expect software rendering to already be either an option or a fallback, not the default nor the only kind of renderer...

OTOH why isn't dgVoodoo capable of changing resolutions of software rendered games?
This game even has multiple resolutions with software renderer, and software rendering afaik is also 3D rendering, no?

Dege wrote on 2026-10-23, 17:28:

Yes, the game asks for a 4:3 resolution (640x480 or 800x600). If your desktop resolution is 1920x1080 then the render resolution will be 1440x1080 as I mentioned.
But you can use the _dbg versions of the dlls: the debug log contains information about what resolution the game asked for and what is the actual rendering resolution.
Even a warning is there if the aspect ratio of the two are different.

I'll take a peek when I have some time.
That's in dgVoodoo v2.87.5 (spec release with Debug Layer) download?
PS: what's the tldr version of dgVoodoo WinMM OS uptime fixer?

Dege wrote on 2026-10-23, 17:28:

dgVoodoo does not support FOV extending (wouldn't even work with Glide games). That's a different matter.

Sure, but many fixers/wrappers/patches that offer widescreen resolutions often have adjusted/adjustable FoV (sometimes games themselves have it via their config), that's why it crossed my mind that maybe it's stretched due to lower res 4:3 FoV changed (wrongly) in relation to a 16:9 higher resolution, as that is sometimes the case, not related to dgVoodoo directly.
AFAIK that's the worst case, middle case is that FoV stays the same but view extends, and best case is if FoV is adjusted/adjustable, but again, it was just speculation and not really dgVoodoo related, but for game itself.

Dege wrote on 2026-10-23, 17:28:

I think it is only saved when "Enumerate refresh rates" is enabled.

A popup/info for this would be nice 😉

Dege wrote on 2026-10-23, 17:28:

Glide always sets not only the resolution but the refresh rate as well when initializing the graphics system. Games usually ask for 640x480 at 60Hz. And dgVoodoo respects whatever refresh rate the game is asking for (or the closest supported one).

1. Seems only enumerated (or custom res + Enumerate) resolutions will ignore 60Hz request in Exclusive Fullscreen AND Fullscreen Fake?
2. Still doesn't explain why Fullscreen Fake changes the refresh rate, it's a window, I dunno how a windowed app can do that?

*Reminder that I still don't get the refresh rate change with Fullscreen Fake.

Dege wrote on 2026-10-23, 17:28:

2mg wrote on 2026-10-11, 04:35:

3b. "Enumerate refresh rates" actually works as expected, tho it reports 239 as max refresh rate - I did try 1920x1080, 120 in my testing related to 3 and 3a and it didn't work, so it's not just a "you put in an impossible refresh rate".

This one should work however. It would worth to look into the debug log.

I did use "1920x1080, 120" and ""1920x1080, 100" just as a random test, point is I tried this to avoid a potential "you have 239, not 240 you dummy" trap when I tried "1920x1080, 240" - but all of this was before enabling Enumerate refresh rate, so that's why it didn't work.

I see that with Enumerate refresh rate has 2 quirks:
1. The resolution you enter is persistent in input box, but doesn't get written in the list.
2. I just tried Fullscren with "1920x1080, 180" which is under 240Hz of my display so it's capable of that, however it falls down to 144Hz, as this is an enumerated setting while 180 isn't, so I dunno if it's simply my display/GPU/driver being uncooperative or dgVoodoo being a bit peculiar.

Dege wrote on 2026-10-23, 17:28:

I don't know how G-sync affects this all. Did you tried it without that? And are you using some overlay sw to have the actual frame rate displayed?
You can also try GeneralExt\FPSLimit to get dgVoodoo to limit the FPS on its own instead of delegating it to the DX runtime/video driver.

G-sync (in any windowed form) isn't enabled in DX11 due to it apparently using older Present modes, aside from also G-sync for windowed apps also being a bit of a hack (and it needs to be enabled in GPU driver, which it is in my case). DX12 should automatically use newer Present modes.
This is according to vlad54rus that wrote about it in this thread.

I used GeneralExt FPS limit anyway at 120, dunno if everything is 1:1 compared to running the game at 60FPS, but I finished it and had no problems.
Had to use it, at 240FPS the game is like 3x sped up.

My OSD is MSI Afterburner (RTSS), tho I didn't disable NVidia's overlay.

Could you also address the part where game sometimes starts in an invisible window, I wrote about it too.
Worst thing is that it's hard to replicate, and it seems it toggles when you play with dgVoodoo a bit, ala changing resolutions, Fullscreen vs Fake and so on, but when it happens it happens exactly as I wrote it - an invisible (perhaps it's outside of screen, or 1x1 pixel sized) window with music and you have to press Space ASAP otherwise it will crash.

2mg wrote on 2026-10-24, 00:55:

But if it's DirectX, why is it software rendered?
I mean sure, you need an API to display things but is that all that DX means to this game?

BTW this game has a DOS only version, and a Windows version (where Glide is also included), sounds just a bit strange for a 1997/1998 Windows game to just use a software renderer in DX mode, well at least above 640x480 that is, by that time I'd expect software rendering to already be either an option or a fallback, not the default nor the only kind of renderer...

Early games like this had a sw renderer because 3D accelerators weren't that widespread at that time. But a sw renderer could typically render with plain point sampled texture filtering because bilinear was too expensive for the contemporary hw.
So, later(?) they added a 3D accelerated version to have true bilinear filtering, and they chosed Glide because that was the best 3D API.
D3D wasn't too great, it was hard to code against and it had a lot of limitations because that was not a hw-specific library like almost all of the others.
And yes, DDraw was the handy API to do true fullscreen with a given resolution.

2mg wrote on 2026-10-24, 00:55:

OTOH why isn't dgVoodoo capable of changing resolutions of software rendered games?
This game even has multiple resolutions with software renderer, and software rendering afaik is also 3D rendering, no?

Because the frame is completely rendered by the game code, dgvoodoo only gets a finished picture to be displayed on the screen. Even modern upscale algorithms cannot do "perfect" upscaling to a single image.
Btw, I only get 640x480 and 800x600 offered for sw rendering in the setup.

2mg wrote on 2026-10-24, 00:55:

I'll take a peek when I have some time.
That's in dgVoodoo v2.87.5 (spec release with Debug Layer) download?

Yes.

2mg wrote on 2026-10-24, 00:55:

PS: what's the tldr version of dgVoodoo WinMM OS uptime fixer?

It hooks some API calls and reports "low" elapsed time values as if your computer was booted a short time ago.

2mg wrote on 2026-10-24, 00:55:

Sure, but many fixers/wrappers/patches that offer widescreen resolutions often have adjusted/adjustable FoV (sometimes games themselves have it via their config), that's why it crossed my mind that maybe it's stretched due to lower res 4:3 FoV changed (wrongly) in relation to a 16:9 higher resolution, as that is sometimes the case, not related to dgVoodoo directly.
AFAIK that's the worst case, middle case is that FoV stays the same but view extends, and best case is if FoV is adjusted/adjustable, but again, it was just speculation and not really dgVoodoo related, but for game itself.

Yes, it can be done in game specific patches. The FOV is a rendering parameter to the game engine into which dgVoodoo cannot see and intervene.
The game engine does its internal calculations with a given FOV and dgVoodoo just see either the finished transformed vertices or the matrices needed to achieve the transformation with a given FOV.
So, it could extend the FOV but the game engine can do visibility testing for polygons internally and it can decide to sort out ones that are out of the FOV. Or, it can downright clip the polygon set to the camera frustum defined by the FOV.
Extended FOV areas (on dgVoodoo side) would be either completely empty or partially rendered. Those were the results when I experimented with it last time.

2mg wrote on 2026-10-24, 00:55:

1. Seems only enumerated (or custom res + Enumerate) resolutions will ignore 60Hz request in Exclusive Fullscreen AND Fullscreen Fake?

Yes, "enumerate refresh rates" is needed to override app refresh rate.

2mg wrote on 2026-10-24, 00:55:

2. Still doesn't explain why Fullscreen Fake changes the refresh rate, it's a window, I dunno how a windowed app can do that?

As I mentioned, Fake changes display modes (resolution + ref rate) just like Real fullscreen. Even if the resolution stays the same, the refresh rate can be changed. And then fullscreen sized window is stretched over the screen.

2mg wrote on 2026-10-24, 00:55:

I see that with Enumerate refresh rate has 2 quirks:
1. The resolution you enter is persistent in input box, but doesn't get written in the list.

That's the expected behavior. The list only contains what is reported as supported natively by the driver.

2mg wrote on 2026-10-24, 00:55:

2. I just tried Fullscren with "1920x1080, 180" which is under 240Hz of my display so it's capable of that, however it falls down to 144Hz, as this is an enumerated setting while 180 isn't, so I dunno if it's simply my display/GPU/driver being uncooperative or dgVoodoo being a bit peculiar.

Well, that part is foggy a bit even for me. The DXGI runtime that handles the requested fullscreen modes (resolution + refresh rate) should accept any refresh rate, even ones that are not supported natively.
It accepts as expected but the v-synced output does not always align to the refresh rate (but to some natively supported value that is closest to that refresh rate).
So, if I force for example 12Hz then I'd expect that the output is done at 12 FPS. It looks to work for some people and doesn't for others (they get 50/60 Hz or so).
I don't know why it is, maybe the implementation for custom values are implemented in the driver (not the MS runtime) and it either works with a driver or not. 😖 It might be the reason for you to get only refresh rates aligned to natively supported values.
Since defining custom refresh rate values proved to be unreliable, later I implemented the FPS limiter on dgVoodoo side .

2mg wrote on 2026-10-24, 00:55:

G-sync (in any windowed form) isn't enabled in DX11 due to it apparently using older Present modes, aside from also G-sync for windowed apps also being a bit of a hack (and it needs to be enabled in GPU driver, which it is in my case). DX12 should automatically use newer Present modes.
This is according to vlad54rus that wrote about it in this thread.

You can use modern Flip-type presention modes with DX11 too, you just have to set in dgV config.
DX11 defaults to the legacy blt-type because that is the only one supported on Win7 and it enables true gamma ramping (however I'm not sure if still that is the case on latest OS versions).

2mg wrote on 2026-10-24, 00:55:

Could you also address the part where game sometimes starts in an invisible window, I wrote about it too.
Worst thing is that it's hard to replicate, and it seems it toggles when you play with dgVoodoo a bit, ala changing resolutions, Fullscreen vs Fake and so on, but when it happens it happens exactly as I wrote it - an invisible (perhaps it's outside of screen, or 1x1 pixel sized) window with music and you have to press Space ASAP otherwise it will crash.

I improved handling the window size in the current version, I'm going to release a new patch version soon. I'm not sure if it solves this problem, but the game is working fine for me with it.

Dege wrote on Yesterday, 14:53:

It hooks some API calls and reports "low" elapsed time values as if your computer was booted a short time ago.

What's the use case?

Dege wrote on Yesterday, 14:53:

...
Extended FOV areas (on dgVoodoo side) would be either completely empty or partially rendered. Those were the results when I experimented with it last time.

Similar to how widescreen patches for ie a lot of PS1 games have literary empty stuff outside 4:3.
Cool that you experimented with FoV tho.

Tho if I can force some games to actually render at 16:9, as in they really can do it (or there's a widescreen patch for a given but dgVoodoo is still needed as a wrapper) maybe add that FoV setting as an extremely experimental option?

Dege wrote on Yesterday, 14:53:

As I mentioned, Fake changes display modes (resolution + ref rate) just like Real fullscreen. Even if the resolution stays the same, the refresh rate can be changed. And then fullscreen sized window is stretched over the screen.

Interesting, I do not recall resolution switching with Glide version, only Hz, and I did try stock resolution/Unrestricted and 800x600...
Tho maybe that didn't properly stick because this was also before I knew about Enumerate resolutions.

If it's not too technical, question still is how can a window (which Fullscreen Fake is) change either of those, I'm a bit out of date on that, but I thought that was reserved only for True Fullscreen (aka pre-DX12, maybe including DX12) or newer Borderless Fullscreen (which is DX12 "special" Fullscreen mode now)?

Dege wrote on Yesterday, 14:53:

That's the expected behavior. The list only contains what is reported as supported natively by the driver. […]
Show full quote

2mg wrote on 2026-10-24, 00:55:

I see that with Enumerate refresh rate has 2 quirks:
1. The resolution you enter is persistent in input box, but doesn't get written in the list.

That's the expected behavior. The list only contains what is reported as supported natively by the driver.

2mg wrote on 2026-10-24, 00:55:

2. I just tried Fullscren with "1920x1080, 180" which is under 240Hz of my display so it's capable of that, however it falls down to 144Hz, as this is an enumerated setting while 180 isn't, so I dunno if it's simply my display/GPU/driver being uncooperative or dgVoodoo being a bit peculiar.

Well, that part is foggy a bit even for me. The DXGI runtime that handles the requested fullscreen modes (resolution + refresh rate) should accept any refresh rate, even ones that are not supported natively.
It accepts as expected but the v-synced output does not always align to the refresh rate (but to some natively supported value that is closest to that refresh rate).
So, if I force for example 12Hz then I'd expect that the output is done at 12 FPS. It looks to work for some people and doesn't for others (they get 50/60 Hz or so).
I don't know why it is, maybe the implementation for custom values are implemented in the driver (not the MS runtime) and it either works with a driver or not. 😖 It might be the reason for you to get only refresh rates aligned to natively supported values.
Since defining custom refresh rate values proved to be unreliable, later I implemented the FPS limiter on dgVoodoo side .

Yeah, if you add that people use VRR, with (pun intended) variable quality of not only monitors but VRRs in those monitors (aka budget Freesync vs expensive monitor with G-Sync module), overlays/OSDs (that can also inject random stuff), ReShade, random GPU stuff like ReBar or GPU scheduling or Reflex/Antilag/Low Latency Mode, XBOX/Game mode on/off, possibly Display Stream Compression, whichever driver they have installed at that moment, the fact that for some reason my monitor is connected via DP and it still splits some resolutions as TV and some as PC driver behavior, misalignment with game FPS and screen Hz, and that you're wrapping around ancient stuff, foggy is actually good, it could be worse, it could be... black magic voodoo 😉

I could try to either make a custom 1920p180Hz or use CRU for that, but that's not important, as it's known (mis)behavior to you, so anyone that wants something like that can try to do what I wrote and then try using it in dgVoodoo.
This info could fit in a popup somewhere tho.

Dege wrote on Yesterday, 14:53:

I improved handling the window size in the current version, I'm going to release a new patch version soon. I'm not sure if it solves this problem, but the game is working fine for me with it.

Have you ever experienced it with Montezuma, or another game, and why does it happen with Glide only with Montezuma?

Regarding software render, could you perhaps detect this and alert the user/have a (toggleable) sticker, so that we don't waste time trying to get higher resolutions?

PS: props for answering my stuff.