[D3D9 (via D3D8)] Request scaling for DX8/Dx9 games.

[RustyShacklefordIII]

First of, I want to thank you for the dxwrapper. It's really an amazing tool that finally lets me have fullscreen shell menus in the game Star Trek Armada Fleet Operations ( https://www.fleetops.net/download ). I'm also loving the improved anti-aliasing and framerate control that dxwrapper brings. This game originally was a DX8 game, but using dxwrapper with its d3d9.dll library and the settings:

D3d8to9 = 1
FullscreenWindowMode = 1

I can get the shell menus that normally come in a 800x600 window in the middle of the desktop to show as fullscreen (with some black bars).

I did run into the issue of very lengthy mode changes when launching in fullscreen using dxwrapper. It takes about 5 seconds when launching into fullscreen before I get to see the main menu, and during those 5 seconds the screen is entirely black, then when I launch a game (which has a different resolution than the shell menus) the same thing happens, also every time I go from a game into the escape menu, and back. I'm assuming this has something to do with refresh rates, but I'm not sure, when I change resolutions in Windows display settings the change is instantaneous and without a black screen, so I know it's not strictly necessary to have any delay or black screens.

However, if I force scaling (aspect ratio or integer) on the GPU in the Nvidia control panel the mode changes only take about 1 second (there is a very short flicker where you see the taskbar appear and disappear, but I'll take that over 5 seconds of black screen and missing the loading screen when launching a game). The Magpie tool ( https://github.com/Blinue/Magpie ) can also scale the game with very quick mode changes, although it needs to be actively told to scale every time a new menu page is opened (for example when going from the main menu to the options menu).

I was hoping you could add scaling (aspect ratio would be best, but integer scaling is already better than nothing, especially if we get to choose the integer, and if we can also choose half integers) for DX9 games. I'd rather have it be done by dxwrapper than by the Nvidia control panel, also because Nvidia messes up the color saturation (Magpie doesn't).

I'm able to compile dxwrapper and now sort of know where to make changes to fullscreen settings but I'm in over my head when it comes to scaling modes.

P.S. Magpie is open source with the code available on github for inspiration, I think it uses a change of the viewport size to achieve the scaling.

[RustyShacklefordIII]

I dug into Magpie some more. It seems to use DX11 code for the resizing, no idea if that's what makes it so fast (it's very fast, even faster than Nvidia's scaling, but has to activated by hand every time I click through a shell menu).

[elishacloud]

This game originally was a DX8 game, but using dxwrapper with its d3d9.dll library and the settings:

You should be using the d3d8.dll stub along with dxwrapper.dll and dxwrapper.ini.

I was hoping you could add scaling (aspect ratio would be best, but integer scaling is already better than nothing, especially if we get to choose the integer, and if we can also choose half integers) for DX9 games.

Scaling the window using DX9 is possible. However, I don't plan to do that soon, because DX9 is 3D it can take more effort to scale. I suggest looking for a d3d9.dll file that can scale DX9 games.

It seems to use DX11 code for the resizing, no idea if that's what makes it so fast (it's very fast, even faster than Nvidia's scaling, but has to activated by hand every time I click through a shell menu).

I suspect that Magpie is scaling the window rather than switching resolutions. I suspect that your monitor has slow resolution switching. FullscreenWindowMode switches monitor resolution. If that is slow for your monitor then there is not much I can do. Switching for me when using FullscreenWindowMode on my laptop is under a second.

Try disabling FullscreenWindowMode and just setting EnableWindowMode and see how long it takes. The only difference between EnableWindowMode and FullscreenWindowMode is resolution switching. If EnableWindowMode is fast and FullscreenWindowMode is slow than I suspect the issue is that your device has slow resolution switching.

[RustyShacklefordIII]

This game originally was a DX8 game, but using dxwrapper with its d3d9.dll library and the settings:

You should be using the d3d8.dll stub along with dxwrapper.dll and dxwrapper.ini.

I am, that's how I got the AA and FullscreenWindowMode to work in the first place.

I was hoping you could add scaling (aspect ratio would be best, but integer scaling is already better than nothing, especially if we get to choose the integer, and if we can also choose half integers) for DX9 games.

Scaling the window using DX9 is possible. However, I don't plan to do that soon, because DX9 is 3D it can take more effort to scale. I suggest looking for a d3d9.dll file that can scale DX9 games.

Oh, I don't really need 3D scaling, just the shell menus, which are all 2D. I was going to try adding it myself but I know next to nothing about directx. I think the scaling has to do with changing the viewport size, but doing that at the one place (where according to the dxwrapper log) the shell menus go through a viewport change didn't do anything for the menus (it did cutout a large portion of the screen while inside the actual 3D game though).

It seems to use DX11 code for the resizing, no idea if that's what makes it so fast (it's very fast, even faster than Nvidia's scaling, but has to activated by hand every time I click through a shell menu).

I suspect that Magpie is scaling the window rather than switching resolutions. I suspect that your monitor has slow resolution switching. FullscreenWindowMode switches monitor resolution. If that is slow for your monitor then there is not much I can do. Switching for me when using FullscreenWindowMode on my laptop is under a second.

Yes, it's scaling the window rather than changing the resolution.

Try disabling FullscreenWindowMode and just setting EnableWindowMode and see how long it takes. The only difference between EnableWindowMode and FullscreenWindowMode is resolution switching. If EnableWindowMode is fast and FullscreenWindowMode is slow than I suspect the issue is that your device has slow resolution switching.

It's indeed much faster without the resolution switching, but on my system Windows can change desktop resolutions almost instantaneously in the Windows 10 Display settings (control panel).

[RustyShacklefordIII]

I suggest looking for a d3d9.dll file that can scale DX9 games.

Thanks, do you know one that can do that?

[elishacloud]

Oh, I don't really need 3D scaling, just the shell menus, which are all 2D.

d3d9 doesn't have 2D. Everything is in 3D, even things that look 2D are actually rendered in 3D.

I think the scaling has to do with changing the viewport size

Changing the viewport is part of it. Other things may be affected by this also. I may add scaling later, but I have so many things on my list before that.

It's indeed much faster without the resolution scaling, but on my system Windows can change desktop resolutions almost instantaneously in the Windows 10 Display settings (control panel).

I am not sure about Windows. But the difference between these two modes is only one line of code where the resolution is changed.

You could try using EnableWindowMode and FullScreen. The latter will stretch the window to fill the screen. Or you could try EnableWindowMode plus Magpie.

[elishacloud]

I suggest looking for a d3d9.dll file that can scale DX9 games.

Thanks, do you know one that can do that?

I just did a quick search and found this: https://github.com/Dwedit/GameStretcher

[RustyShacklefordIII]

Changing the viewport is part of it. Other things may be affected by this also. I may add scaling later, but I have so many things on my list before that.

Of course, just hoping to see that in dxwrapper one day.

You could try using EnableWindowMode and FullScreen. The latter will stretch the window to fill the screen.

That's just as slow and comes with some artifacts/bugs that simply setting FullscreenWindowMode = 1 doesn't have.

Or you could try EnableWindowMode plus Magpie.

This "works", except Magpie is a manual app that "forgets" the scaling every time a new window is opened (which the shell menus do), I also don't think it can be automated to run whenever the game starts, so I can't include it into a mod package for other players.

I just did a quick search and found this: https://github.com/Dwedit/GameStretcher

That one crashes with Fleet Operations, but at least it's open source, so maybe there's something useful in the code.

[elishacloud]

Try this update with FullscreenWindowMode option. I just changed it to stretch the window to fit the screen rather than switching the resolution.

dxwrapper.zip

[RustyShacklefordIII]

Try this update with FullscreenWindowMode option. I just changed it to stretch the window to fit the screen rather than switching the resolution.

dxwrapper.zip

Thanks. It does rapidly stretch the window, but since the menus are glued to the upper left corner and don't resize I get this (this is a peculiarity of the game engine that I also got when I hex-edited the game's engine to be as large as the screen resolution)

[elishacloud]

It does rapidly stretch the window, but since the menus are glued to the upper left corner and don't resize

I suspect that the issue is because this screen is GDI and not d3d9. That's why it doesn't stretch and why it stays black for 5 seconds. GDI is cleared (meaning the window turns black) when the resolution changes and it doesn't get drawn again for 5 seconds.

I added some code to tell the window to redraw. Try this one: dxwrapper.zip

[RustyShacklefordIII]

It does rapidly stretch the window, but since the menus are glued to the upper left corner and don't resize

I suspect that the issue is because this screen is GDI and not d3d9. That's why it doesn't stretch and why it stays black for 5 seconds. GDI is cleared (meaning the window turns black) when the resolution changes and it don't get drawn again for 5 seconds.

I added some code to tell the window to redraw. Try this one: dxwrapper.zip

Hmmm, that has the same delay as before. As far as I know the game does use DX8 to create windows, but it also uses Delphi code to create "forms" that are stuck to the upper left corner of those windows: https://docwiki.embarcadero.com/Libraries/Sydney//en/Vcl.Graphics

I've disassembled the engine hook that turns Armada 2 into Fleet Operations and it seems to use both those Delphi forms and DX8, though I'm no expert.

It's a shitty design by the original devs if you ask me, and just getting the shell menus to appear in the center of the screen, surrounded by black bars and unscaled, would already be a welcome breakthrough, so I would definitely understand it if you don't put too much time into this, but thank you again for looking into it.

[elishacloud]

As far as I know the game does use DX8 to create windows

The game is d3d8. But it still may use GDI for some screens. That is quite common on DX8 and older games. Can you enable the ShowFPSCounter and see if it is working correctly on this screen? If the counter is working correctly then the screen is d3d8. Otherwise it is likely GDI.

[RustyShacklefordIII]

As far as I know the game does use DX8 to create windows

The game is d3d8. But it still may use GDI for some screens. That is quite common on DX8 and older games. Can you enable the ShowFPSCounter and see if it is working correctly on this screen? If the counter is working correctly then the screen is d3d8. Otherwise it is likely GDI.

The FPS counter flashes very briefly in the main menu and then goes away, it never appears, not even flashing, in other menus. Here are the relevant .idb (disassembly) files for the game engine: https://limewire.com/?referrer=pq7i8xx7p2

Is there some way to quickly recognize function names from GDI in the engine, or maybe in the names of elements within resources within the game engine?

[elishacloud]

The FPS counter flashes very briefly in the main menu and then goes away, it never appears, not even flashing, in other menus.

Ok, that shows that the screens are GDI. It also makes sense that this is why the screen turns black for 5 seconds.

Is there some way to quickly recognize function names from GDI in the engine, or maybe in the names of elements within resources within the game engine?

There are a lot of GDI functions. From ChatGPT:

Common GDI Functions (Win32 API)
Device Context (DC) management

GetDC() — retrieves a device context for a window or the entire screen.
ReleaseDC() — releases a device context.
CreateCompatibleDC() — creates a memory DC compatible with a specified DC.
DeleteDC() — deletes a device context.
CreateCompatibleBitmap() — creates a bitmap compatible with a DC.
SelectObject() — selects a GDI object (like a pen, brush, or bitmap) into a DC.

Drawing & Copying

BitBlt() — copies a block of pixels from one DC to another (the classic 2D blitter).
StretchBlt() — like BitBlt, but allows scaling the source rectangle.
PatBlt() — performs a pattern blit using the currently selected brush.
FillRect() — fills a rectangle with a solid color brush.
Rectangle() — draws a rectangle (outline + optional fill).
Ellipse() — draws an ellipse.
LineTo() — draws a line from the current point to a specified point.
MoveToEx() — sets the current drawing position.

Text

TextOut() — draws text at a specified position.
DrawText() — draws text with formatting options (word wrap, alignment, etc.).
SetTextColor() — sets the text color in a DC.
SetBkColor() — sets the background color for text output.
SetBkMode() — sets the background mode (opaque/transparent).

Pens, Brushes, Fonts

CreatePen() — creates a pen for line drawing.
CreateSolidBrush() — creates a solid color brush.
DeleteObject() — deletes a GDI object (pens, brushes, bitmaps, etc.).
CreateFont() / CreateFontIndirect() — creates a logical font.

Bitmaps

CreateBitmap() — creates a bitmap with specified dimensions and pixel data.
LoadBitmap() — loads a bitmap resource from a module.
GetDIBits() — retrieves the bits of a bitmap.
SetDIBits() — sets the bits of a bitmap.

Clipping

SelectClipRgn() — selects a clipping region.
ExcludeClipRect() — excludes a rectangle from the clipping region.
IntersectClipRect() — intersects the current clipping region with a rectangle.

Palette (for 8-bit/Indexed color modes)

CreatePalette() — creates a logical color palette.
SelectPalette() — selects a palette into a DC.
RealizePalette() — maps palette entries to system palette.

[RustyShacklefordIII]

Oh right, I see references to CreateCompatibleDC in the engine newer part of the engine code, also StretchBlt, and some others, so yeah, apparently it's GDI, at least for some of the menus (like the main menu), though the older part of the engine has no references to these (the menu that actually launches a game is directx, from the old part of the engine, but it's hooked into by the newer part of the engine, not sure what that does when it comes to resolution switching).