How hard would it be to port a directx 7 application to run on Windows 7?

Question

We had an arcade/redemption game running on Win98, but hardware which can run it has finally gone obsolete. The game used a number of scaling effects, some through the 3D path, and played some tricks moving things in and out of video memory. If I was to undertake porting it to run on Windows 7, how much trouble would it likely be? Would it mostly be recompilation, or have the APIs undergone such transformation that I might as well re-write the device interfaces?

Answer 1

It's been a while since I've written any DirectX7 code (or Direct X code at all) but if I recall there were some significant API changes event between 7 and 8 - let along 9 or 10 - that would make such a change a bit more difficult. Specifically I think the major change was that they refactored the system after 7 to merge DirectDraw into Direct3D so that the two systems were no longer completely separate between 7 and 8. I haven't look at it since then, but I suspect that given the number of new coding methods and like that the API has change quite a bit so it is probably going to be a bit of a project to make these changes rather than mostly recompilation like you might have hoped.

Answer 2

You EVER moved things in and out of video memory? shudder

Still ... its quicker to do that now than when DX7 was around. What exactly were you doing? From your description its impossible to say how easy it would be. A DX7 app should still run on Windows 7, I can't think of what odd features you may have used that would cause it to break.

Also converting an application to DX9 from 7 is not actually all that hard (Converting to DX10+ would be a nightmare). They are still relatively similar ... the main thing that has changed since those days is the shortening of things like D3DTRANSFORMSTAGESTATE_* or D3DRENDERSTATE_* to D3DTSS_* or D3DRS_*.

Edit: The biggest change I can think of that has happened since DX7 is that graphics card manufacturers have dropped support for palettised textures which "could" break some old apps on modern machines. That really is a very simple fix though ...

Edit2: Decompressing things from disk into a texture can be a bit of a pain. Your main issue is the fact that you end up suffering A performance hit when you create the texture. However if you have a load of textures already created and open then you can load to the relevant texture as and when you please. You only suffer a lock/unlock hit. That can be mitigated by loading a resource a few frames in advance. If you do this, though, it will no doubt require multi-threading and calling D3D from multiple threads. If you do this set the multi-thread flag on the device.

Answer 3

Don't think of it as porting to Win7. Just simply port to DX9 and let DX do the work with the Win7 parts. Infact, you could probably just leave it as is and it shuold run -- but you mention you do crazy things with video memory that I assume has nothing to do with DX. (ie either through GDI or some other hack?). Anyway, the DX7, 8 and 9 APIs all have quite drastic differences. But the nice thing is they're all backwards compatible. If the code you have is pure dx7, try compiling against the latest SDK and see if it works on win7 straight off.