2009-09-29, 03:06 AM
I've actually thought a lot about the only way to do this. I even ordered a couple DX7 books. Unfortunately thinking about it might be as far as I ever get.
I was able to toss together a DLL that can pretend to be the directdraw dll, which is the library DX7 interfaces with for graphics. This isn't all that hard to do because there are only a few imported routines for most directx applications. There are several other hidden routines called by the imported routines, which fortunately I was just barely able to find signatures online for.
The problem is the DX APIs rely heavily upon C++ "virtual" functions (which is why there are only a few exports) ...For C apps there is a preprocessor way of simulating virtual functions (not that it matters)
Anyway this proxy dll (it routes the function calls to the real directdraw dll) is really more valuable because from within it I can theoretically have my way with the SOM runtimes' writable data segments (which will be awesome, if/when I ever find a way to reliably locate it)
It is possible however, that I could program my own set of virtual classes and have them mimic the DX interface perfectly each virtual function being interpreted so to do extra stuff to find out why things don't display properly. The thing is there is nothing wrong with SOM. What the real problem is Microsoft has not done a good job of keeping software built on older versions of DX functioning correctly. All of the DX7 calls are routed to DX9 or DX10, but not properly. The problem with the tools is they seem to mix GDI with DX which for some reason does not go over well with contemporary drivers. It's possible this is no longer possible, though I'd think there is some way to make it work with contemporary drivers. You'd think though if it was possible the drivers would make it work somehow. Another possibility is the graphics in the tool are just not being lit correctly, possibly making them appear to not be there when they really are (edited: in fact this is probably the case now that I think about it, because I do sometime see graphical artifacts when using the tools where the 3D graphics should be)
Aside from completely replacing the directdraw API, it should be possible (and fairly straight forward) I think to mix in our own graphics routines, so to add like simple under water and other atmospheric effects (like drawing a dark overlay under the water level and maybe distorting the view beneath that line) ...replacing the sky with something more appropriate, etc.
If you have the time I could put you on the right path for replicating the DX api. Personally I don't have the time and I try not to learn anything about DX if I can help it. If you could pull it off, I would take the time to route thru a superior APIs like OpenGL. There would also be merit in doing the same with Direct Sound and Direct Input, and probably other Direct Crap.
I was able to toss together a DLL that can pretend to be the directdraw dll, which is the library DX7 interfaces with for graphics. This isn't all that hard to do because there are only a few imported routines for most directx applications. There are several other hidden routines called by the imported routines, which fortunately I was just barely able to find signatures online for.
The problem is the DX APIs rely heavily upon C++ "virtual" functions (which is why there are only a few exports) ...For C apps there is a preprocessor way of simulating virtual functions (not that it matters)
Anyway this proxy dll (it routes the function calls to the real directdraw dll) is really more valuable because from within it I can theoretically have my way with the SOM runtimes' writable data segments (which will be awesome, if/when I ever find a way to reliably locate it)
It is possible however, that I could program my own set of virtual classes and have them mimic the DX interface perfectly each virtual function being interpreted so to do extra stuff to find out why things don't display properly. The thing is there is nothing wrong with SOM. What the real problem is Microsoft has not done a good job of keeping software built on older versions of DX functioning correctly. All of the DX7 calls are routed to DX9 or DX10, but not properly. The problem with the tools is they seem to mix GDI with DX which for some reason does not go over well with contemporary drivers. It's possible this is no longer possible, though I'd think there is some way to make it work with contemporary drivers. You'd think though if it was possible the drivers would make it work somehow. Another possibility is the graphics in the tool are just not being lit correctly, possibly making them appear to not be there when they really are (edited: in fact this is probably the case now that I think about it, because I do sometime see graphical artifacts when using the tools where the 3D graphics should be)
Aside from completely replacing the directdraw API, it should be possible (and fairly straight forward) I think to mix in our own graphics routines, so to add like simple under water and other atmospheric effects (like drawing a dark overlay under the water level and maybe distorting the view beneath that line) ...replacing the sky with something more appropriate, etc.
If you have the time I could put you on the right path for replicating the DX api. Personally I don't have the time and I try not to learn anything about DX if I can help it. If you could pull it off, I would take the time to route thru a superior APIs like OpenGL. There would also be merit in doing the same with Direct Sound and Direct Input, and probably other Direct Crap.