That looks really cool. I'd need more help for the next steps - a game loop that runs the game at a consistent speed on different processors, and a sound library.
As I recall, at least in mode 13h on VGA cards you can poll a register for vsync status, so a simple way is to just busywait on that.
Alternatively you can install your own timer interrupt for a higher precision counter you can monitor.
Typically we wrote directly to the sound hardware back then, but if you're looking to have all that complexity abstracted (it isn't really that bad, there's good documentation out there and these are pretty simple devices), you could use the old DOS version of the Allegro library.
In DJGPP, you can use uclock() to get a sort of high precision timer, at least much higher precision than the 18.2Hz timer usually employed in DOS apps.
As for audio, I'm afraid I have no suggestions. My memory is blurry, likely because audio programming in DOS was very not good.
There’s a list with some links to source for sound libraries here:
https://www.vogons.org/viewtopic.php?t=54318
Personally I’ve used Midas for an MS-DOS game project for sound effects. It’s also available for Windows so good for projects that are cross-platform. For demoscene productions I’ve used a number of different mod players (most recently IMS).
What's wrong with using VSync? 320x200 ran at 70Hz on every machine out there.
You don't need a sound library. You just need to know how to talk to a SoundBlaster. Virtually everything was compatible, so you were good to go. A library is only adding Points Of Failure. Programming a sfx card was way easier compared to nowadays.
> Programming a sfx card was way easier compared to nowadays.
This. Replace "sfx card" with almost anything except new ones. The list would include: ios/android app, web site, etc. There's a feeling that we keep stacking an unneeded complexity in layers.
A feeling? ... Ever since the OOP nonsense started decades ago, adding more and more bureaucracy to programming has been the norm. Nowadays we live in a world where programmers suck, because they've never learned to actually program the computer! Instead they've learned how to use programming languages, aka dealing with all the unnecessary bullshit I call bureaucracy!
Once you start piling Bureaucracy onto something , more and more will get stacked on top of it.
Cool. What about a modern setup for VB/VBA? The last time I had to define a custom statistical function for Excel and had limited time I felt handicapped and annoyed by how dumb the code editor (still the same as in VB5) is.
Depending on your requirement, it might be better to create custom functions in Javascript [1]. One difference is that the functions are tied to the Excel installation, and not on the workbook like VBA.
This comes in handy. Yesterday I ordered a book that covers ASM/C demo effects from the 90th. It is called "PC Underground", available from the second hand book mark.
Was amused to see in the first review the comment that it was 'a bit disorganized'.
This reminded me of the 'door stop' books of the 90s, those great thick things that weighed about 3 lbs. In the early days they tended to be worth every penny, but toward the end of the decade the publishers seemed to have gotten some kind of gold-rush mentality, because while there was a sudden proliferation of these hefty tomes, the quality definitely became hit or miss, and it became work to find the gems.
Door stop books. Heh heh. Michael Abrash’s “Graphics Programming Black Book”[0] comes to mind. That thing weighs a ton. (I also didn’t realize how pricey it has gotten in the used market! Yikes!)
Yes. I owned it during the 90th. The only problem is, that it is in German. Over at archive.org I only found torrent images for the enclosed CD-ROM, which features source code as well as a couple of great demos from Iguana, Dust, Surprise and others.
Yay! One of the unexpected benefits of releasing a lot of source code for our work back then, is that we can now find it again on the internet [1] - most of it would have been (and was) lost otherwise :)
Write to the Archive.org folks, perhaps? These two items are clearly both up there somewhere, and they need to be linked together as being part of a single release. The issue of books/publications with enclosed media (floppies, CD) is also quite general, well beyond that one case.
Super strange to run into this - I've been using Dosbox Staging with MASM611 to do some MASM x86 assembly.
I really want to understand the original packet driver assembly code; once I understand it, I can write a little packet driver (just as a learning exercise).
I love when stuff like this (something very related) gets posted. Sheesh, HN is great.
DJGPP was great, but if you want to drop to assembly for performance reasons, NASM was the way to go. AT&T syntax on Intel was a poor choice IMO, and the pain of juggling inline assembly register requirements was just not worth it.
LLVM devs are apparently still working on adding proper i386 support https://github.com/llvm/llvm-project/issues/58470 but if that were to be addressed, we might even be able to use clang or rustc to build proper DPMI-based code for DOS. That would then leave 8086 real mode and 80286 protected mode as the next steps - admittedly quite a bit harder, given the need to deal with the complexity of segmented memory and the related issue of "code models".
Some people have been maintaining a GCC with 16-bit DOS support for a few years now. It started as near pointer only (so only tiny/small memory models) but now has far pointers and some memory model support. I haven't really used it in anger. https://gitlab.com/tkchia/build-ia16/-/releases
If you want C++ you have to build a cross-compiler from source on a modern platform; they supply DJGPP binaries that'll compile C to 16-bit.
