1

We're a small-medium size enterprise (~50 devs), working on several DirectX 9 applications. (not games)

DirectX 10 and 11 both were deep interface overhauls, as DX12 will probably be. We didn't upgrade to any of them, and since VS2013 (now migrating) working with DX9 is getting very inconvenient to say the least - while DX9 is not technically deprecated, MS is very actively pushing devs away from it.

I wonder, how are other dev shops handling the DX interface instability? Are you actually re-writing your graphics engine every ~2-3 years? Are you using 3rd party middleware? Both OGRE and Unity seem like tons of code, have design goals I don't care about (cross platform), and I'm not even sure their interface is more stable. Are there other ways I'm missing?

Important note: We're not developing AAA games, and we've not much use for fancy shaders or a need to squeeze every bit of performance from modern hardware. Our products just display data mostly in 3D.

it seems some clarifications are in order. The current state of graphics development is that MS issues a completely overhauled DX interface roughly every ~2-3 years. It seems - whether deliberately or not - they are targeting major game shops (or even: game-engine shops), which would happily devote the needed HR to rewrite the 3D graphics engine to conform to the latest and greatest.

Our shop (and I suspect many others) is nothing like that. We present a lot of data in 3D, but do not use exotic shaders and don't care about the latest consoles or GPUs. It makes no business sense for us to rewrite our rendering engine for new features we don't care about - and yet the old engines are becoming deprecated fast. A DX dev from MS writes:

the ability to support a Direct3D 9 application at all is diminished on the latest versions of Windows, and that's likely to continue

And regarding D3DX - while not technically deprecated, is very hard to work with on VS2013. MSDN diplomatic Quote:

Investigate alternate solutions for working with the Direct3D API.

I'm curious: how are other shops with similar 3D needs handling this? e.g., how are you guys in the CAD business doing?

Improve this question
7
  • Are you constantly making updates to the engine you're using? If you're completely content with DX9, why upgrade to VS2013?
    – Ampt
    Jul 30, 2014 at 15:03
  • For reasons completely unrelated - C++ standard conformance, supposed compiler improvements (auto vectorization), annoying bug fixes, etc. etc. Graphics is not by any means the central aspect of our products.
    – Ofek Shilon
    Jul 30, 2014 at 15:05
  • Sounds like you've accumulated some technical debt by allowing the DX9 app to lag behind. If/when they do deprecate DX9, what would you do? Doing a re-write now may not be necessary, but it may be on the horizon. It might make sense to invest the time to bring it up to date now and save on your productivity moving forward.
    – Ampt
    Jul 30, 2014 at 15:08
  • 3
    What instability? DX10, DX11, and DX11.2 are all stable after you make the intial move. You shouldn't have to rewrite anything DX11 contains DX9 compatability within it. If you want to use the new functions that something else entirely.
    – Ramhound
    Jul 30, 2014 at 15:43
  • 3
    to handle troublesome interface changes, consider building an Anti-Corruption layer, so that said changes are "encapsulated" within that layer
    – gnat
    Jul 30, 2014 at 23:31

1 Answer 1

Reset to default
1

Direct3D changes frequently because graphics hardware is constantly evolving. So at some point, Microsoft can no longer maintain compatibility with older D3D versions. This is why fixed-function rendering is gone. Newer hardware doesn't support it, so it cannot be exposed in the API any longer.

Now from what you've explained, your use of 3D doesn't seem very demanding, which probably means you could write a small interface layer to insulate your application from the rendering back-end. If you design the rendering interface well, the amount of actually API dependant code is very small. Even for a large game engine like Ogre3D, if you look in the source code at the API specific folder, you'll see that it consistes of some dozen files. Probably less than 1% of project's code.

With an interface layer between the rendering API and application you can add software emulation in the future if a hardware feature goes away. E.g.: Simulate the fixed pipeline with shaders; So maybe use the API change opportunity for a possible refactoring of the renderer module in a way to make it mode API agnostic.

Improve this answer
2
  • Thanks @glampert. What I'm referring to as a 'graphics engine' is exactly such a layer. It is a very non negligible amount of code, and I'm left wondering if other software vendors keep rewriting it whenever the DX interface overhauls.
    – Ofek Shilon
    Aug 1, 2014 at 12:50
  • Well, nothing lasts for ever. If looking for more stability, OpenGL is probably a better choice, the library maintains a lot more legacy compatibility than D3D, but even GL had to make the shift to programable rendering, because, like I mentioned, the hardware has changed, so there isn't much you can do there but adapt to the change.
    – glampert
    Aug 1, 2014 at 18:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.