elishacloud
Possible bug with full screen mode
Hi Elishacloud, So while I was playing around with Star Trek Bridge Commander with Rtx Remix trying to get 1080p to work. I started changing fullscreen vs window settings in dxwrapper.ini that's when I noticed there was a noticeable difference in vram usage that using Window/full screen window mode was using less vram versus regular fullscreen. So when STBC starts it plays through some intro videos that drop down to 480p resolution before hitting main menu and if I'm reading the log correctly it's not closing the thread-safe D3D9 device properly in full screen mode at least according to bridge32.log.
I don't think this is an issue with dxwrapper. dxwrapper just changes some settings to tell DX to use windowed mode. I think the "issue" is a byproduct of how Windows works. When playing fullscreen exclusive mode the game has full (i.e. exclusive) access to the GPU.
However, when playing windowed mode (fullscreen or not) the game shares the GPU with other applications that are running, like the Windows desktop. It isn't surprising that more video memory is being used when the GPU is being shared by multiple apps vs when the game has exclusive access to the GPU.
BTW: this is also why we call it exclusive mode vs windowed mode.
It's doing the reverse, exclusive fullscreen mode is using more vram compared to window mode.
I don't think this is an issue with dxwrapper. Like I said the only difference is the settings given to Direct3D9. Any extra memory would be done by Direct3D9 or Windows.
dxwrapper will create additional surfaces when in windowed mode. But that is only when the game is in windowed mode. If windowed mode is set by dxwrapper but the game is still set for exclusive fullscreen then those extra surfaces aren't created.
I found some places where dxwrapper was using more memory than it should. But I don't think there is any bugs here.
This is the latest build. It should use a little bit less memory: dxwrapper.zip
Closing as I don't think this is dxwrapper's issue.
It's probably on remix side but I did notice higher vram usage with a recent build, All tests done with 7to9 enabled and everything else default.
dxwrapper-stbc.log 1.4.8019.25 4334 MiB usage dxwrapper-stbc.log 1.4.8019.25 4334MiB usage.log
dxwrapper-stbc v1.4.7999.25 3694 7to9 enabled ~3694MiB Usage dxwrapper-stbc v1.4.7999.25 3694MiB.log
dxwrapper-stbc.log 1.4.7900.25 3694 MiB usage dxwrapper-stbc.log 1.4.7900.25 3694.log
dxwrapper 1.1.6972 3645MiB usage dxwrapper-stbc.log 1.1.6972 3645MiB usage.log
I know why it is using more memory in windowed mode.
- In windowed mode the back buffer for d3d9 and for DirectDraw must be the size of the full screen. Whereas in fullscreen mode the back buffer only needs to be the size of the window. If you have a 4K monitor (for example) and the game only displays in 1024x768 then the memory usage could be quite a bit more in windowed mode. There is nothing I can do about this since in windowed mode the game window could appear anywhere on screen so the buffer needs to be big enough to handle that because the game could write to the surface anywhere on screen.
- With dxwrapper I also use an extra shadow surface when then game is displaying to a window so that I can always make the display fit in the upper left-hand corner of the d3d9 buffer. This makes it so that the game data is NOT moving around on the d3d9 surface while it is moving around on the ddraw surface (when the window is moved). Again, this is required for translation.
This extra memory in windowed mode is normal and expected I don't know of anyway to change it. I guess even native DirectDraw uses more memory in windowed mode than in fullscreen mode. However, dxwrapper may use more because of the extra shadow surface and the fact that it uses back buffers both in ddraw and in d3d9.