Thanks to some help in the OpenWatcom Discord, I got the DOS Glide build to build with 2.43 (needed to pass in the NOCASEEXACT option to the Watcom linker, as the glide2x.lib symbols are all uppercase), if anybody wants to give it a try (needs glide2x.ovl, either in the system directories or in the same folder as the exe).
Thanks to some help in the OpenWatcom Discord, I got the DOS Glide build to build with 2.43 (needed to pass in the NOCASEEXACT option to the Watcom linker, as the glide2x.lib symbols are all uppercase), if anybody wants to give it a try (needs glide2x.ovl, either in the system directories or in the same folder as the exe).
This 3Dfx DOS versions works without the freezing the computer, however the sounds are a bit distorted.
Here's the final build. As the behavior of real hardware vs Glide Wrappers (PCem/DOSBox-X/nGlide) was different, I actually got myself a Voodoo Graphics board this week to test it myself, and it works at 60 FPS on my K6-II 500 MHz.
Download below.
Screenshots:
The attachment Screenshot 2021-10-15 at 20.13.58.png is no longer available
The attachment Screenshot 2021-10-15 at 20.13.43.png is no longer available
The attachment Screenshot 2021-10-15 at 20.13.32.png is no longer available
The attachment Screenshot 2021-10-15 at 20.13.20.png is no longer available
Some pitfalls / learnings from the Glide porting:
One can poll grBufferNumPending() and avoid overfilling the FIFO (wait until there are no pending buffers)
Vertices are snapped to a 0.0625f pixel grid, the CPU rounding could be slightly different than what the graphics chip does and can cause hangs/delays (I do it the naive way and multiply it by 16, convert to long, then convert back to float and divide by 16, which the Glide Manual says exactly not to do because of performance reasons, but hey, works well enough in my tests)
OpenWatcom needs the NOCASEEXACT linker option to link against glide2x.lib from the Glide DOS SDK
This new build adds a 16-color EGA version of the software rasteriser (EGA vs VGA is detected automatically, use "ega" (lowercase, without the quotes) to force the 16-color mode on VGA boards. Also, a super weird EGA/VGA text mode version for really old computers (16 colors, 80x43 "resolution"). And zyzzle gets 128 lives by just passing their username as first command line parameter.
That's it: The Glide version works, and the VGA software rasterizer turned out pretty nice, and I learned a lot about Glide, OpenWatcom, DOS overlays, OpenGL on Windows 95 and new Win32 API features. Also about EGA's planar mode, detecting CGA vs EGA vs VGA and implementing a crappy 16-color text mode rasterizer. Also, 8-bit Sound Blaster audio output under DOS. A small multi-weekend project coming to a close 😀
1Version 1.2 (2021-10-15) 2------------------------ 3 4 - Glide port: Use grBufferNumPending() and vertex snapping to 0.0625f 5 - Reintroduce the DOS 3Dfx port using Glide 2.43 and wlink's NOCASEEXACT 6 - Allow pressing "SPACE" only after the intro has finished playing 7 - Win32/OpenGL: Add logging support, make bpp/depth/stencil configurable 8 - Allow ports to customize the font scaling (fixes text alignment) 9 - Add cheat command line argument to have more lives (name of requester) 10 - 16-color EGA mode support for DZZESFTW.EXE (force using "ega" option) 11 - New "mode 4350" build (DZZE4350.EXE) without sound, using text mode
Great that you ironed out the problems and learned something new with Glide! 😀
I know that this is final build, but I've noticed that the sound quality with the DOS 3Dfx version is not on par with the other ones having some annoying clicks when playing samples. Besides this, could be possible to add 800x600 and 1024x768 (for those using SLI on Voodoo2 cards) resolutions on the 3Dfx version?
I know that this is final build, but I've noticed that the sound quality with the DOS 3Dfx version is not on par with the other ones having some annoying clicks when playing samples. Besides this, could be possible to add 800x600 and 1024x768 (for those using SLI on Voodoo2 cards) resolutions on the 3Dfx version?
About the sound quality, I unfortunately don't have time to dig into, it might be related to the library I'm using (SMIXW v1.30 on DOS) or a signed/unsigned 8-bit WAV mismatch.
About the resolutions: Sure, why not. Attached the two Glide builds (DOS/Windows) that now accept as command-line arguments either "1024x768", "800x600, "640x480" or "320x240" (defaulting to 640x480). You can either type these in the command line or create a batch file:
In related news, homebrew ports to 3DS and Vita as well as a "modern" Windows version utilizing OpenGL and SDL2 are now available on Itch.io too: https://thp.itch.io/dzzee (the "retro" build is the same as the version available here).
thpwrote on 2021-10-17, 15:31:About the resolutions: Sure, why not. Attached the two Glide builds (DOS/Windows) that now accept as command-line arguments eith […] Show full quote
About the resolutions: Sure, why not. Attached the two Glide builds (DOS/Windows) that now accept as command-line arguments either "1024x768", "800x600, "640x480" or "320x240" (defaulting to 640x480). You can either type these in the command line or create a batch file:
As the behavior of real hardware vs Glide Wrappers (PCem/DOSBox-X/nGlide) was different
Cool project!
Ostensibly speaking as a project manager for the old OpenGlide Glide wrapper, and having communicated with Glidos (OpenGlide), Dege (dgVoodoo2 and ye olde dgVoodoo), and Zeus (nGlide) frequently in the past, I am sure we'd all be interested in what can be done to bring things in line with actual hardware. (Also, sounds like you didn't try Dege's dgVoodoo2.)
PCem is, BTW, a lower-level emulation of Voodoo hardware than an API wrapper. It's intended to simulate the real silicon.
DOSBox-X, I believe, offers both a lower-level Voodoo emulation, or an API Glide wrapper, as options. When using the wrapper, you should be able to swap out the one it comes with (probably OpenGlide) with nGlide or dgVoodoo2.
Someday you should be able to obtain a similar to PCem experience using MAME (first to create a low level Voodoo Graphics/Voodoo2/etc. emulation), but its emulation of PCI-bus PC hardware is still spotty.
"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen
Ostensibly speaking as a project manager for the old OpenGlide Glide wrapper, and having communicated with Glidos (OpenGlide), Dege (dgVoodoo2 and ye olde dgVoodoo), and Zeus (nGlide) frequently in the past, I am sure we'd all be interested in what can be done to bring things in line with actual hardware. (Also, sounds like you didn't try Dege's dgVoodoo2.)
Since for the last version I made that made it work, I did two things at once, I'm not sure which one made it work (it might be that both, or just one of them, or neither of them, caused the issue to go away, I didn't bisect it further):
Vertex snapping (as described in the "Floating Point Vertex Snapping and Area Calculations" section in the Glide 2.2 Programming Guide)
Poll grBufferNumPending() -- in case it overfills the FIFO
If it was just the vertex snapping, it can probably be reproduced by using a 16-bit fixed-point (12.4) bits representation for the emulated hardware part (FBI), from the Glide docs:
A potential inconsistency may arise between Glide ́s and the Voodoo Graphics hardware ́s perception of area and vertex values when Glide ́s floating point values change upon conversion to the hardware ́s fixed point <12.4> representation
If it was the overfilling of the FIFO, limiting the FIFO is probably one option, but then everything has to be cycle-accurate including the PCI bus, and the issue might of course only happen depending on how fast the CPU feeds the FIFO, so might not have been visible on era-accurate pairings of CPUs and Voodoos.
The vertex snapping is something that I'd consider "good" to have for accuracy, since it can affect the visual output (if you want to reproduce what the SST-1 does pixel perfect). The FIFO overfilling is something that might be related to other components, and apart from "developer mode" (where you want to be bug-for-bug compatible to original hardware), it's good that the Glide wrappers don't lock up if the FIFO becomes full.
As for trying different wrappers, during development I am using Linux and DOSBox-X was readily available, PCem easy to build from source and nGlide worked fine in Wine, so didn't go for testing with all wrappers (especially since there's an OpenGL 1.1 build for anything non-Voodoo). One more fun thing to try would be to see how to reduce the OpenGL API usage to make it compatible with the MiniGL driver (I'm using vertex arrays from OpenGL 1.1, but that could be "backported" to glBegin()/glEnd() which seems to be what GLQuake has been using), or if the full OpenGL ICD that was released for Voodoo Graphics eventually actually did support the OpenGL 1.1 build properly.
And zyzzle gets 128 lives by just passing their username as first command line parameter.
Wow, thanks for all that you do! And, new versions are GREAT! 16-color EGA version works well, and is a really neat retro touch. Now, I'll get really dizzy with so many lives...
I'm slightly confused, the game is now sold from the author's page at $5.00: https://thp.itch.io/dzzee
Are the older free downloads still legit?
I don't know, all the files that thp uploaded here are still available at the time of this writing including the version 1.2.0 for Retro PCs (as DZZEE12R or 1.2, just one day prior the date displayed on the itch.io site).
I'm slightly confused, the game is now sold from the author's page at $5.00: https://thp.itch.io/dzzee
Are the older free downloads still legit?
The itch.io build gets you a modern Windows build (32- and 64-bit), 3DS and Vita versions as well as the retro (DOS, Windows Glide) version, and any updates the game might receive in the future, plus a warm fuzzy feeling of supporting retro game development.
Only the DOS, Windows Glide (retro) build is also available here as a thanks for Vogons members testing and giving feedback on the game during its development -- feel free to share the retro DOS build available here as "shareware". Please don't share the modern Windows build and 3DS and Vita versions of the game. Thanks!
Only the DOS, Windows Glide (retro) build is also available here as a thanks for Vogons members testing and giving feedback on the game during its development -- feel free to share the retro DOS build available here as "shareware". Please don't share the modern Windows build and 3DS and Vita versions of the game. Thanks!
To finish off the porting frenzy, PS1, PS2, GameCube and Wii ports are now also available (and the DOS/Win9x port is now accessible on Itch.io as "Demo" - i.e. free - just like here on Vogons).
Period-correct PC hardware (1994) - like a good 486 or even a new Pentium were definitely faster than the PS1 for those tasks, and one can feel it comparing the PS1 port (with hardware accelerated rendering, but floating point emulated in software, because I didn't bother to go fixed point) to the DOS software rasterizer port -- and adding a Voodoo 1 (although introduced only in October 1996) made it silky smooth 60 FPS without much effort at all.
There's two new ports available, the gameplay is still the same.
One is for macOS >= 10.14.6 (both Intel and Apple Silicon, aka x86_64 and arm64) and probably not interesting to most retro enthusiasts -- yet?
The other one is a Win32 build (compatible from Win9x/NT4 onwards all the way to Windows 11 - not all renderers will work on NT4, though, but most will still run fine in Windows 11 on ARM (tested in Parallels on Apple Silicon), which supports running 32-bit x86 binaries through binary translation, and still has compatibility for those ancient Direct3D versions) with the following choice of renderer (the Direct3D renderers are separate implementations targeting different API levels):
GDI (8-bit software rasterizer)
DirectDraw (8-bit software rasterizer)
Direct3D 3
Direct3D 5
Direct3D 7
Direct3D 8
3dfx Glide 2.x
OpenGL 1.1
The 3dfx Glide renderer should work on real hardware, but also works with e.g. nGlide.
Tested the old versions in VMs, DOSBox-X with Voodoo emulation and different Win98SE/WinXP machines using a Radeon 9250, Geforce4 MX440 and a S3 UniChrome Pro IGP. Haven't gotten around to test it with an ATI Rage Pro that's probably more limited and might work well only with older Direct3D versions, but should work with at least some APIs on those old cards.
