VOGONS

Common searches


Warhammer Dark Omen (1998)

Topic actions

  • This topic is locked. You cannot reply or edit posts.

First post, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

This is yet another very difficult game to make it working on modern system. Dege's efforts with dgVoodoo2 nailed it and made it work perfectly for modern Windows, so you don't have to have QEMU to play it. However, for Linux this could be the only way. Unfortunately it wasn't quite perfect yet, the last remaining issue seems to be a long hidden bug of Wine, the background bitmap was blit twice and one of those was upside down -- FIXED. The screenshot of the game main menu from Wine AppDB shows the exact issue. The game is also a "Garbage" listed on Wine AppDB.

I was able to get Wine 2.0.5 rendering the game battle scene with minor graphics glitches from camera rotate and zoom, but Wine-5.0.3 completely fixed that and the game battle scene was perfect, including scaling from 640x480 to any resolution with hardware 3D acceleration. The game still requires the 1-byte hex-edit patch at offset 0xBD0A8 from 0x01 to 0x00, even running with Win98 VM. It just puzzled me how this game could even run on period correct retro hardware.

Well, QEMU now brings modern CPU/GPU prowess to this old game, for both Windows 10 and Linux alike. The PC version is so much better than the console version. PC games rule, ditto 😁

Warhammer Dark Omen (1998) on QEMU Win98 VM scaled 1024x768

DarkOmen.png
Filename
DarkOmen.png
File size
1.53 MiB
Views
893 views
File comment
Dark Omen
File license
Fair use/fair dealing exception
Last edited by kjliew on 2021-03-10, 21:21. Edited 1 time in total.

Reply 1 of 15, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

IT'S FIXED, IT'S FIXED!!!

I cannot believe this that no one reported this bug to the Wine community 😖, when the DDRAW surface blit takes the CPU path due to DDBLT_DDFX with the same source and destination, the blitter did not use a temporary buffer to avoid overlapping (memcpy vs memmove). With this fixed (and it wasn't a very difficult fix but took considerable time and patience to root cause), Warhammer Dark Omen now runs **PERFECTLY** on QEMU Win98 VM with hardware 3D acceleration from original CD with just the simple 1-byte patch to replace Flip with Blit to screen. Everything worked out great with max quality, audio, FMVs and the in-game/campaign little portraits animation as the story was told.

Neverminded the game does not get GoG or Steam treatment, now it runs great on VMs with the peace of mind isolation that keeps modern OS apart from installing the game native. A wonderful, timeless masterpiece to relive the nostalgic memory of games from the late 90's. All you need is QEMU Win98 VM and Wine-5.0.3. Just rip the CD, install, patch the 1-byte and have fun!

DarkO-perfect.png
Filename
DarkO-perfect.png
File size
345.3 KiB
Views
830 views
File comment
Dark Omen on QEMU Win98 VM
File license
Fair use/fair dealing exception

I wonder how many DirectDraw/DirectX games were affected, the same bug in CPU blitter was there all the way back in Wine 1.8.7.

Reply 3 of 15, by darry

User metadata
Rank l33t
Rank
l33t
kjliew wrote on 2021-03-10, 21:19:
IT'S FIXED, IT'S FIXED!!! […]
Show full quote

IT'S FIXED, IT'S FIXED!!!

I cannot believe this that no one reported this bug to the Wine community 😖, when the DDRAW surface blit takes the CPU path due to DDBLT_DDFX with the same source and destination, the blitter did not use a temporary buffer to avoid overlapping (memcpy vs memmove). With this fixed (and it wasn't a very difficult fix but took considerable time and patience to root cause), Warhammer Dark Omen now runs **PERFECTLY** on QEMU Win98 VM with hardware 3D acceleration from original CD with just the simple 1-byte patch to replace Flip with Blit to screen. Everything worked out great with max quality, audio, FMVs and the in-game/campaign little portraits animation as the story was told.

Neverminded the game does not get GoG or Steam treatment, now it runs great on VMs with the peace of mind isolation that keeps modern OS apart from installing the game native. A wonderful, timeless masterpiece to relive the nostalgic memory of games from the late 90's. All you need is QEMU Win98 VM and Wine-5.0.3. Just rip the CD, install, patch the 1-byte and have fun!
DarkO-perfect.png
I wonder how many DirectDraw/DirectX games were affected, the same bug in CPU blitter was there all the way back in Wine 1.8.7.

Are you running this on non x86 hardware ? If not, then why do you need QEMU ? Wouldn't running Wine directly under Linux be enough ? Am I missing something ?

Reply 4 of 15, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Cool, so I just missed out your past debug efforts that buried deep in the dgVoodoo2 thread.
Good news is both Blt and BltFast work on WineD3D for QEMU. The game unmodified Flip mode failed because it did not seem to attach created surfaces into swapchain and I am not sure how this could work for Direct3D back then with ATI, Matrox, Rendition and Voodoo.

Of course you cannot use vanilla QEMU as the upstream has no 3D acceleration support for Windows guests, be it on Linux or Windows host. My addition to QEMU is the only solution for Windows guests 3D acceleration for QEMU today.

The video footage is also available, if you aren't aware.
https://www.youtube.com/watch?v=WVF7C0YNuqw

Reply 5 of 15, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
darry wrote on 2021-03-11, 02:07:

Are you running this on non x86 hardware ? If not, then why do you need QEMU ? Wouldn't running Wine directly under Linux be enough ? Am I missing something ?

I do anticipate that in future, non x86 hardware will be fast enough for QEMU to run 20 years old Windows games. 😉 It is probably doable now for this one on Apple M1 with a native build of QEMU running TCG, if we had working XQuartz/OpenGL to port qemu-3dfx over.

The advantage of QEMU is VM isolation. If you're on Windows 10, then you can also run the game native with dgVoodoo2. For Linux, I don't think you will be so lucky then. See https://appdb.winehq.org/objectManager.php?sC … cation&iId=5506. The game is listed as "Garbage". Frankly, Wine directly under Linux is more complicated than Wine on QEMU Windows VM because Windows VM only need the DirectDraw/Direct3D DLLs. The rest are all Microsoft true implementation, including D3DRM/D3DIM and other supporting DLLs. When QEMU KVM offers enough performance, it is simpler to just use Win98/ME VMs for games in Linux. The fully working size of Win98/ME disk image with WineD3D is just 300MiB, less than half of Wine installation in Linux. Yeah, I know disk size is cheap today, but VM isolation matters the most to save time of redoing a good running system in case something screwed up. And, you don't want that to happen due to the urge to play an old game 🤣

Last edited by kjliew on 2021-03-11, 03:13. Edited 1 time in total.

Reply 6 of 15, by darry

User metadata
Rank l33t
Rank
l33t
kjliew wrote on 2021-03-11, 02:38:
darry wrote on 2021-03-11, 02:07:

Are you running this on non x86 hardware ? If not, then why do you need QEMU ? Wouldn't running Wine directly under Linux be enough ? Am I missing something ?

I do anticipate that in future, non x86 hardware will be fast enough for QEMU to run 20 years old Windows games. 😉 It is probably doable now for this one on Apple M1 with a native build of QEMU running TCG, if we had working XQuartz/OpenGL to port qemu-3dfx over.

The advantage of QEMU is VM isolation. If you're on Windows 10, then you can also run the game native with dgVoodoo2. For Linux, I don't think you will be so lucky then. See https://appdb.winehq.org/objectManager.php?sC … cation&iId=5506. The game is listed as "Garbage". Frankly, Wine directly under Linux is more complicated than Wine on QEMU Windows VM because Windows VM only need the DirectDraw/Direct3D DLLs. The rest are all Microsoft true implementation, including D3DRM/D3DIM and other supporting DLLs. When QEMU KVM offers enough performance, it is simpler to just use Win98/ME VMs for games in Linux. The fully working size of Win98/ME disk image with WineD3D is just 300MiB, less than half of Wine installation in Linux. Yeah, I know disk size is cheap today, but VM isolation matters the most to save time of redoing a good running system in case something screwed up. And, you don't want that to happen due to the urge to play an old games 🤣

Thank you for the added info and my apologies if I am asking questions about obvious things, but I find this a bit abstract and am trying to wrap my head around the concepts

So, if I understand correctly, you are running a full install of Windows 98 in a QEMU VM with the version of QEMU being a custom one that allows Opengl API requests to passthrough the host OS OpenGL implementation . Within the context of the QEMU guest environment that is running Windows 98, you are running a Windows 98 compatible implementation of WINEd3d for Windows to wrap D3D API calls to the OpenGL hardware implementation on the guest OS .

Please correct me if I am wrong .

EDIT : Again, please correct me if wrong, the info here https://github.com/kjliew/qemu-3dfx describes how, in addition to OpenGL passthrough, you implemented Glide wrapping so that OpenGL or Glide applications running in a Windows 98 guest VM could take advantage of the host's OpenGL implementation.

Reply 9 of 15, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Yeah, I was right 😁. Warhammer Dark Omen is smooth & playable on M1 despite lacking hardware virtualization for x86.

Screen Shot 2021-05-21 at 9.53.25 PM.jpg
Filename
Screen Shot 2021-05-21 at 9.53.25 PM.jpg
File size
691.32 KiB
Views
600 views
File comment
Dark Omen on M1
File license
Fair use/fair dealing exception

Reply 11 of 15, by digger

User metadata
Rank Oldbie
Rank
Oldbie
kjliew wrote on 2021-03-11, 02:38:

I do anticipate that in future, non x86 hardware will be fast enough for QEMU to run 20 years old Windows games. 😉 It is probably doable now for this one on Apple M1 with a native build of QEMU running TCG, if we had working XQuartz/OpenGL to port qemu-3dfx over.

Is the Metal->MoltenVK->Zink stack in a good-enough state at this point to provide a proper OpenGL implementation in macOS on an M1-based Mac? Both MoltenVK and Zink are being extensively developed and are undergoing rapid improvements very quickly. If it doesn't work yet, perhaps it will soon?

Reply 12 of 15, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
gernumikus wrote on 2021-05-29, 20:11:

Have you tried Pcem? The game works fine even on a weak host (amd phenom x4 945). But this applies to Windows, I have not tested it on Linux.

Since you mentioned PCem, then I will say that PCem is always a joke, even for this over 20 years old game. You could probably try software rendering, but when 3D acceleration comes into picture, PCem's branded "freaking fast" fake 3Dfx voodoo software recompiler is an utter trash. I don't have to try it, someone from OCAU "Retro Let's Play" tried it and it was just as I described. If one ever play Win9x Direct3D games with PCem because of the fake "voodoo", then one may also just enable Microsoft reference RGB Direct3D renderer and play with that. The thread may get deleted without notice because truth were not supposed to be told for anything PCem related... 🤣. When someone once said ".... it will be OK on M1 ...." I just LMAO 😁

digger wrote on 2021-05-29, 20:53:

Is the Metal->MoltenVK->Zink stack in a good-enough state at this point to provide a proper OpenGL implementation in macOS on an M1-based Mac? Both MoltenVK and Zink are being extensively developed and are undergoing rapid improvements very quickly. If it doesn't work yet, perhaps it will soon?

XQuartz/GLX seems to have already provide OpenGL 2.1 (+ARB/EXT/APPLE extensions) on top of Metal, the native graphics APIs that M1 GPU accelerates. It is true that it won't be as great as what is available from Windows/Linux, but so far for games that work, I don't see OpenGL 2.1 being a limitation as of now. If Apple could realize cross architecture virtualization in the future, then OpenGL 2.1 could be seen as a limitation to play games on VM.

M1 is a great SoC, for TCG vs TCG in native code, it outshines any Intel/AMD x86 laptops and reaching almost the same level of performance of desktop-class Core i7 6700k/7700k, fanless, thin & light and ultraportable. However it is still a walled garden within Apple confined software ecosystem. It is yet unknown how well Zink, the OpenGL wrapper for Vulkan, could work outside of MESA. Zink has limited usefulness as of today as popular ARM SBCs (RPi4/RK3399) already support OpenGL desktop profile up to version 2.1. It is no doubt great for the future as non-Apple graphics APIs consolidated into Vulkan.

Perhaps we don't need all of this as WineD3D will support Vulkan natively for sure. All we need is another API pass-through with Vulkan.

Reply 13 of 15, by Bladeforce

User metadata
Rank Member
Rank
Member
kjliew wrote on 2021-05-30, 00:38:
gernumikus wrote on 2021-05-29, 20:11:

Have you tried Pcem? The game works fine even on a weak host (amd phenom x4 945). But this applies to Windows, I have not tested it on Linux.

Since you mentioned PCem, then I will say that PCem is always a joke, even for this over 20 years old game. You could probably try software rendering, but when 3D acceleration comes into picture, PCem's branded "freaking fast" fake 3Dfx voodoo software recompiler is an utter trash. I don't have to try it, someone from OCAU "Retro Let's Play" tried it and it was just as I described. If one ever play Win9x Direct3D games with PCem because of the fake "voodoo", then one may also just enable Microsoft reference RGB Direct3D renderer and play with that. The thread may get deleted without notice because truth were not supposed to be told for anything PCem related... 🤣. When someone once said ".... it will be OK on M1 ...." I just LMAO

The facts of the matter are this game runs very well in pcem no matter what your prejudices are against pcem

Last edited by Stiletto on 2021-06-01, 21:19. Edited 1 time in total.

Reply 14 of 15, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Bladeforce wrote on 2021-06-01, 16:49:

The facts of the matter are this game runs very well in pcem no matter what your prejudices are against pcem

Well, then good for you. You don't have to take my words, I didn't try the game on PCem, but you can check out
https://forums.overclockers.com.au/posts/18808093/
Someone tried it on Ryzen 3900X.

But wait til we get PCem fixed up and running on M1 with their ARM64 voodoo recompiler (which is still missing and still bug-ridden even for x86_64), then you will realize whether I was prejudiced or merely spoke out of truth.