D3D8 Driver

[tgjones]

Would you accept a PR for a D3D8 driver?

I know there's a D3D9 driver stub, but it doesn't do capture, so it would be a bit weird to have a D3D8 driver that's more complete than the D3D9 one. And obviously there's a maintenance cost.

My motivation is that I want to do a graphics study for C&C Generals, in the same style as Adrian Courrèges's awesome frame breakdowns of popular games like GTA V. But C&C Generals is a D3D8 title, which very few frame debuggers support (really just apitrace, but apitrace's UI doesn't give me pretty partially-rendered screenshots that I can put on my blog).

I've already matched the D3D9 driver, so my D3D8 driver can render the overlay as below. I'll probably carry on with the capture code regardless of your answer, but it would be extra motivation if there was the thought that this code could be merged and / or useful to others.

[moradin]

I can't answer the question but would like to chip in just to say how it looks from my side.

I started the D3D9 driver but then, unfortunately, lost a large chunk of my free time to other activities. Since the D3D9 and D3D8 interfaces are exact matches in many cases, it would be great to make progress on either implementation, because this would mean much easier progress for the other. If I will have any more free time in the near future I will certainly return to the D3D9 driver which I very much regret abandoning. As for your concerns, I think it's not a problem to have a D3D8 driver, even if the D3D9 one is not functional yet and you shouldn't worry about this. Especially since all this development would probably happen in a branch.

Obviously, all this is just my opinion and Baldur has the last word on all matters renderdoc related :)

[tgjones]

@moradin thanks for the reply, and your work on the D3D9 driver - it made the initial D3D8 work pretty straightforward.

Let's see what Baldur says.

[baldurk]

This is certainly unexpected :smile:.

At this point I don't get many requests about D3D9 support, although there are still a few people shipping programs on D3D9. D3D8 is only of historical interest I imagine. However I don't mind merging the API support into the codebase in principle.

My main concerns are maintenance like you mention - I don't really want to have a driver that is just left to rot and bugs aren't fixed, but equally I don't have the familiarity or realistically the time/priorities to fix anything. There's also a question of controlling expectations - when new features are added or changes are made, D3D8 is definitely going to get the short end of the stick. Many features will probably be impossible to implement without maybe doing some kind of dual-API path where you share textures with a more capable API like D3D11 and do the work there. In general though, I don't want to give people the expectation that D3D8 is fully supported without being able to back it up.

As long as it is simply merged into the code without being 'public-facing' until it's ready, I think it should be fine.

I guess although D3D8 and D3D9 are similar, all of the versioned COM interfaces make code sharing kind of difficult? If the APIs are close enough and it's feasible then it would be nice to share some code if possible, but if that's more trouble than it's worth doing the gymnastics to merge things then it's not important.

For a procedural thing I'd strongly recommend PR'ing with what you have now already, and then PR'ing at a regular basis after that. Realistically I can't review and merge a whole back-end at once, so if there's a PR that's too big then that might be something I'd reject. Instead if you do it in bite-sized chunks then it's easier to review and fix any issues sooner rather than later. As long as it compiles there's no harm in merging it any time, it doesn't have to work until we decide to publicise it and make it an official backend.

[tgjones]

when new features are added or changes are made, D3D8 is definitely going to get the short end of the stick

That makes complete sense - I wouldn't be surprised or upset if, at some point in the future, there are enough changes or new features that you decide to remove D3D8 support. But if there's at least some version of RenderDoc that supports D3D8, that ought to be enough for people like me who just want to better understand an old game.

As long as it is simply merged into the code without being 'public-facing' until it's ready, I think it should be fine.

Great!

If the APIs are close enough and it's feasible then it would be nice to share some code if possible

In my opinion, it's not worth trying to share code, at least at this stage, because of the versioned COM interfaces you mentioned. Perhaps after the capture code is implemented I can revisit that opinion.

For a procedural thing I'd strongly recommend PR'ing with what you have now already

Will do.

[moradin]

As for code sharing, most of the code would compile if a define would be added for each API object. Now I'm not saying that I like such code but something like this would work:

#if DX9
#define D3DTexture IDirect3DTexture9
#elif DX8
#define D3DTexture IDirect3DTexture8
#else
#error
#endif

The same idea could be implemented with typedefs or templates.

There are certainly objects that are different or functions that exist only in one API but the similarity is really huge.

[baldurk]

Closing this for now as the initial PR is merged, feel free to open new issues if there are specific things that should be discussed.

[Skybladev2]

Where to vote for D3D9 support? My game defaults to DX9 suddenly and I can not force it to work with DX11, so I can't use RenderDoc for it anymore.

[baldurk]

There is no voting. D3D9 support is unlikely to be implemented unless someone else contributes it as it's not high priority for me.

My game defaults to DX9 suddenly and I can not force it to work with DX11

I'm not sure if it's what you mean, but capturing commercial or copyrighted programs that are not your own is not supported or condoned. I provide no support for that. If it's your own project and you have a DX11 backend then it's up to you to use DX11, it's not something I can help with.