VOGONS


First post, by thp

User metadata
Rank Member
Rank
Member

A game jam game from last weekend turned into a DOS/Windows 95 retro game.

Edit 2021-10-15: Final build Dzzee 1.2 available here

Screenshot 2021-10-15 at 20.21.54.png
Filename
Screenshot 2021-10-15 at 20.21.54.png
File size
181.52 KiB
Views
3361 views
File comment
Gameplay
File license
CC-BY-4.0

Posting here in the video forum, since it might be fun to try different video modes and acceleration modes and benchmark different systems. Also, the 3Dfx mode was developed/tested using PCem and DOSBox, so if anybody could give it a spin on a real Voodoo Graphics, that'd be great (I don't have a 3Dfx card anymore). Obviously, no warranty that it won't destroy your monitor or graphics card, but so far I've successfully tested the builds in DOSBox, PCem, Windows 95B running in PCem, Windows 98 SE on real hardware with an ATI 3D Rage Pro and a GeForce FX 5200. Feel free to post videos, FPS numbers (with your setup) and photos of the game running.

Dzzee 1.0 -- A well-rounded game that makes you dizzy [DOS/Win95 RETRO BUILDS] […]
Show full quote

Dzzee 1.0 -- A well-rounded game that makes you dizzy [DOS/Win95 RETRO BUILDS]

Here comes another little retro toy: Dzzee. Control the white rectangle
with the UP and DOWN arrow keys. Stay on the lanes, avoid the gaps. Survive
longest and retain health points for high score.

This retro build of the game comes in 3 variants:

  • DZZEEDOS.EXE -- Built using DJGPP (CWSDPMI.EXE), OSMesa (software OpenGL), VGA and VESA (up to 800x600) modes, 8-bit Sound Blaster
  • DZZE3DFX.EXE -- Built using Open Watcom (DOS4GW.EXE), needs a 3Dfx Voodoo Graphics board, renders using Glide 2 for DOS, Sound Blaster
  • DZZEEW95.EXE -- Built using Open Watcom, 32-bit Windows executable, should work on any Windows from 95B to Windows 10, 8-bit WaveOut output; configurable via DZZEE.INI (screen resolution, fullscreen mode, audio output disabling in case it fails)

All builds show the current FPS (average, calculated every second) in the top right corner in case you want to compare frame rates with different builds (e.g. 3Dfx vs. OSMesa software rendering).

For the DOS build, in 256-color VGA mode, you can toggle dithering with "D", temporal dithering with "T" (only when dithering is enabled) and toggle between widescreen "W" (unscaled DOSBox or widescreen monitor) and 4:3 mode "H" (scaled DOSBox or 4:3 monitor with non-square pixels). For the VESA modes, 32bpp is used (no dithering necessary), and all screen modes are 4:3, so no non-square pixels.

If you enjoy this game, and haven't seen Loonies 8192, check it out - that one focuses more on different DOS audio options (Adlib/OPL-2, MPU-401, SB MIDI, PC Speaker, CD Audio).

Attachments

  • Filename
    DZZEE10R.ZIP
    File size
    1.28 MiB
    Downloads
    131 downloads
    File comment
    Dzzee 1.0 Retro Release
    File license
    Fair use/fair dealing exception
Last edited by thp on 2021-10-15, 18:22. Edited 4 times in total.

Reply 1 of 36, by Gmlb256

User metadata
Rank l33t
Rank
l33t

Nice arcade game! Tested it on a K6-2+/450 computer with write combining enabled and got around 27-29 FPS average in-game on 320x240 32bpp in DOS. I got some feedback:

  • The 3Dfx version didn't work for me and froze the computer with a black screen with a single Voodoo2 12MB card.
  • Video modes above 320x240 32bpp are much slower in the non-3Dfx version of DOS. I believe that on slower CPUs it would have a lower FPS in average at 320x240.
  • Could you set the black color for the background? It would look much better.

VIA C3 Nehemiah 1.2A @ 1.46 GHz | ASUS P2-99 | 256 MB PC133 SDRAM | GeForce3 Ti 200 64 MB | Voodoo2 12 MB | SBLive! | AWE64 | SBPro2 | GUS

Reply 2 of 36, by thp

User metadata
Rank Member
Rank
Member
Gmlb256 wrote on 2021-10-02, 22:21:

Nice arcade game! Tested it on a K6-2+/450 computer with write combining enabled and got around 27-29 FPS average in-game on 320x240 32bpp in DOS.

Thanks for testing, glad you like it 😀

Gmlb256 wrote on 2021-10-02, 22:21:

The 3Dfx version didn't work for me and froze the computer with a black screen with a single Voodoo2 12MB card.

It might be that the statically linked Glide 2 kind of requires a Voodoo 1. Have you tried setting environment variables similar to what made the Tomb Raider 1 3Dfx DOS version work? See this posting here: Tomb Raider 1 - Voodoo 2 (SST_GRXCLK, SST_FT_CLK_DEL, ...)

Gmlb256 wrote on 2021-10-02, 22:21:

Video modes above 320x240 32bpp are much slower in the non-3Dfx version of DOS. I believe that on slower CPUs it would have a lower FPS in average at 320x240.

Yes, the non-3Dfx modes all use software rendering, so higher resolutions would need a beefier CPU. Not sure if writing a simpler (flat shaded) rasteriser would give a speedup compared to OSMesa, maybe.

Gmlb256 wrote on 2021-10-02, 22:21:

Could you set the black color for the background? It would look much better.

Yes, this could be done. I mostly chose a off-black color so that I could test if my screen clearing code did the right thing (and it wasn't just luck that it was cleared in black).

Reply 3 of 36, by Gmlb256

User metadata
Rank l33t
Rank
l33t
thp wrote on 2021-10-03, 19:59:

It might be that the statically linked Glide 2 kind of requires a Voodoo 1. Have you tried setting environment variables similar to what made the Tomb Raider 1 3Dfx DOS version work? See this posting here: Tomb Raider 1 - Voodoo 2 (SST_GRXCLK, SST_FT_CLK_DEL, ...)

I had set these environment variables thru V2-AUTO.INF that comes with the drivers. The original 3Dfx Tomb Raider executable which was meant for Voodoo Graphics works fine with these environment variables but not on this game.

VIA C3 Nehemiah 1.2A @ 1.46 GHz | ASUS P2-99 | 256 MB PC133 SDRAM | GeForce3 Ti 200 64 MB | Voodoo2 12 MB | SBLive! | AWE64 | SBPro2 | GUS

Reply 5 of 36, by Gmlb256

User metadata
Rank l33t
Rank
l33t
Yoghoo wrote on 2021-10-03, 20:34:

What are the system requirements? Tried it with a 486/66 and got 1 fps. Tried also with univbe but couldn't get the vesa modes to run.

I've feared that it would run much slower on such CPU considering the FPS I got, UniVBE won't improve much on that situation. Also certain older video cards doesn't support 32bpp btw.

VIA C3 Nehemiah 1.2A @ 1.46 GHz | ASUS P2-99 | 256 MB PC133 SDRAM | GeForce3 Ti 200 64 MB | Voodoo2 12 MB | SBLive! | AWE64 | SBPro2 | GUS

Reply 6 of 36, by Pierre32

User metadata
Rank Oldbie
Rank
Oldbie

Looks cool, but a few issues here. System is a Pentium 200 (non MMX) with an ARK2000 video card and a Voodoo 1, running DOS 6.22.

Running DZZEEDOS.EXE, the only mode that words on my card is mode 1 (13h / VGA 256). Unfortunately this is a little too slow to be playable on my system. Tried UniVBE to no effect.

Running DZZE3DFX.EXE I get the the 3DFX splash, then the game halts here:

dzzee 3dfx crash.jpg
Filename
dzzee 3dfx crash.jpg
File size
90.67 KiB
Views
3920 views
File license
Public domain

ps. Looking at your Twitter account, I'm sure I've enjoyed some of your work before. But I can't quite remember and it's torturing me 😁 Perhaps from my days using gPodder.

Reply 8 of 36, by thp

User metadata
Rank Member
Rank
Member

Weird that the 3Dfx builds work in PCem and DOSBox for me, but that's why it's important to test on real hardware 😀

My first hunch was that it could be related to the Sound Blaster code I'm using (smix). So there's "nosb" builds attached to this post to try. But then I had a look through the code what else could be wrong, and my ISR for the timer didn't properly acknowledge the interrupt (outp(0x20, 0x20);), but this is now added (the "pitfix" builds). The timer interrupt is initialized after grSstOpen() is called, which might explain why it locks up after the 3Dfx logo (and with any luck, Gmlb256 could have just had the splash screen disabled via environment variables, seeing that it was always a black screen there).

Before:

void
interrupt NewInt1C(void)
{
int1Ccnt++;
if (int1Ccnt % 55 == 0) {
pOldInt1C();
}
}

After:

void
interrupt NewInt1C(void)
{
int1Ccnt++;
if (int1Ccnt % 55 == 0) {
pOldInt1C();
} else {
outp(0x20, 0x20);
}
}

So maybe we have better luck with any of those builds? As for the low performance on slower CPUs, that's kind of expected for software rendering, although of course the rasterization could be optimized, but let's see (e.g. directly rasterize into an 8-bit paletted buffer and not rasterize - with blending - into a 32-bit buffer and then either palletize or even dither...).

If the "pitfix" builds work (with/without Sound Blaster), then this was the bug, if only the "nosb" builds work, then it might be related to the smix library, and if none of them work, I'll have to dig deeper...

Attachments

  • Filename
    dzze3dfx-pitfix.exe
    File size
    166.44 KiB
    Downloads
    73 downloads
    File comment
    Acknowledge timer interrupt
    File license
    Fair use/fair dealing exception
  • Filename
    dzze3dfx-nosb-pitfix.exe
    File size
    162.44 KiB
    Downloads
    74 downloads
    File comment
    No Sound Blaster code, acknowledge timer interrupt
    File license
    Fair use/fair dealing exception
  • Filename
    dzze3dfx-nosb.exe
    File size
    162.44 KiB
    Downloads
    76 downloads
    File comment
    No Sound Blaster code
    File license
    Fair use/fair dealing exception

Reply 9 of 36, by Gmlb256

User metadata
Rank l33t
Rank
l33t
thp wrote on 2021-10-04, 17:23:

and with any luck, Gmlb256 could have just had the splash screen disabled via environment variables, seeing that it was always a black screen there

You guessed it right that I have disabled the 3Dfx splash screen by setting FX_GLIDE_NO_SPLASH to 1, I just like to get the game started already as with modern video cards. 😁

Anyway, I downloaded the three EXEs and they still doesn't work on real hardware. However with the "nosb" executables the screen finally appeared with some title letters like the others reported and FPS stayed at 0.

VIA C3 Nehemiah 1.2A @ 1.46 GHz | ASUS P2-99 | 256 MB PC133 SDRAM | GeForce3 Ti 200 64 MB | Voodoo2 12 MB | SBLive! | AWE64 | SBPro2 | GUS

Reply 10 of 36, by thp

User metadata
Rank Member
Rank
Member

Ok, here's one last try. This removes the SB code and the interrupt 1C (timer interrupt) handling, so has a fixed time step (10 ms per frame hardcoded), and no FPS counter (as this relies on measuring time). Input handling is done via kbhit() and getch(), so no fancy keyboard interrupt hooking like the dzzeedos.exe. This is now literally just that for initialization:

    GrHwConfiguration hwconfig;
GrScreenResolution_t screenRes = GR_RESOLUTION_640x480;

grGlideInit();

if (!grSstQueryHardware(&hwconfig)) {
fprintf(stderr, "grQuery failed!");
grGlideShutdown();
exit(-1);
}

grSstSelect(0);

if (!grSstOpen(screenRes,
GR_REFRESH_60Hz,
GR_COLORFORMAT_ABGR,
GR_ORIGIN_UPPER_LEFT,
GR_SMOOTHING_ENABLE,
2)) {
fprintf(stderr, "grOpen failed!");
grGlideShutdown();
exit(-1);
}

And to swap the buffers after every frame:

    grBufferSwap(1);

And at exit (Escape key or "Q"):

    grGlideShutdown();

Attachments

  • Filename
    dzze3dfx-nosb-noint1c.exe
    File size
    162.1 KiB
    Downloads
    71 downloads
    File comment
    DOS Glide version with just Glide calls + kbhit + getch
    File license
    Fair use/fair dealing exception

Reply 11 of 36, by Gmlb256

User metadata
Rank l33t
Rank
l33t
thp wrote on 2021-10-05, 05:24:
Ok, here's one last try. This removes the SB code and the interrupt 1C (timer interrupt) handling, so has a fixed time step (10 […]
Show full quote

Ok, here's one last try. This removes the SB code and the interrupt 1C (timer interrupt) handling, so has a fixed time step (10 ms per frame hardcoded), and no FPS counter (as this relies on measuring time). Input handling is done via kbhit() and getch(), so no fancy keyboard interrupt hooking like the dzzeedos.exe. This is now literally just that for initialization:

    GrHwConfiguration hwconfig;
GrScreenResolution_t screenRes = GR_RESOLUTION_640x480;

grGlideInit();

if (!grSstQueryHardware(&hwconfig)) {
fprintf(stderr, "grQuery failed!");
grGlideShutdown();
exit(-1);
}

grSstSelect(0);

if (!grSstOpen(screenRes,
GR_REFRESH_60Hz,
GR_COLORFORMAT_ABGR,
GR_ORIGIN_UPPER_LEFT,
GR_SMOOTHING_ENABLE,
2)) {
fprintf(stderr, "grOpen failed!");
grGlideShutdown();
exit(-1);
}

And to swap the buffers after every frame:

    grBufferSwap(1);

And at exit (Escape key or "Q"):

    grGlideShutdown();

Nope, still not working. 🙁

VIA C3 Nehemiah 1.2A @ 1.46 GHz | ASUS P2-99 | 256 MB PC133 SDRAM | GeForce3 Ti 200 64 MB | Voodoo2 12 MB | SBLive! | AWE64 | SBPro2 | GUS

Reply 12 of 36, by thp

User metadata
Rank Member
Rank
Member

Too bad, but thanks for testing! Instead of spending time on DOS Glide further, I looked into making the 320x200 VGA mode faster by implementing a small rasterizer of my own instead of relying on OSMesa. A quick test in DOSBox gets me ~ 3x the performance in the title screen, in-game it can also be much faster depending on how much content is on-screen.

Attachments

  • Filename
    dzzesftw.exe
    File size
    108.42 KiB
    Downloads
    80 downloads
    File comment
    VGA 320x200 software rasterizer
    File license
    Fair use/fair dealing exception

Reply 13 of 36, by Gmlb256

User metadata
Rank l33t
Rank
l33t
thp wrote on 2021-10-05, 18:32:

Too bad, but thanks for testing! Instead of spending time on DOS Glide further, I looked into making the 320x200 VGA mode faster by implementing a small rasterizer of my own instead of relying on OSMesa. A quick test in DOSBox gets me ~ 3x the performance in the title screen, in-game it can also be much faster depending on how much content is on-screen.

That's much better than the OSMesa renderer. Also nice that you use a proper black background for this executable! 😀

Got around 171-191 FPS this time, however the circles looks less 3D than it was originally and no transparency effect around the circle hilight and title screen letters.

VIA C3 Nehemiah 1.2A @ 1.46 GHz | ASUS P2-99 | 256 MB PC133 SDRAM | GeForce3 Ti 200 64 MB | Voodoo2 12 MB | SBLive! | AWE64 | SBPro2 | GUS

Reply 14 of 36, by thp

User metadata
Rank Member
Rank
Member

Here's another stab at the Glide API, this time using Glide 2.43 and Win32, compiled using OpenWatcom.

Attachments

  • Filename
    dzew3dfx.exe
    File size
    60.5 KiB
    Downloads
    80 downloads
    File comment
    3Dfx Glide build for Windows
    File license
    Fair use/fair dealing exception

Reply 15 of 36, by Gmlb256

User metadata
Rank l33t
Rank
l33t
thp wrote on 2021-10-08, 16:25:

Here's another stab at the Glide API, this time using Glide 2.43 and Win32, compiled using OpenWatcom.

This one finally did the trick for 3Dfx! 👍

Got a very consistent 60 FPS with vsync enabled and 205-220 FPS without it. If only the 3Dfx version of DOS could work using the same Glide library (which forces the user to find a suitable GLIDE2X.OVL file) that would be great.

VIA C3 Nehemiah 1.2A @ 1.46 GHz | ASUS P2-99 | 256 MB PC133 SDRAM | GeForce3 Ti 200 64 MB | Voodoo2 12 MB | SBLive! | AWE64 | SBPro2 | GUS

Reply 16 of 36, by thp

User metadata
Rank Member
Rank
Member
Gmlb256 wrote on 2021-10-08, 16:48:

This one finally did the trick for 3Dfx! 👍

Got a very consistent 60 FPS with vsync enabled and 205-220 FPS without it. If only the 3Dfx version of DOS could work using the same Glide library (which forces the user to find a suitable GLIDE2X.OVL file) that would be great.

Neat 😀 While "porting" the Glide 2.11 DOS code for Win32 was just a single function call change (grSstOpen vs grSstWinOpen) as far as glide2x is concerned, there are some linking issues with the DOS libraries. There's also little documentation on how the (dynamic?) linking with the OVL file works, and the Glide 2.43 SDK contains two sets of libraries in folder "Register" and "Stack" (that's probably the calling convention used? passing parameters on registers vs on stack). Maybe I'll figure it out... Until then, I'll roll another release with the findings from the last week (thanks again for testing 😀.

Reply 17 of 36, by thp

User metadata
Rank Member
Rank
Member

A new release based on feedback from here, still fits on a floppy (as ZIP file, anyway):

Version 1.1 (2021-10-08)
------------------------

- New 3Dfx build using Glide 2.43, for Win32 (using OpenWatcom)
- New software rasterizer for DOS with 2 modes
- Frame rate calculation rate is increased (every 200 ms)
- Replace my buggy waveOut code with the nifty Win32 PlaySound() API
- Removed the non-working DOS Glide build based on the Glide 2.11 SDK
- Small tweaks and customizations to avoid overdraw in the rasterizer

If I ever get around to figuring out the DOS Glide linking, the DOS Glide build will return, but for now, no point in shipping broken code 😀

Attachments

  • Filename
    DZZEE11R.ZIP
    File size
    1.35 MiB
    Downloads
    92 downloads
    File comment
    Dzzee 1.1 retro builds (DOS, Win32 OpenGL and Glide)
    File license
    Fair use/fair dealing exception

Reply 18 of 36, by zyzzle

User metadata
Rank Member
Rank
Member

New version (software renderer) is great! About 1/10th the size of the openmesa version, compresses to 95 kb, and runs much faster -- higher fps. Quick question: Is the source code available? I want to give myself more lives. 8 just isn't enough. Tried looking for any obvious offsets in the binary, but couldn't find the "lives" initiation bytes (0x08 0x00), or something like that! The going gets so frenetic.

Last edited by Stiletto on 2021-10-11, 22:08. Edited 1 time in total.

Reply 19 of 36, by thp

User metadata
Rank Member
Rank
Member
zyzzle wrote on 2021-10-10, 23:36:

New version (software renderer) is great! About 1/10th the size of the openmesa version, compresses to 95 kb, and runs much faster -- higher fps. Quick question: Is the source code available? I want to give myself more lives. 8 just isn't enough. Tried looking for any obvious offsets in the binary, but couldn't find the "lives" initiation bytes (0x08 0x00), or something like that! The going gets so frenetic.

The EXE is packed using UPX, if you unpack it it should be easier to disassemble/hex-edit.

Last edited by Stiletto on 2021-10-11, 22:08. Edited 1 time in total.