Closed Nightshades1 closed 8 years ago
While there's no reason why not in principle, being realistic these will never be supported.
Take DX9 as an example - this is still actively used in many shipping games and programs today, but it still falls far behind many other higher priority tasks. When it comes to the point where it might be feasible to work on it, it will be less common and less relevant so it may not happen either. For GL2 and DX6/7, this point will probably never arrive and those APIs are old enough that doing some of the basic tasks needed for RenderDoc's features will be difficult and perhaps need proxying to a different API.
GL2 has a slight chance since although few people will still be using it, more people are using GLES2 & WebGL which are comparable. Plus because of the backward/forward compatibility it could be replayed on a GL4 context. The effort vs. value tradeoff still doesn't look good though, so I wouldn't hold my breath.
One side note - I think I probably do support all of GL 3.x. As in I don't think any features added in 3.0 and 3.1 were then deprecated in 3.2, and RenderDoc supports everything in core profile GL which is 3.2+.
How much work would it involve to just add some stubs for these APIs and ask people to fill it out? Last time I offered help with adding a new API you told me that it's too much work but I see people making progress on adding better support for DX12 after the basics are already there. Maybe as a start adding a DX9 stub would be easy and I can definitely help improving it.
For DX9 it'd be feasible for someone to start adding support, for the other APIs I'm not sure I'd actually want that as there's still a maintenance burden from having them in the codebase even if I'm not working on them directly - especially considering how few people would actually use it.
The trouble with adding stubs is it's not clear where to stop. To properly stub it all out, you'd need to wrap all the interfaces (as a number of functions go via the texture/buffer interfaces like LockRect), but that means then having proper wrapping/unwrapping, etc. Doing only a stub of the main interface isn't much work but also isn't much help either, I think it's probably easier for someone working on it to just begin work themselves.
If someone wants to add DX9 support, what I'd recommend is first doing a 'proof of concept' by adding just enough to hook the device, wrap some basic interfaces, and create their own shader & texture to display the RenderDoc overlay during Present() saying "D3D9. Capture not yet supported. FPS / frametime". That would be useful in practical terms, and then it could be expanded from there and serialisation added etc.
While I agree that DX6/7 is probably barely used as far as I understand it was all done through the DirectDraw API back in the days. This API is still used by some games even today (not many). And as more and more people start picking up RenderDoc the need to be able to use it as a debugger of rendering scenarios where you don't have access to the sources (maybe because the game is 20 years old) is becoming more and more valid. I think the proper way of handling this would be someone who is passionate about those APIs forking RenderDoc on GitHub, adding the support and maintaining it. I can certainly do this with DX9 if you would prefer.
I will send an email about more details on DX9.
Hello would be awesome to add those to the compatibility list:
OpenGL 2. OpenGL 3.
D3D (DX6) D3D (DX7)
Most Likely to be useable on windows game / psx emulator. Thanks for your hardwork on this good software, i also asked Nvidia if they could plan a way to attach on any game their software, Nvidia Nsight is awesome but sadly doesn't work well/crash on game you want to debug (you know, the game you don't have the source =P).