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

[Bruninho]

@AndrewNi @helkaluin I have the same results with both your libraries. Upon running GP3, host machine fires up XQuartz app and QEMU crashes back to the terminal, terminating the XP vm. Counter-Strike 1.5 freezes before loading the map.

Latest QEMU-3Dfx builds no longer require X11/XQuartz on Macs, so I don't understand this call. I can run it with X11 if I recompile SDL2 with X11 and set 'export SDL_VIDEODRIVER=X11' before running QEMU (Which I was doing when X11 was required) and it will most certainly work there. But he is doing it without X11 now on his youtube videos and I don't know how... would be good to know because without X11 the performance should be much better.

Now I have a theory and I think that the problem must be the way I compile QEMU here on my Mac. I have excluded other possibilities with these tests - These WineD3D libraries above should work, provided I compile QEMU-3Dfx correctly, from what I can think of these possibilities.

After following his instructions on github, this is how I configure qemu before I issue 'make': 

$ ../qemu-6.2.0/configure --prefix="/Volumes/Macintosh HD/Users/bruninho/QEMU/qemu-3dfx" --enable-sdl --disable-cocoa --target-list=i386-softmmu,x86_64-softmmu

This build was built when SDL2 was 2.0.16, last week I tried to redo with latest SDL2 (2.0.20) yet it would not run. I am not sure which SDL2 version kjliew is using. The --prefix is used to tell where to install the files when I issue a 'make install'. Apart from that, it's no different from his instructions (I also made it compile faster by reducing the target list to what I really need).

Later when I have some free time I will try to recompile and see what happens.

[pangoomis]

He is probably watching this topic, I am judging that by his "QEMU Prince Of Persia 3D (1999)" video  Let's test it:

Yes, we might be totally wrong about the issue of paying for your project, that's not even the main concern.

You seem like a very knowledgeable person, just like rloew was. Understand that your project and other projects can co-exist in peace. They are fundamentally different, but can be used for the same goals, Nothing wrong with having a choice. Emulating PC components as a whole has its benefits, just like GPU passthrough does, no need to exclude one just because the other exists.

We can point things at your project, and you can point things at other projects, you bring good points why your solution is superior, and we (or at the very least I) wouldn't have a problem with that.

However, don't behave like that your words are the almighty truth and everyone else is an id*** and have no rights to voice their opinions. Your borderline vulgar remarks are often unnecessary and do not do anything other than make people potentially turn their heads off your one-of-a-kind project. We are very interested in your work and as I've said, I am considering making a donation and test it, believe me, I have the hardware and determination, just don't want to feel like I have to watch every word of mine so I do not get attacked by you just because I might have some remarks about your project. Present your project better, without personal remarks and you would only benefit from this with more positive publicity and potentially more donations. You do know that history showed that many great projects got destroyed by mixing amazing programming with personal feelings (and therefore personal life)? Just don't act you're above everyone else, OK?

I do not recall rloew pointing fingers at everyone in every post he made and he did commercial work for old systems enthusiasts just like you do, and no-one had any problems with that. I bought his AHCI driver before he passed away. I have plans to donate to you in the future, but if you keep making things personal for everyone even slightly interested in your project, I will not.

 

 

[Bruninho]

@MrMateczko LMAO. I saw the video just now. I did talk to Federico Dossena (author of WineD3D on Windows) and Henri Verbeet (from CodeWeavers/WineHQ) about the legality of it. Verbeet also informed Alexandre Julliard about that work he's doing.

While Federico does think he is violating the license, Verbeet was unsure, but both said the same thing: the corresponding source to build these libraries must be made available to people purchasing them, and additional restrictions cannot be imposed on them, e.g. redistribution of that source code.

There is no source code for these custom-made WineD3D libraries for his QEMU fork being made available from him, and I haven't heard from other buyers if they have got the source code along with the pre compiled libraries. I suspect they didn't. The way I see it, it's a violation of the license.

He should have made it available for anyone capable of building them. And for those who aren't capable, he could mantain the donation with a fair price along with the support for the three main games. This way he is completely legal under the license.

CrossOver has nearly the same price tag, and is a more complete product along with a frontend to run them in an easy way. My games ran as if they were native on Mac. Unlike his project, a puzzle you have to mount yourself to make it run, while you scratch your head...

Edited April 26, 2022 by Bruninho

[Bruninho]

I've tried to recompile that fork of QEMU on my M1 Mac twice just now. Successful builds. And yet the damn thing still fires up XQuartz.app when I want to run a game with one of those WineD3D libraries before crashing QEMU and sending me back to my host terminal, with the same errors I mentioned here before. I can only run Glide games. Grrrr....

[Bruninho]

@MrMateczko another gem of a dig from him at the end of the video comparing us (and the Vogoners) with the dark side of the Force (ROFL): https://www.youtube.com/watch?v=xXrdhvNTcsY

ROFL. Seriously. He really believes that he's right. He has ZERO community spirit.

His work could be even better and easier if he were able to fork something like UTM or a frontend to run his QEMU fork. And then provide an installer for the WineD3D libraries just like SPICE Tools on QEMU/UTM.

But no... "let's choose the path of extortion and ask for a hefty donation (USD 59.99) to provide these gold WineD3D libraries to run DirectX based games". He could have something much better than WINE, PCem and DOSBox for the entire retro community, since he hates all other emulatores so much, that with this work he could obliterate them; but instead he chose to go rogue.

"So this is how democracy dies, with thunderous applause." -Padme Amidala, Star Wars

Look at UTM. The developer (osy) knows he has something SO GOOD, that it can fight with VMware/Parallels/Virtualbox. Dude, UTM is the fifth most downloaded app from the business category on Mac App Store. His only weakness is that 3D acceleration is only supported on Linux for now (thanks to the work of another developer with whom he collaborated to make it happen). But it means that UTM is being downloaded by people willing to have Windows to run their apps on Mac for various reasons related to work/business/production.

However, osy is not demanding a single penny to produce the binaries for us. Yes, he has a sandboxed version of the app on Mac App Store, but he asks for only USD 9.99. The sandboxed version has limitations compared to the non-sandboxed one available on his github page for free, due to the Apple's policy on apps standards. I don't know why, but here's my take: He gives us a chance to test his software and if it works as expected, we can sure as hell buy it on App Store to support him. Therefore with both routes to get the app, he is well within the legal GNU GPL license standards.

Which kjliew fails to do with the WineD3D libraries required for his QEMU fork. Here's a tip, I know he is reading the thread, at least let people choose how much to donate, be it $0, $1 or $59.99, and then proceed to download the libraries. Then he might have some traction for development. Most GNU GPL licensed projects do it anyway. ElementaryOS is a (good) Linux distro and a good example of that.

Edited April 28, 2022 by Bruninho

[AndrewNi]

Bruno, have you tested ordinary OpenGL programs within the guest? e.g. wglgears is often used as a demo. If you have, does it crash qemu in the same way? I expect it would still load XQuartz, though. I don't have a Mac, but on Windows as the host, it always produces a new MESAGL window when doing OpenGL passthrough work. This sounds similar to what happens with XQuartz.

In keeping with the thread, I have been looking at ReactOS. The qemu-3dfx wrappers work perfectly fine within it, and if you put the opengl32 wrapper into the system directory, ReactOS' implementation of WineD3D (which seems to be around version 3.3, but with some extra patches) will pass along the OpenGL commands. ReactOS' compatibility with the Windows programs themselves is a bit hit-and-miss though, so I have isolated the WineD3D components for use on Windows XP RTM+. They even made a nice control panel applet.

ReactOS' WineD3D 3.3ish DLLs: https://mega.nz/file/kcpmEJ7I#KRmaA--70ssX3-O162Yg-Dz76IXYfDlJoIKAd-jPohA

As for the license thing, I thought it was quite straightforward. Wine is licensed under the GNU Lesser Public License 2.1, and it says that a fee can be charged for the binaries/sources, with no upper limit etc. As long as anyone who pays can successfully ask and receive the source code, then there's no problem. (e.g. when you buy a Linux-based router, you get the binaries in its flash memory but no source code, just a website to visit if you want it.)

So this lay person (<----) highly suspects he's in the legal right. Of course, anyone who does buy them gets 100% of the rights he has too - so, for example, I could buy his product, then legally sell them to two people for $40 each and make a profit.

5 hours ago, Bruninho said:

He could have something much better than WINE, PCem and DOSBox for the entire retro community

Steady on... actually I'm surprised he didn't work out a deal with you. Instead of spreading the good word across half the web, you've spread the erm... not-as-good word. You could be like, the CEO of project advertisement, after all, I only found out about this project via your postings.

[Bruninho]

55 minutes ago, AndrewNi said:

1) Bruno, have you tested ordinary OpenGL programs within the guest? e.g. wglgears is often used as a demo. If you have, does it crash qemu in the same way? I expect it would still load XQuartz, though. I don't have a Mac, but on Windows as the host, it always produces a new MESAGL window when doing OpenGL passthrough work. This sounds similar to what happens with XQuartz.

2) In keeping with the thread, I have been looking at ReactOS. The qemu-3dfx wrappers work perfectly fine within it, and if you put the opengl32 wrapper into the system directory, ReactOS' implementation of WineD3D (which seems to be around version 3.3, but with some extra patches) will pass along the OpenGL commands. ReactOS' compatibility with the Windows programs themselves is a bit hit-and-miss though, so I have isolated the WineD3D components for use on Windows XP RTM+. They even made a nice control panel applet.

ReactOS' WineD3D 3.3ish DLLs: https://mega.nz/file/kcpmEJ7I#KRmaA--70ssX3-O162Yg-Dz76IXYfDlJoIKAd-jPohA

3) As for the license thing, I thought it was quite straightforward. Wine is licensed under the GNU Lesser Public License 2.1, and it says that a fee can be charged for the binaries/sources, with no upper limit etc. As long as anyone who pays can successfully ask and receive the source code, then there's no problem. (e.g. when you buy a Linux-based router, you get the binaries in its flash memory but no source code, just a website to visit if you want it.)

So this lay person (<----) highly suspects he's in the legal right. Of course, anyone who does buy them gets 100% of the rights he has too - so, for example, I could buy his product, then legally sell them to two people for $40 each and make a profit.

4) Steady on... actually I'm surprised he didn't work out a deal with you. Instead of spreading the good word across half the web, you've spread the erm... not-as-good word. You could be like, the CEO of project advertisement, after all, I only found out about this project via your postings.

1) Nope.

2) I can try it out. But I don't expect any miracles. Nope, they do not work. Thanks anyway.

3) In my previous post I alread left an advice regarding the amount he's been asking for a donation, in case he is really reading the thread. However, in my opinion, to be in the legal right, he has to provide the source code for his custom WineD3D libraries and the means of compiling it for free too, if he wants to charge a (hefty) fee for readily built ones. That's my view when I read the license.

4) No way. I am a 20 yr old seasoned web developer. I've worked with many programmers. I've met good and bad programmers. He is a bad one - does not mantain a consistent and good documentation of his project, is arrogant like hell, and unable to help/assist people willing to compile and run his fork with some sense of education, nor respect others works with other emulators like PCem. I would NEVER want to work with a guy like him. His behavior is outrageous. Go read his posts and rants about other emulators on VOGONS forums. Then you'll understand why he was banned by the moderators there.

He does not have a community spirit sense. No wonder why he got banned from VOGONS.

Edited April 28, 2022 by Bruninho

[Bruninho]

Anyway, since I cannot get it to work with any other WineD3D library, and since kjliew is not exactly a community/cooperative guy, I decided to give up on QEMU-3Dfx and put some effort in talking and testing with the DOSBox-X guys to improve and fix the issues that were preventing me to run some of the games with its 3dfx emulation, which were the reason why I gave QEMU-3Dfx a go in the past.

It's sad to see that solution for QEMU not being used as it should by the community. Nothing we can do, the guy is very selfish.

More modern games (GP4, Counter-Strike, Max Payne...) I will just leave for a modern Windows VM in Parallels Desktop. I will have to live with that. Case closed.

[Bruninho]

He’s definitely reading our thread. 😂

[AndrewNi]

He is? Hi Liew 

On 4/29/2022 at 12:00 AM, Bruninho said:

1) Nope.

Do you mean "nope, I haven't tested other OpenGL programs" or "nope, it doesn't crash, they work fine"?

The ReactOS DLLs are the best working ones on my system. GP3 seems to work OK with them, but I still have the missing texture thing that I also saw in Bugs Bunny. Also my computer isn't very fast at all (far removed from a $6000 machine), so it's outputting about 1fps. It's so slow in fact, the FPS counter that usually proudly appears in the console isn't there. This screenshot comes from the calibration option. Maybe it's night time...

I was puzzling over commit 0dd2b2d. Normally, if you put the file mesagl.cfg in the same directory as the program, you can limit ExtensionsYear to a specific year for the whole VM. However since that commit, whenever a WGL function is called, the value is reset on purpose.

I don't know if it's because I'm using Windows as the host, or if it's the guest software's behaviour, or whatever, but virtually every call seems to be a WGL function/started with one and thus the host cap is being effectively ignored. The puzzle is... why? Why ignore the cap for WGL? (Although capping the year didn't help with the missing textures.)

[Bruninho]

@AndrewNi "nope, I haven't tested". I tried GP3 and Counter-Strike 1.5 & 1.6.

I may have to try again the reactOS libraries now that I can run this qemu fork through X11 (will be slower than natively). If it works, and it's a big IF, then I need to figure out how did he make it work without X11 with his M1 Mac. No idea how.

You can limit the year with a glide.cfg file, as he stated here: https://github.com/kjliew/qemu-3dfx/issues/15

[Bruninho]

@AndrewNi which video driver are you using (cirrus? vbemp?) and which gpu are you emulating (-vga, -cirrus-vga, -vmware-svga...) when you did that test with GP3?

I finally got the same results you had from the screenshot above using your libraries. I also had to start qemu with X11 (export SDL_VIDEODRIVER=x11) but from his youtube videos using the same M1 Mac as me, he is not using any X11 at all now. I need to find out how he is doing it.

The first run of GP3 did not work, but the 2nd attempt after a small glitch (missing GL context, it seems) it finally showed the same result as you.

Edited May 9, 2022 by Bruninho

[Bruninho]

These ReactOS libraries worked 99% fine with Counter-Strike 1.5, when I set it to use OpenGL, default driver and 1024x768 in game settings. the 1% is because when I get into the actual play, the mouse pointer is missing, so I had to navigate through the menus using the keyboard. Now if we manage to improve GP3 performance somewhat, AND find out why the textures are missing for that game...

Installed CS 1.6, works, somewhat slower, same settings, and the mouse pointer is missing from the entire game. At least the cross for aiming is not missing when shooting.

Edited May 9, 2022 by Bruninho

[Bruninho]

Another discrepancy... if I want to run a glide game, I have to run QEMU without X11 (SDL_VIDEODRIVER=). If I want to run a OpenGL/D3D game, I have to run QEMU with X11 (SDL_VIDEODRIVER=x11).

I need to fix something. Clearly. No idea what.

I installed Grand Prix 3 in a Windows 11 Pro ARM64 VM using Parallels Desktop. To enable 3D accel, I used dgVoodoo2.

Turns out, performance is acceptable. Good for dry track, not so good for wet track. But Software mode graphics are so much better than hardware mode, except for the rain and wet track effects. I don't remember the graphics being that BAD when I was 16/18 yrs old and playing that game.

So playing GP3 in software mode might be more than enough. No need to have it in a Win 11 VM then. That VM has only GP4 (perfect) and Max Payne 1 (perfect) as well as CS 1.6 (even more perfect).

Edited May 9, 2022 by Bruninho

[AndrewNi]

7 hours ago, Bruninho said:

@AndrewNi which video driver are you using (cirrus? vbemp?) and which gpu are you emulating (-vga, -cirrus-vga, -vmware-svga...) when you did that test with GP3?

I'm using -vga std (the default) and vbemp NT version k.

5 hours ago, Bruninho said:

Now if we manage to improve GP3 performance somewhat, AND find out why the textures are missing for that game...

The performance is no mystery on my PC - I can't use any accel options because I use VirtualBox, which conflicts with them. It's all software CPU emulation. The textures are what I'm more interested in working out. On Bugs, the textures are fine on my old ATI graphics card, and in Liew's video playing GP3, he's using a Windows machine with an AMD Vegas GPU.

Is it possible that the Intel GPU and Apple M1 GPU cores are missing an OpenGL extension that AMD/ATI GPUs have? Or maybe the wrapper maps them in a strange way? I admit to being very confused as to how backwards compatibility works in OpenGL.

This is all fun and curiosity for me, so if Parallels works, then great! Case closed, as you say.