Jump to content

Compiling newer WineD3D for 98SE and/or XP...?


Bruninho

Recommended Posts


@MrMateczko  another use on VOGONS told me that he used the WineD3D 1.8.6 and had success. No special build or whatever, just the binaries from the main site. I am confused.

I tried the 1.8.6 from Federico Dossena's website (is there any other WineD3D 1.8.6 build?!) and while it did call MESA correctly, it still fired up X11 on my Mac and crashed QEMU. Back to square one.

But, at least now I know one version that would work here. I wonder if I need to roll back my qemu-3dfx version to when it needed X11 to run. I don't know how to do that (I don't even know which commit to roll back to), and I would also need to roll back SDL2 to 2.0.14 I think. It's a huge drama.

I tried to email a wine team member about the license and I still haven't got a reply yet. Seems that winehq.org has no way to contact them or report it to them. Bummer.

Link to comment
Share on other sites

Using his QEMU-3Dfx code from late 2020 (september/october, before his SDL2 plumbing update) I have to use X11 to display the VM. Latest code does not need to use it anymore.

Now, using the old version of this code, I can run different WineD3D libraries from Federico Dossena, and I have tried two games: Counter-Strike 1.5 and Grand Prix 3 on Windows XP SP3.

GP3 does not start, it does show the intro on second attempt to start the game, but fails with "No GL context for func 02fc"

Counter-Strike 1.5 can run it, but its unplayable, near zero speed. Also, some graphics are garbled.

Back to square one.

More updates

Tried with different WineD3D libraries like 4.12. Same results. Grand Prix 3, Counter-Strike 1.5, NBA Live 98 are not playable with WineD3D there. Before someone say something about these libraries, I can play these games on CrossOver for macOS. All three are playable in software mode on QEMU, and QEMU-3dfx, and Counter-Strike 1.5 is playable with the OpenGL mode (3dfx minidriver) on QEMU-3dfx.

Grand Prix 3 can even run better in software mode, although we do lose some graphics eye candy with wet-weather races. NBA Live 98 is supposed to be much better looking with D3D/3Dfx, but I can't get it to work in QEMU-3dfx.

I really really need these WineD3D libraries modified to run on his newer QEMU-3dfx code.

Edited by Bruninho
Link to comment
Share on other sites

  • 2 months later...

@BruninhoI recently stumbled across your thread (having stumbled on the qemu-3dfx project as well). Is your main problem about compiling Wine? Cause it's quite straight forward on Ubuntu.

I don't have any games to test but if you want some specific version of Wine built for the i686-w64-mingw32 target, just leave a message. No guarantees if they'll work though since I have no idea at which release did the Wine devs removed xddm support. Or indeed if kjliew is applying some patch for Wine to work with his QEMU environment.

Link to comment
Share on other sites

4 hours ago, helkaluin said:

@BruninhoI recently stumbled across your thread (having stumbled on the qemu-3dfx project as well). Is your main problem about compiling Wine? Cause it's quite straight forward on Ubuntu.

I don't have any games to test but if you want some specific version of Wine built for the i686-w64-mingw32 target, just leave a message. No guarantees if they'll work though since I have no idea at which release did the Wine devs removed xddm support. Or indeed if kjliew is applying some patch for Wine to work with his QEMU environment.

Unfortunately, my environment is MacOS (Monterey, 12.3). My main problem is actually compile just the newer WineD3D libraries (the DLLs) required for use in qemu-3dfx with Mesa/GL passthrough and Windows XP or 98 (kjliew says he managed to build for both). I also don't know if he is applying some patch - so far I don't think he did.

The mentioned DLLs are: d3d8.dll, d3d9.dll, d3d10.dll, d3d10core.dll, d3d11.dll, ddraw.dll, dxgi.dll, libwine.dll (that one shouldn't be required with newer WINE libraries), and wined3d.dll. Games only require two or three of them. Example: A DX7 game requires only ddraw.dll, wined3d.dll and libwine.dll if WINE is older, along with the custom built opengl32.dll that comes after compiling qemu-3dfx wrappers. A DX9 game will require d3d9.dll replacing ddraw.dll. You just have to put them in your game folder.

If you can compile these libraries from a newer WINE built, and cross compile them for the above mentioned Windows versions, and if they do work, then we can overcome the hefty donation he asks for them. You can test them against games like Counter-Strike 1.6 (enabling D3D instead of OpenGL), Grand Prix 3 (disabling software mode and enabling hardware mode). Any other DX7 or DX9 game will support it.

He has a youtube channel demoing some games as well. https://www.youtube.com/channel/UCl8InhZs1ixZBcLrMDSWd0A/videos so you can see which games he demoed.

In these videos I was able to figure out which versions of WineD3D he used for some games: 1.8.7, 1.9.7, 2.0.5, 3.0.5, 4.12.1, 5.0.5, 6.0.2. Looks like he used 5.0.5 for Grand Prix 3 which was my main interest here. One of the videos is a walkthrough: https://www.youtube.com/watch?v=_cTy6CLkZbE

 

Edited by Bruninho
Link to comment
Share on other sites

11 hours ago, Bruninho said:

Unfortunately, my environment is MacOS (Monterey, 12.3). My main problem is actually compile just the newer WineD3D libraries (the DLLs) required for use in qemu-3dfx with Mesa/GL passthrough and Windows XP or 98 (kjliew says he managed to build for both). I also don't know if he is applying some patch - so far I don't think he did.

The mentioned DLLs are: d3d8.dll, d3d9.dll, d3d10.dll, d3d10core.dll, d3d11.dll, ddraw.dll, dxgi.dll, libwine.dll (that one shouldn't be required with newer WINE libraries), and wined3d.dll. Games only require two or three of them. Example: A DX7 game requires only ddraw.dll, wined3d.dll and libwine.dll if WINE is older, along with the custom built opengl32.dll that comes after compiling qemu-3dfx wrappers. A DX9 game will require d3d9.dll replacing ddraw.dll. You just have to put them in your game folder.

If you can compile these libraries from a newer WINE built, and cross compile them for the above mentioned Windows versions, and if they do work, then we can overcome the hefty donation he asks for them. You can test them against games like Counter-Strike 1.6 (enabling D3D instead of OpenGL), Grand Prix 3 (disabling software mode and enabling hardware mode). Any other DX7 or DX9 game will support it.

He has a youtube channel demoing some games as well. https://www.youtube.com/channel/UCl8InhZs1ixZBcLrMDSWd0A/videos so you can see which games he demoed.

In these videos I was able to figure out which versions of WineD3D he used for some games: 1.8.7, 1.9.7, 2.0.5, 3.0.5, 4.12.1, 5.0.5, 6.0.2. Looks like he used 5.0.5 for Grand Prix 3 which was my main interest here. One of the videos is a walkthrough: https://www.youtube.com/watch?v=_cTy6CLkZbE

 

I've compiled the versions you listed. Here you go! https://drive.google.com/file/d/12rG5PGarnWZAiaJkDYJ-gftNzaWALrDM/view?usp=sharing

Reupload with password (password is literally "password") to try to evade Google Drive's abuse scanning: https://drive.google.com/file/d/1EZQ5N_vlMs_YT5YDnepkYmB08BTOxh_N/view?usp=sharing

Note that there's no such thing as "compiling for Windows 98/XP". As far as the compiler is concerned (gcc) there's only the "32 bit Windows" target. Whether it'll work under Win98/XP or not depends on the Wine code --- like I said, the key thing seems to be when the Wine devs removed xddm support.

Edited by helkaluin
Link to comment
Share on other sites

On 4/1/2022 at 4:46 AM, helkaluin said:

I've compiled the versions you listed. Here you go! https://drive.google.com/file/d/12rG5PGarnWZAiaJkDYJ-gftNzaWALrDM/view?usp=sharing

Reupload with password (password is literally "password") to try to evade Google Drive's abuse scanning: https://drive.google.com/file/d/1EZQ5N_vlMs_YT5YDnepkYmB08BTOxh_N/view?usp=sharing

Note that there's no such thing as "compiling for Windows 98/XP". As far as the compiler is concerned (gcc) there's only the "32 bit Windows" target. Whether it'll work under Win98/XP or not depends on the Wine code --- like I said, the key thing seems to be when the Wine devs removed xddm support.

Thanks, got it - I will test them later and report back with what I've found.

Link to comment
Share on other sites

I'm struggling a bit to test - some more modern ones crash due to something missing (must be what you spoke about earlier). Sometimes it's gdi, sometimes it's something about DVMKT or whatever.

Older ones (2.x and older) did fire up, but it made a call to run Xquartz/X11 on my Mac and crashed QEMU back to the terminal. Same behavior I had with the other WineD3D libraries I was testing months ago. The explanation is pretty simple.

If you watch his videos on youtube, the most recents ones running on his M1 Mac do not use Xquartz at all. But any WineD3D library I throw at it for any game calls Xquartz and crashes everything.

Except when I try to run Qemu through X11, then it sort of works with any game... I managed to run Counter-Strike 1.6 with an old WineD3D library, but that test was some months ago and performance was not great. He probably did something with his WineD3D libraries to make it work the way he advertises on his videos. I can't see what it is.

Today I tried to repeat it (Qemu + X11) but I cannot. Whenever I fire up qemu with X11, no display is shown on my screen. I clearly forgot something. I have recompiled everything - openglide, wrappers, qemu-3dfx... and I have even set up SDL_VIDEODRIVER=X11 for that. I also call qemu with the flag -display sdl. No luck.

What the hell did I forget this time to fire up Qemu with X11?

EDIT: Had to downgrade SDL2 to 2.0.14_1 (Was 2.0.20). Gonna try again...

Edited by Bruninho
Link to comment
Share on other sites

Here are the messages I get when I try QEMU-3dfx + XQuartz/X11 along with Windows XP SP3, Grand Prix 3 and different WineD3D libraries:

WineD3D 1.87 & 1.9.7: Crash to desktop

WineD3D 2.0.5: GP3.exe Entry point not found - The procedure entry point D3DKMTCreateDCFromMemory could not be located in the dynamic link library gdi32.dIl.

WineD3D 3.0.5: GP3.exe Entry point not found - The procedure entry point D3DKMTCreateDCFromMemory could not be located in the dynamic link library gdi32.dIl.

WineD3D 4.12.1: GP3.exe Entry point not found - The procedure entry point D3DKMTCreateDCFromMemory could not be located in the dynamic link library gdi32.dll.

WineD3D 5.0.5: GP3.exe Entry point not found - The procedure entry point D3DKMTCloseAdapter could not be located in the dynamic link library gdi32.dll

WineD3D 6.0.5: GP3.exe Unable to locate component - This application has failed to start because ucrtbase.dll was not found. Re-installing the application may fix this problem.

I did not try without X11 because a first attempt showed me that it would not work and crash, too.

So that kjliew dude must have modified something in these libraries.

I'll recompile qemu-3dfx, wrappers and sdl2 to the latest versions and wait for a possible solution in the future.

Meanwhile, DOSBox-X, which would be a much easier solution, has problems with SB16 emulation along with 3Dfx games on Windows 98. All games will crash there unless you set sbtype=none and play them without sound.

Edited by Bruninho
Link to comment
Share on other sites

  • 2 weeks later...

@helkaluin Also, this is what I get when I try to use WineD3D libraries from Federico Dossena. This is WineD3D 1.9.7 and game is Grand Prix 3:

(focus on my 2nd run of Windows XP and ignore the previous. I was running NFS2SE (A glide game) hence why there is some glidept calls. GP3 is a D3D game, so it calls mesapt)

544017828_ScreenShot2022-04-18at4_14_33PM.thumb.png.14fdd7f5705c8a4fda93fa70a0b95f71.png

Game tries to start and host machine fires up XQuartz (???) then QEMU is killed and I'm back to the terminal. This happens with any WineD3D library that MIGHT work apart of those you sent me before.

Most recent QEMU-3dfx versions on macOS no longer require X11 to run. I'm running one of those newer versions I compiled myself. Kjliew managed to make it work pretty much more native on mac. X11 was required before because code was compiled for Linux X11. I'm gonna try Counter-Strike 1.6, but I'm not optimistic.

He definitely does something with these libraries to work with his QEMU fork. That's the question of USD 60 (the "small" donation he asks for three games only, which IMO is an insult).

 

Edited by Bruninho
Link to comment
Share on other sites

I am thinking of donating to him someday. (Haven't I already said that?)

His wording is not super clear, does he mean he will provide WineD3D libraries for those games that a donator specifies or will they be "generic"?

Are there any hints in the videos that he makes individual versions of WineD3D libraries for each video? He surely must have a private git with his WineD3D code that he does.

 

Link to comment
Share on other sites

2 hours ago, MrMateczko said:

I am thinking of donating to him someday. (Haven't I already said that?)

His wording is not super clear, does he mean he will provide WineD3D libraries for those games that a donator specifies or will they be "generic"?

Are there any hints in the videos that he makes individual versions of WineD3D libraries for each video? He surely must have a private git with his WineD3D code that he does.

 

For those 3 specific games only you get priority support from him.

Regarding the WineD3D libraries, I am not convinced they are specific per game yet, but they may be for only one reason: A specific version of WineD3D may work better for an specific game. And that version is the one he will tweak for this purpose. Thats just me speculating what he may be doing. For example, A certain game XXX probably works better WineD3D 4.12 instead of 3.0.6. Another game YYY can work with 5.0.3 but not with other version. I see no reason why this would be relevant, apart of some certain graphics features?

Edited by Bruninho
Link to comment
Share on other sites

Hey.

So I have been following this topic for about a week, here and on Vogons. You've posted about this topic a lot, Bruno. A lot. I'm honestly thinking Liew's asking price might be good value for you. (Although I do have issues with him labelling it as a "willing donation" when there's an exact amount listed, etc.)

helkaluin's builds: Wine began using the D3DKMT* APIs, which are only available on Windows Vista and above. Fun fact: even the latest dev builds of WineD3D work fine on Vista. But that's no good for XP and below. Fortunately, Wine also contains an implementation of those APIs we can link against. I have managed to build three versions of WineD3D - 4.12.1, 4.21 and 5.0.5. They are compatible with Windows XP RTM and above. They won't work with Windows 2000, 98 (not even with KernelEx) or below, not at the moment anyway.

https://mega.nz/file/tBpEQbSQ#tXkiMX_b2UD8-YQbbrtfV1KOivyglORr8FF3qoyn3ek

I have tested these builds on a real Windows XP machine with an ATI Radeon HD4xxx GPU, and they all work well with the standard DirectX samples (rotating teapots, spinning cubes, floating text, etc). I have also compiled qemu-3dfx and all its wrappers, with Windows 7+ as the host target. Building qemu-3dfx itself was actually quite painless, but this is where things get complicated.

The characteristics of the host system are very important. I tried the Bugs Bunny: Lost In Time Demo on Windows XP RTM with WineD3D 5.0.5. Using the exact same VM HD image on two systems - ATI Radeon HD4xxx (booted into W7) and an Intel UHD 630 (W10), I got these two differing results:

Intel UHD 630:

bugs_630.png.10c3b8ab5cfd4b80f61d8724bb7f11b2.png

ATI HD4xxx:

bugs_ati.png.f15e1fd5cf18e62abedde74b458e23bc.png

No textures on the Intel, but perfect functionality on the ATI GPU. I also attempted to play Crammond's Grand Prix 3 Demo, since it's mentioned a lot. However, it wouldn't even start - no crashes as such, just a black screen. Interestingly, it would not work on the host Windows system either, without qemu/WineD3D involved etc. Perhaps it's just a problem with the demo, but it might also be something to do with the host GPU, which of course, propagates into qemu. (In other words, don't get your hopes up Bruno! :- )

As for "did Liew create modified builds of WineD3D?" - I'm confident he did. My evidence? ScaleWindow. See this post by kjliew on Vogons, where he describes using the ScaleWindow setting to stretch the image, because otherwise you get a small box in the corner of the window. If you scroll down the thread a bit to this post, you get to see the whole registry file with ScaleWindow included. This setting is not a part of WineD3D's source code, and it's not listed in the WineD3D registry key settings.

Honestly, although this is a fascinating piece of work, and Liew obviously knows a lot about graphics APIs and GPUs etc, I don't think this is really a viable way to play games. I was testing PowerSlide via Glide, which worked fine graphically, but the truck's wheels kept sticking - something to do with keyboard inputs into qemu, I assume. I've never had a problem like that on PCem. You also get 100% DirectX compatibility with PCem, since you're using the official Microsoft libraries.

Anyhow. I hope that the above libraries are of some use to somebody, and I also hope that Liew gains a sense of community spirit, because at the moment, I don't feel like his efforts are really about game preservation as he claims on his Github page.

Link to comment
Share on other sites

Thanks for your input, @AndrewNi ! I will certainly try out your libraries and give a feedback.

3 hours ago, AndrewNi said:

I'm honestly thinking Liew's asking price might be good value for you.

It's not a good value because it's nearly the same value for a one year subscription of Parallels Desktop for my Mac. And believe me, both Parallels and CrossOver for Mac are much better options, even for a M1 MacBook Air like mine. They're more expensive but better.

I can run Grand Prix 4 thru CrossOver just fine. However, I'd also like to have the experience of using the classic Windows when playing these games, hence why I tried other solutions like DOSBox-X (too buggy and limited performance) and PCem (any macOS build we did on github was just not good enough plus voodoo emulation is broken since M1 compatible code was added). I am convinced that PCem could be the right solution here if the code is optimized and fixed for M1 Macs, given the strong performance the M1 possess.

To point out it's power, the same M1 MacBook Air on youtube is shown from various users running F1 2017 thru CrossOver/Parallels, GTA V thru CrossOver, both with very good performances and playable. Even Apple showed it in their keynote running an intel version of the latest Tomb Raider, through Rosetta 2. A M1 Pro should definitely beat it and a M1 Max is overkill for that. Let's not mention M1 Ultra, ridiculosly powerful.

Grand Prix 3 on both software and 3D accelerated modes have nearly no difference at all - biggest difference is when you do a wet race. Rain effects are perfect in accelerated mode. Software mode rain effects are not THAT bad at all, so playing it in software mode is good enough. Even CrossOver struggles to play it under directx. GP3 is no doubt a demanding game, even though it still uses the same engine and textures as GP2 did, but added some 3D on it. I think VMware on Intel Macs has the best performance for that game alone. Parallels, maybe.

Counter-Strike 1.6 has no glide support but 1.5 does, so I can play this version there while I leave the 1.6 under CrossOver along with GP4. GP4 was a complete overhaul over GP3 in engine and graphics, yet runs better than GP3. Go figure...

And in Brazil, 1,00 USD = R$ 5,00 (as of now) so it's five times the value you think it's "good". R$ 272 is too much for any brazilian to pay for it, when the standard minimum salary in Brazil is around R$ 1200. He needs some "community spirit" if he really wants to preserve games. I thought about negotiating with him a fair value given the exchange rate difference, but I don't think he will, given the way he behaves.

Even Panic Coda had some community spirit when I asked them for a discount to pay for Coda 2 months before they released Nova (I like and prefer Coda, though). They understood the difference in the value and gave me a 70% discount. They're good developers, and have been on Mac scene since decades ago (way before MacOS 9.x and in PowerPC times).

I'd rather stick to software modes than pay that extortion he calls a "donation" for his WineD3D libraries. I am convinced that he is violating the GNU GPL V2 license of WineD3D by doing that.

There's an initial (abandoned) implementation of ATI Rage 128 for QEMU, without any 3D acceleration though. If one could use PCem/DOSBox Voodoo cards code to implement it for QEMU, then all our prayers could be answered with maybe, a Voodoo 2 or Voodoo3 2000 card being emulated. But QEMU was never meant for retro games at all, so theres nearly no interest from the devs to do that.

One thing though is that UTM, a frontend for QEMU on MacOS/iOS, has 3D acceleration for Linux. It will be a long time till we can see it for Windows one day, and it will only work on modern windows though.

Anyway, I'll try out your files and give you a feedback. Thanks for them!

 

Edited by Bruninho
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...