Well, it's not a lack of interest that's holding us back in creating DX1-7 wrapper, but a perspective of spending 7 years (and maybe even more) before the wrapper became 99% compatible.
There's also another problem. Let's say we'll use DX12 as a target API, but will DX1-7 games be still compatible after that period of time with Windows 10?
(7 years being about how long nGlide's been in development if I recall correctly...)
"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen
There's also another problem. Let's say we'll use DX12 as a target API, but will DX1-7 games be still compatible after that period of time with Windows 10?
Well he already answered his question himself 😉
Zeus wrote:You're missing a simple fact that wrapper is not an emulator. Who needs a wrapper that wraps let's say to
DirectX 14 if none of […] Show full quote
You're missing a simple fact that wrapper is not an emulator. Who needs a wrapper that wraps let's say to
DirectX 14 if none of these games that use it work anymore?
You're also missing a fact that success of Windows XP (along with DirectX 9) is unprecedented in the whole Windows history. Did you forgot when Microsoft released DirectX 9? It was 2002! And still, it will be supported in Windows 8 (thus, for at least next 3 years).
This means DirectX 9 offers the widest range of operating systems (thus, compatibility with old games) and graphics cards (thus, user base). DirectX 11 cuts down everything by 70%.
DirectX 9 -> DirectX 11 wrapper won't be needed since DirectX 9 will be supported in Windows 8. And in DirectX 14 era there won't be any sense in using Glide or early DX API wrappers. You will use a Virtual Machine with Windows XP and DirectX 9 support then.
Little update.. the wrapper generator is taking shape; current output is around 320k of code. There's still a few nasty functions to figure out, namely those where one interface returns another (but does not create them), like when a texture is queried for the ddraw interface that was used to create it, or surfaces returning attached surfaces, etc.
As a reminder, the current target is just to make a pass-through wrapper that doesn't actually affect the functionality, but generates logs. This can then be used as a starting point of all sorts of hacks.
Well, it's not a lack of interest that's holding us back in creating DX1-7 wrapper, but a perspective of spending 7 years (and maybe even more) before the wrapper became 99% compatible.
My goal isn't to be 100% compatible, but to primarily enable other people to hack ddraw/d3d more easily, and after that goal, to get, maybe, 3dvision working with crimson skies =)
Now I managed to run CS with the wrapper so that the splash screen, intro videos, menus work (with some graphical glitches), but I get a crash when entering the game itself. csfix naturally fixes all of the above problems, but does something strange itself and chaining my wrapper with csfix doesn't work =)
And no, still haven't gotten replies from Timeslip regarding this. But I did get a 100k-line log, which I'm NOT pasting on this forum =)
It does do plenty of stuff with d3d3, though.. and apparently if d3d8.dll isn't in the system, it just gives a popup asking to update directx. It apparently never USES d3d8.dll for anything.
I'm kinda starting to wonder if this is actually a dx3 game that has been stamped with dx7 for marketing purposes.. of course, it's still possible the ingame proper is dx7, since I can't get that far.
Added more self-defensive code to the wrapper, basically trying to wrap all incoming pointers from various interfaces like getPalette, but the crimsonskies->mywrapper->csfix->directx chain still crashes. Sigh.
Spent some time refactoring wrapper generation code to be simpler, and the generalizations I did to delete ~600 lines of code apparently fixed the bug, since now I get to the ingame! Yay!
And based on the logs I generated, it does seem that crimson skies is definitely not a directx7 game. At least on the graphics side.
Pondering whether I should bother learning dx9 or to use OpenGL as the back-end.. if I used gl1.x (which should be more than enough), I could use gldirect to handle the directx transform. On the other hand, a direct dx9 output would be cleaner, and some stuff (like render states) should, more or less, go through as is. Maybe.
Anyway, whichever way I'll go, the directshow/directmedia will cause headaches, so I started looking at the logs trying to figure out how it's used. I don't see the directshow calls (and I'm considering wrapping them just for that), and a frame of video currently looks like..
..which is downright mysterious with all those texture stages, but crimson skies seems to do all sorts of stupid things anyway, so they may be leftovers from some experiment..
DDraw centric ramblings
that you may or may not find interesting.
SetPrivateData() solves almost all problems tracking object lifetimes.
Tracking surfaces can be offloaded completely.
Clippers and palettes that are implicitly released...
( wrapper interface never receives a release call that returns "0" )
If we dds->SetPrivateData( IWrapClipper, DDSPD_IUNKNOWNPOINTER ) when attaching a clipper/palette to a surface,
the release method of the clipper/palette wrapper will be explicitly called when a surface is destroyed
if the surface was holding the last reference to the clipper/palette object this call will return "0"
SetPrivateData was introduced in DX4 but a dds1 can query up for a dds4
call SetPrivateData then release the dds4 interface...
The dds1 interface will call the release method of the wrapper when dds1 is destroyed.
note:
the wrapper interface doesn't need its own separate ref counting, it is still just a pass-thru to the real object
Registered just to let you know that for years I have been keeping an eye out for this type of wrapper. Hope you can make it work but if not, at least it's an interesting to see the process involved at trying to do it.
Registered just to let you know that for years I have been keeping an eye out for this type of wrapper. Hope you can make it work but if not, at least it's an interesting to see the process involved at trying to do it.
Well, don't hold your breath - even if I get CS to work, I can't promise it'll work for other games.
I found this post while looking for a directx to opengl wrapper so I could double wrap various games -- though not expecting much 😉
(( Insert lengthy rant about nvidia slicing out working code from their stereoscopic driver here ))
I just wanted to say thank you for working on this. Regardless of where it goes from here, it's uplifting to know that someone with experience has interest in such a project, and I wish you great luck and success! I'll be following closely! 😎😀
Im having a problem with windows 8 not running my older games that use direct x 7, it will run but the screen will be completely black but i can still hear sound. I looked this issue up it said something to do with older direct x programs using mixed direct x call and not being allow to draw on the screen by something in windows 8, will this wrapper help me fix this issue?
