Migrate to DX9

[JohnsterID]

Following on from w3dhub/OpenW3D#17, draft attempt at JohnsterID#1

Phase 1: DX8 → DX9 (Windows-only modernization)
├── Update WW3D2 core (dx8wrapper → dx9wrapper)
├── Update all tools (W3DView, WorldBuilder, etc.)
├── Update main games (Generals, Zero Hour)
└── Validate everything works

Phase 2: DX9 → Abstraction Layer
├── Create RenderDevice interface
├── Implement DX9RenderDevice
├── Refactor WW3D to use abstraction
└── Test with DX9 backend

Phase 3: Add Cross-Platform Backends
├── Implement OpenGLRenderDevice
├── Implement VulkanRenderDevice (optional)
├── Add platform-specific windowing
└── Cross-platform builds

[xezon]

My main ask here is to not break DirectX 8 while upgrading to Direct X 9. Have them selectable by compile option, or later, command line argument.

[Mauller]

There's also the need to first unify the directx 8 code between generals and zero hour, i think someone started it then stopped so far through.

I might take a look at finishing that off.

The directx9 codebase also wants to be parallel to the directx8 codebase as this can then allow switching between the two using an API Abstraction layer at a later date.

[JohnsterID]

Ok, I added an attempt at compile-time option.

[HossamAbubakr]

What benefits would the migration bring?

[githubawn]

DX9.0c:
Being able to select gpu.
Post processing shaders, such as CAS.
No need to manage an extra dll like d3d8to9.dll.
Simpler code for effects like heat haze.
Faster on wine.

dx9ex:
Gpu managed frametime/framerate.
More stable alt tab.
Better Vsync in windowed mode.

[fbraz3]

In my fork i've implemented the code to choose graphic engine by cmdline parameter.

I think this deepwiki can help to implement the same feature into supehackers repo.
https://deepwiki.com/search/the-windows-version-have-some_1ec57cc3-019a-4233-b258-710d1ac5dd05

[bobtista]

Revisiting this - RE making a dx8/dx9 compile toggle, I'm concerned that it's a ton of extra work that will ideally be thrown away soon, and our velocity isn't great, so the extra work could dramatically balloon the time to get it shipped. What are the benefits of supporting the toggle vs just reverting to before a migration if needed?

Regardless of the toggle, I agree that more unification work would be beneficial here, and I'm happy to focus more on both unification and dx9 related tasks. What is everyone else thinking is our best path forward here?

[stephanmeesters]

I put a bit of time in DX9 migration this week, didn’t quite finish it, see here for reference.

Perhaps temporary glue code would not be so bad, for as far as I’ve seen the interface changes are manageable.

The biggest change is perhaps moving the shader object management from DWORD to IDirect3DPixelShader9, IDirect3DVertexShader9, IDirect3DVertexDeclaration9.

The glue code could be something like below. When dx9 is migrated and verified the macros would be removed.

#ifdef DX9

#define IDirect3DTexture IDirect3DTexture9
#define IDirect3DVertexBuffer IDirect3DVertexBuffer9
…

#else

#define IDirect3DTexture IDirect3DTexture8
#define IDirect3DVertexBuffer IDirect3DVertexBuffer8
…

#endif

#ifdef DX9

#define SET_STREAM_SOURCE(device, stream, vb, offset, stride) \
        (device)->SetStreamSource((stream), (vb), (stride))

#else

#define SET_STREAM_SOURCE(device, stream, vb, offset, stride) \
        (device)->SetStreamSource((stream), (vb), (offset), (stride))

#endif

#ifdef DX9

struct PixelShader
{
    IDirect3DPixelShader9* shader = nullptr;

    void Apply(IDirect3DDevice9* device) const
    {
        device->SetPixelShader(shader);
    }

    void Release()
    {
        if (shader) {
            shader->Release();
            shader = nullptr;
        }
    }
};

struct VertexShader
{
    IDirect3DVertexShader9* shader = nullptr;
    IDirect3DVertexDeclaration9* decl = nullptr;

    void Apply(IDirect3DDevice9* device) const
    {
        device->SetVertexShader(shader);
        device->SetVertexDeclaration(decl);
    }

    void Release()
    {
        if (shader) {
            shader->Release();
            shader = nullptr;
        }
        if (decl) {
            decl->Release();
            decl = nullptr;
        }
    }
};

#else

struct PixelShader
{
    DWORD shader = 0;

    void Apply(IDirect3DDevice8* device) const
    {
        device->SetPixelShader(shader);
    }

    void Release()
    {
        shader = 0;
    }
};

struct VertexShader
{
    DWORD shader = 0;

    void Apply(IDirect3DDevice8* device) const
    {
        device->SetVertexShader(shader);
    }

    void Release()
    {
        shader = 0;
    }
};

#endif

[githubawn]

Thanks for the SDL3 suggestion. Since DX8 and DX9 both use the same DInput, it's outside the scope of Phase 1. Better to keep the renderer dialect migration isolated.

[drweb86]

Im very far from C++. i just saw some topics here about porting to linux, so SDL proposal (or basically to other cross platform thing) is to reduce scope of DirectX staff in general in project. Less Direct X code - less migrational efforts. But im again very far from that field.

[githubawn]

I've done part of the migration myself as exploratory research to establish the actual scope (this wasn't an implementation attempt, but a way to find out what we're dealing with before committing to an approach). I think it changes the risk calculus a bit, and I'm writing this to better understand the concern and to keep both the review burden and the ifdef churn manageable.

It came out to roughly 7900 lines of API substitution and about 100 lines of real logic changes. Five extremely small shaders need fixing, and ronin has already fixed one or two driver regression issues on his side. It's almost entirely mechanical. We can split this up into separate commits in the pull, one for the mechanical changes, one for the logic changes that do need review.
This would also open the door to things like dual-GPU selection that DX8 simply can't support. It's also worth noting that the rendering cleanup is actually easier to do once we're on DX9.

Given that, would a toggle still feel necessary for Phase 1? My concern is that DX8 and DX9 are close enough in API surface that maintaining them as parallel paths would cost more long-term than the migration itself risks.
A toggle absolutely makes sense when the gap is architectural, Phase 2 will need one, and bgfx looks like the right tool for that abstraction layer. But I'm not sure DX8 to DX9 clears that bar for Phase 1.

What if we treated current master (DX8) as the reference benchmark and kept the upgrade on a dedicated branch until the DX9 branch matches 1:1 in visual output and performance? That way DX8 stays untouched as ground truth throughout, and we only merge once parity is confirmed. Would that address the stability concerns without needing a toggle?

On GenTool, with 23 PRs already merged to integrate it, is the concern that a DX9 migration specifically breaks it, or is that only a Phase 2+ problem once we introduce an abstraction layer? The VC6 incompatibility with bgfx is a real constraint, but that feels like a Phase 2 decision rather than something Phase 1 needs to resolve.

Happy to hear your reasoning.

[xezon]

GenTool only works with DX8.

I suspect what makes the upgrade from DX8 to DX9 a bit annoying is the very lax DX8Wrapper, which still allows anyone to access raw DX8 structures. I expect a DX9Wrapper will be much easier to add when EVERYTHING goes behind DX8Wrapper. No exceptions.

For example:

	IDirect3DTexture8* d3d_texture = DX8Wrapper::_Create_DX8_Texture
	(
		width,
		height,
		dest_format,
		(MipCountType)mips
	);

This is not OK. Texture should be abstracted.

So perhaps what we need to do first, add more and more abstractions around DX8Wrapper so that no native DX8 stuff is spread around the code base.

But before that, we perhaps want to unify more of WW3D2.

[bobtista]

I've been playing with this flow:
Add an interface so we can choose a rendering back end
Default to dx8, so the interface is just passing straight through to dx8 and the game runs as normal
Implement other backends - we could put dx9 here, I've been working on bgfx and am making progress there

If anyone wants to try adding their dx9 as a backend, here's the branch: render-backend-interface

[fbraz3]

Hey there, if you guys are interested, my fork have a full SDL3 + DXVK + OpenAL + FFMPEG implementation working fine. Maybe something there could be useful for this efforts.

https://github.com/fbraz3/GeneralsX