Technical roundup

More efficient loading

Internally, the game is structured into stages, which in turn specify several waves of entities to spawn. After one wave’s enemy are defeated, the next one begins.

I previously constructed entities and loaded their resources for one wave at a time. This resulted in noticeable loading pauses during game play. Now each stage loads all it’s entities at the beginning.

Windows NT 3.51 support

Both the Win32 as well as the DOS ports now run on Windows NT 3.51. This was actually an unintended compatibility issue caused by my custom long file name layer that mistakenly flagged all NT versions as supporting LFNs. While NT 3.51 does support them, it only does so on NTFS volumes. Most importantly, there is no Joliet support for ISO9660 volumes.

I now test for LFN support on every open(), eliminating this kind of error completely.

Sound Blaster support

The DOS version now features a Sound Blaster audio driver. It supports everything from Sound Blaster 1.5 up until Sound Blaster 16 (and compatibles). It currently outputs at up to 44.1khz (depending on your model) 8-bit mono, though the game always goes for 22 khz. The driver could be easily extended to 16-bit and stereo, but I have no need for that right now.

Wait. A driver?

Yeah. What sounds crazy is actually pretty necessary. DOS just doesn’t feature any kind of audio support at all. While DOS, as an operating system, does feature hardware abstraction and a system for operating-system-integrated drivers, it doesn’t have a concept of audio at all.

So, to get a sound card to work, applications/games have to interface them directly. Since DOS does not implement any means of isolation or protection of system resources, you can easily do that. And that’s precisely what all games did.

Some used frameworks like Miles Sound System / Audio Interface Library, which are mostly a driver collection with a software mixer attached. I’ve chosen not to go that route for now.

Why Sound Blaster?

Easy: It’s pretty much the most widely used sound card in DOS machines. Of all supported models, most people will probably go for a Sound Blaster 16, which became kind of the gold standard in DOS gaming.

Why is that? The first Sound Blasters sold well and games were quick to utilize them. Since the drivers are, again, part of the application using them, competitors had a hard time establishing their (incompatible) cards. This lead to other cards being less successful, which again resulted in applications not supporting cards other than Sound Blaster (why invest the work when a card doesn’t have much market share?). Reverse chicken and egg!

This effect lessened over time, through third-party audio frameworks like the aforementioned Miles and software drivers emulating a Sound Blaster interface. The surefire way, however, to get sound out of your game was to use a Sound Blaster.

So…aren’t you doing the same thing?

Yes. At least for now. In the absence of a standardized audio interface for DOS, I’ve made whatever Sound Blaster does my “standard”.

After all, that’s kind of what is: The standard interface. Even if you aren’t rocking a Sound Blaster in your system, chances are the vendor of your card included some TSR to emulate a Sound Blaster using their hardware. Even Creative, the company behind Sound Blaster, included them in their later cards. Some Windows versions even to it for you! And if that’s not enough, there are modern projects like SBEMU that do the same for modern(-ish) chips. Most of these should work just fine (and I will tune things when they don’t).

I might implement more drivers in the future (cards like GUS were successful and awesome!), but decided not to do that for now. Maybe even use AIL?

Even more sound

As mentioned, I’ve also fixed the sound bug in SDL2. This manifested as every sound playing exactly once. Turns out it was just a simple off-by-one…

The software mixer, as used on Win32 and DOS, can now also integer resample between sampling rates. This is mostly for compatibility on DOS, since cards there differ in supported sampling rates. This introduces a performance hit though, so I hope to actually not use resampling in the final release.

Dual Shock controls

On a PSX equipped with a Dual Shock (or compatible…) controller, you can now use the left analog stick to smoothly aim your ship. Nothing much else to say about that. Try it out!

The next phase of development

As discussed in my previous post, I would like to call technical stuff “done” for now and advance the game to it’s next development phase: preview.

The preview phase, in my custom arbitrary parlance, focuses on getting the game itself mostly done and, most importantly, fun. I would like to implement a brief introduction, flesh out the first level and make it mostly complete. Things will shift a lot more towards game design topics. There are quite a bit of things I’d like to add to the game. Some already present things will probably get reworked (for example, I’m not too sure about the current control scheme).

This will be quite challenging for me, as my background is actually more in low-level technical stuff. It’ll be exciting!