beastlike wrote:

As fun as it would be to write something from scratch, having some modern advances like Box2d would be super convenient for physics / collision detection / callback/delegates-based coding that makes game programming a lot easier.

From the OP:
"new PC game for old hardware"
...
"(286, 386, 486? EGA or VGA? Real mode or protected mode? PCM or FM effects? MOD or OPL3 music?)"

That pretty much leaves out any pre-fab engines and libraries, because they're all way too slow/bloated and/or target different OSes and hardware.
I mean, Allegro in itself is pretty much out of the question already, I would think.

beastlike wrote:

If you'd ever actually DONE that kind of programming back in the day, you'd cringe at the idea of doing it again

I would think that this is the actual challenge. No point in using crappy libraries like Allegro and Box2D on modern OSes and hardware. That's just boring everyday code, which every monkey can do.
Exploring the limits of old machines, that's what it's all about. In the early days, many games were developed from graphical tricks and things that the developers discovered while trying to find ways to do graphics at all. There's a lot of trickery and optical illusion going on just to get a smooth gaming experience on your screen. That's the whole oldskool spirit.

Perhaps - an earlier commenter pointed to an older version of Allegro that supported DOS - but as far as the physics you get out of Box2D, to me it'd be cool to have a DOS game that had realistic physics.

Even if you did the graphics yourself, which now i'm sure you would based on your work on the wordpress site. Very nice by the way.

beastlike wrote:

Perhaps - an earlier commenter pointed to an older version of Allegro that supported DOS - but as far as the physics you get out of Box2D, to me it'd be cool to have a DOS game that had realistic physics.

I think you can only have one or the other. Box2D seems like a very generic, modern physics library, which uses lots of floating point operations and iterative models.
There's a reason why this sort of physics was not in games in the old days: It requires an FPU and is very computationally expensive.
Before the 486, most systems didn't even have an FPU at all, and the one in the 486 did not exactly excel in terms of performance.
You really need a 'modern' CPU for that sort of thing.
So you can either have a game that works on old DOS systems, or you can have a game that has realistic physics.
If you design the physics system yourself, at least you can optimize it for the specific CPU and game you're developing, which probably makes it tons faster than using something like Box2D.

Ugh it's coming back how slow working with floats used to be 🤣. I knew a guy who was doing "fixed point" math which would let you do similar to floating point operations but a lot faster - could be a way to do get both the speed and accuracy:
http://x86asm.net/articles/fixed-point-arithm … tic-and-tricks/

I agree with Scali. Collision and physics routines are critical as far as speed is concerned. I think they should be coded from scratch and optimized for non-FPU systems - and we can still have pretty realistic physics anyway, just take advantage of natural laws and equations that we know and mimic the real world as much as you can.

I have a suggestion regarding level map format and editor. What if we pick a suitable format that already exists and has an editor? Camoto is a tool by Malvineous and could be made to support our custom format if we wanted to. Can also work with tilesets and adlib music. Also supports group/archive files, meaning bunch of music/image/map files are stuffed into one big resource data file.

beastlike wrote:

I knew a guy who was doing "fixed point" math which would let you do similar to floating point operations but a lot faster - could be a way to do get both the speed and accuracy:
http://x86asm.net/articles/fixed-point-arithm … tic-and-tricks/

Yup, my 3d engines are entirely fixed-point, even the 486-optimized one. On a 486 the FPU would be slower for most things, so why even bother? Not using the FPU also keeps your code compatible with 486SX and fast 386 systems.

Maybe a warm up like porting NXEngine (Cave Story reimplmentation in C++) to DOS would help. Easier said than done I know, but at least there's an actual, finished, certainlywillbebetterthanthisproposedidea game in there, and most of the dev would involve chopping off the SDL bindings and making a new DOS video/sound/input subsystem to take its place, as well as getting the thing to compile (in DJGPP most likely, but an extra effort to demake it further to use VGA and OPL2 in Watcom C could be done)

I emailed pixel around 2005 about supporting 320x240x8 once. Said it wouldn't be possible 🙁 though i disagree since a bit of lookup table magic on load for everything can fix that up

keenmaster486 wrote:

286, 386, 486? EGA or VGA? Real mode or protected mode? PCM or FM effects? MOD or OPL3 music?

That really depends on what you are trying to achieve. I have absolutely no idea how to write low level code (sound / video / input) for protected mode, so I would just stick to real mode (if I was to make my own DOS game).

The EGA/VGA choice is not just an artistic one. Keep in mind that VGA graphics require TWICE the amout of memory that regular EGA graphics would require. Combined with the 640k limit, that means you can have a lot more variety in EGA than you would in VGA, using the same amount of memory.

For music, I would just stick with the old IMF format, simply because it is by far the easiest to implement. You can write an IMF player for a game in about 1000 bytes of machine code (including file I/O, memory allocation and accessing OPL registers), whereas a MIDI player will probably be at least 8000 bytes after it's compiled.

Of course, if you decide to go for 486 protected mode games, the 640k barrier doesn't matter (that much) and you can add crazy bells and whistles everywhere. But then, you might just as well drop the whole DOS thing and go straight to "modern" platforms in my opinion. I prefer my DOS games in 320x200 pixels.

K1n9_Duk3 wrote:

That really depends on what you are trying to achieve. I have absolutely no idea how to write low level code (sound / video / input) for protected mode, so I would just stick to real mode (if I was to make my own DOS game).

The way DOS games use 32-bit pmode is pretty much the same as real mode, just with giant 4GB segments. As a result, you only need one segment, so basically they write things as if it's a 4GB COM file.
Very simple.
Your VGA ram will be at A0000h instead of A000h:0000h, but that's basically the same thing, right? 😀
The DOS extender will set up some basic 'thunking' to 16-bit so you can still call DOS/BIOS APIs via the usual software interrupts.

K1n9_Duk3 wrote:

The EGA/VGA choice is not just an artistic one. Keep in mind that VGA graphics require TWICE the amout of memory that regular EGA graphics would require. Combined with the 640k limit, that means you can have a lot more variety in EGA than you would in VGA, using the same amount of memory.

But even using 320x200 at 16 colors, VGA does let you customize the palette, while EGA doesn't. So that's a very valid 'artistic' choice to make without increasing memory costs at all.
Some great-looking 16-color artwork has been done for VGA, and it certainly can look better than a mediocre artist using all 256 just to throw more color at the problem (some of those early VGA games truly suffered from that syndrome - as a rule of thumb, the louder they advertised "256-COLOR VGA SUPPORT!!1", the crappier they tended to look).

*Hi-res* EGA graphics is something I always felt like exploring just for the heck of it. That 6-bit color space and the funny aspect ratio could keep things interesting.

K1n9_Duk3 wrote:

That really depends on what you are trying to achieve. I have absolutely no idea how to write low level code (sound / video / input) for protected mode, so I would just stick to real mode (if I was to make my own DOS game).

This applies to me also, I know real mode stuff pretty well and never done any real protected mode stuff. Yes it may not be hard and if the libraries come with all the bells and whistles to call DOS and BIOS functions it could be quite easy, but there is still the learning curve. And pmode stuff works only on 386 and up. There are pretty good demos running on VGA, 16MHz 286 and Gravis Ultrasound..

K1n9_Duk3 wrote:

The EGA/VGA choice is not just an artistic one. Keep in mind that VGA graphics require TWICE the amout of memory that regular EGA graphics would require. Combined with the 640k limit, that means you can have a lot more variety in EGA than you would in VGA, using the same amount of memory.

Good point. 320x200 mode takes 64kbyte on VGA, but only 32kbyte on EGA. On the other hand, VGA allows up to 640x480 at 16 colors which takes 150 kb. 256 color mode is limited to 360x480 with standard H/V rates, and it's not much more, only 169 kb.
Let's also keep in mind that depending on the era of the PC, it might not even have 640kb of memory, some came with 512kb or even less. But on the other hand, even a 286 motherboard that was donated to me had 2MB of memory, so 640kb of conventional memory and 1MB of hardware EMS!

Having said that, I know better VGA than EGA, and better how to work with the 256-color modes than 16 color modes.

K1n9_Duk3 wrote:

For music, I would just stick with the old IMF format, simply because it is by far the easiest to implement. You can write an IMF player for a game in about 1000 bytes of machine code (including file I/O, memory allocation and accessing OPL registers), whereas a MIDI player will probably be at least 8000 bytes after it's compiled.

I think IMF player is even less than 1000 bytes. Probably MIDI player is also less than 8000 bytes as well, depending on features. Adlib music of Monkey Island never used other MIDI events than note on and note off. It's just a tradeoff between how much CPU is used to play music and how much the music data takes memory. IMF files were pre-generated from original MIDI data.

K1n9_Duk3 wrote:

Of course, if you decide to go for 486 protected mode games, the 640k barrier doesn't matter (that much) and you can add crazy bells and whistles everywhere. But then, you might just as well drop the whole DOS thing and go straight to "modern" platforms in my opinion. I prefer my DOS games in 320x200 pixels.

Wolf3D works on 286 and up, as 286 can have both EMS and XMS, so memory should not be an issue. Even 8086 could have EMS. It's just kind of defining or finding a couple of typical machine configurations that really exist. And on a 386+ the 32-bit registers can still be used even in real mode, although not as efficiently as in 32-bit protected mode. And then there's "flat real" mode but it won't work with EMM memory managers loaded.

320x200 is typical of DOS games, but for example Syndicate used 320x200 256-color mode for menus, but 640x480 16-color mode in-game. Though it required a 386 and 4MB of memory.

VileRancour wrote:

But even using 320x200 at 16 colors, VGA does let you customize the palette, while EGA doesn't.

Yes, I know. I've played Duke Nukem II, as you can see from my avatar and username. That game, along with The Blues Brothers and Prehistorik, was memorable for using EGA video mode 0x0D with a custom VGA palette on top. I usually go thinking EGA = 16 colors and VGA = 256 colors, although that is not entirely correct. But the point is that using 16-color video modes requires different coding than (mode 0x13) VGA. Without having a decision on that, you don't need to start programming graphics routines.

Jepael wrote:

320x200 mode takes 64kbyte on VGA, but only 32kbyte on EGA. On the other hand, VGA allows up to 640x480 at 16 colors which takes 150 kb. 256 color mode is limited to 360x480 with standard H/V rates, and it's not much more, only 169 kb.

That seems to be correct (I didn't do the math myself), but those numbers apply to one single full-screen image. My point was that all images (such as sprites, tileset graphics or background images) take twice as much memory when using 256 colors instead of 16 colors. A game will usually have a lot of graphics, so you really should think twice about this.

Jepael wrote:

I think IMF player is even less than 1000 bytes. Probably MIDI player is also less than 8000 bytes as well

That might be true. I was just comparing the original MIDI/AdLib routines from some game against my IMF hack. A quick check told me that it was actually about 800 bytes for IMF and 5400 bytes for MIDI. But keep in mind that MIDI playback also needs to store additional data in memory, like OPL instruments, multiple track pointers and such. (In my example that's about 900 bytes for MIDI variables versus 25 bytes for IMF variables.) IMF doesn't need any of that, because it is basically a recording of the OPL output of a MIDI/CMF/whatever player. This makes IMF easy to implement and reduces CPU usage to a minimum during playback. You could also use DRO format if you don't like IMF, but I don't know much about that format.

And yes, I know that there's EMS and XMS, but I never bothered to learn how to use that. In the end it's just more code that takes up precious conventional memory, though not too much. I might as well ignore EMS and XMS and use protected mode instead, if I wanted to learn "new" things.

In the end it's always a trade-off: The less code (and CPU time) you need for the low-level stuff of the engine, the more code (and CPU time) can be used by the game mechanics. This applies to protected mode, too, because (IIRC) the code that is to be executed must fit in the original 640k of conventional memory.

Scali wrote:

The way DOS games use 32-bit pmode is pretty much the same as real mode, just with giant 4GB segments. As a result, you only nee […]
Show full quote

The way DOS games use 32-bit pmode is pretty much the same as real mode, just with giant 4GB segments. As a result, you only need one segment, so basically they write things as if it's a 4GB COM file.
Very simple.
Your VGA ram will be at A0000h instead of A000h:0000h, but that's basically the same thing, right? 😀
The DOS extender will set up some basic 'thunking' to 16-bit so you can still call DOS/BIOS APIs via the usual software interrupts.

Thanks for the info. Now all I need is time and motivation.

K1n9_Duk3 wrote:

VileRancour wrote:

But even using 320x200 at 16 colors, VGA does let you customize the palette, while EGA doesn't.

Yes, I know. I've played Duke Nukem II, as you can see from my avatar and username. That game, along with The Blues Brothers and Prehistorik, was memorable for using EGA video mode 0x0D with a custom VGA palette on top. I usually go thinking EGA = 16 colors and VGA = 256 colors, although that is not entirely correct. But the point is that using 16-color video modes requires different coding than (mode 0x13) VGA. Without having a decision on that, you don't need to start programming graphics routines.

When talking about not being able to customize EGA palette; you mean actual EGA card? Because on actual EGA card, you can select all 16 colors to be anything from the available 64 colors (6-bit colors, two bits per RGB color component). On a VGA card, you can still use EGA mode with 16 colors, but you can also reprogram the DAC palette to have any 16 colors from the 262144 available colors. On some games, this is the only difference between EGA and VGA modes, they still use 16-color mode but will only reprogram the DAC palette on a VGA.

And some tricks can be played on 16-color mode, for example some games have top part (playfield) and bottom part (inventory, status, etc) and they reprogram the palette so that top and bottom parts have different 16-color palette to get 32 colors.

K1n9_Duk3 wrote:

My point was that all images (such as sprites, tileset graphics or background images) take twice as much memory when using 256 colors instead of 16 colors. A game will usually have a lot of graphics, so you really should think twice about this.

Yes, as it was discussed before, one 64 kilobyte segment for tiles buys you 256 16x16 tiles with 256 colors or 512 16x16 with 16 colors. And since the image data is halved, it can be copied twice as fast, so you can have either twice the stuff on screen or can use half as slow CPU when tiles and video mode are 16-color. I agree, this decision has a huge effect.

There's also a possibility to use 16 color tiles, and 256 color video mode, so that each tileset (foreground, background, characters) can have their own 16 color palette. It will allow less memory usage for tiles and look better but will require just as much bandwidth writing to video memory than 256 color mode.

K1n9_Duk3 wrote:

But keep in mind that MIDI playback also needs to store additional data in memory, like OPL instruments, multiple track pointers and such. (In my example that's about 900 bytes for MIDI variables versus 25 bytes for IMF variables.) IMF doesn't need any of that, because it is basically a recording of the OPL output of a MIDI/CMF/whatever player. This makes IMF easy to implement and reduces CPU usage to a minimum during playback. You could also use DRO format if you don't like IMF, but I don't know much about that format.

I wrote a very barebones command-line player for IMF files under 400 bytes 😀 Since some of the file code and OPL chip code is not only purely for IMF routines, the IMF playing itself might be somewhere along 300 bytes. Yeah, playing MIDI could be too complex and time consuming, unless the MIDI file is limited to being single-track and using fixed instruments per single MIDI channel.

Current DRO version is similar to IMF, there's only two differences. Most important is that IMF supports only single OPL2 (Adlib), while DRO supports also OPL3 and dual OPL2 for stereo music, this is done via register lookup table (indices 0-127 mapped to registers of first OPL and 128-255 mapped to second OPL). Another difference is the timing, DRO has 1000Hz ticks while IMF has several default rates, most often 700Hz used in Wolf3D for example). So in the end there is not much difference which of these formats are used. If I must say something negative, they are both about equally bad for storing music that was originally meant to play in a 60 Hz vertical retrace timer interrupt, because 1000 and 700 are not multiples of 60. This is where RDOS RAW files excel.

Jepael wrote:

When talking about not being able to customize EGA palette; you mean actual EGA card? Because on actual EGA card, you can select all 16 colors to be anything from the available 64 colors (6-bit colors, two bits per RGB color component).

Not in 320x200, which was the subject here - EGA limits its 200-line modes to a strictly CGA-compatible signal (RGBI rather than 'RGBrgb'), so you're stuck with the 16 CGA colors. Most likely IBM was trying to save on logic for the 5154 monitor to detect the mode.

A couple of odd third-party EGA chipsets did support a 200-line 'RGBrgb' signal, and a precious few games exploited this to get a low-res mode with 16-out-of-64 colors (Rambo III and Off-Road come to mind) but that'd only work on a multisync monitor, or perhaps a VGA one if those cards had such a connector.

Ah, so it seems! That might explain a few things 😀 I've actually never had any EGA hardware..

But isn't that the limitation of the IBM 5154 monitor hardware to be backwards compatible with CGA signals (15kHz=RGBI, 22kHz=RrGgBb)? And so it is not a limitation of EGA card hardware itself, but because of the EGA monitor, and to support CGA monitors, EGA card had to use RGBI only on 200-line modes. So in theory, could one just change the palette so it's RrGgBb on a 3rd-party 15kHz monitor?

Well, no, that design decision for the monitor determined the card's behavior in turn. So in 200-line mode the EGA doesn't send out the signal you'd need for 'RGBrgb' - the pin for 'g' becomes 'I' instead (intensity), and the 'r'+'b' pins are disabled. You can still program your palette indexes with values of 0-63, but all you'd get in that range is the 16-color RGBI palette repeated four times (DOSBox emulates this correctly, BTW). More info at http://www.reenigne.org/blog/why-the-ega-can- … 200-line-modes/.

At most, some third-party setup might theoretically interpret this as 'RGBg' instead of RGBI, but even if possible (which I doubt) it'd hardly be desirable 😉
That also explains why those rare 'extra-color EGA' games required specific support for each chipset that had this functionality, since it's explicitly outside the capabilities of standard EGA.

K1n9_Duk3 wrote:

For music, I would just stick with the old IMF format, simply because it is by far the easiest to implement. You can write an IMF player for a game in about 1000 bytes of machine code (including file I/O, memory allocation and accessing OPL registers), whereas a MIDI player will probably be at least 8000 bytes after it's compiled.

Could also consider module format music. If you jettison some lesser used effects, I imagine the play routine would be very small. Plus, GUS would be dead easy to provide support for then. Upload the samples and away you go~

I recall Zone66 had a really cool hybrid FM/MOD format. I'm really surprised more people didn't take advantage of something like that. It was usually one or the other.

Then again, FM tone generation is basically "free" since it's done in the hardware, leaving precious CPU cycles for everything else.

SaxxonPike wrote:

Could also consider module format music. If you jettison some lesser used effects, I imagine the play routine would be very small. Plus, GUS would be dead easy to provide support for then. Upload the samples and away you go~

Depends on the target hardware. For a 486 with 4+ MB, it's no issue, but a low end system with 640K or less memory could have problems. Not to mention that playing MODs in 16-bit segmented mode is extra troublesome. You would basically have to put each sample in its own segment, and juggle segments around all the time.
So you have three problems with MOD:
1) Difficult in 16-bit segmented mode (not many good off-the-shelf libraries, writing it yourself is difficult. Most PC routines are plagued with bugs/incompatibilities with ProTracker)
2) Potentially CPU-hungry, depending on the number of channels used, required sound quality, and target CPU
3) Potentially memory-hungry. MODs can sound very good, even with just 4 channels, but be aware that the best MODs could be 400-700KB each, and were troublesome to combine with a game even on a 1 MB Amiga, let alone a 640K PC or less.

Another aspect is that MODs aren't really 'PC'. You're basically just emulating the Amiga here, and playing their 'native' format. PC audio is more like PC speaker, SN76489 (Tandy/PCjr), AdLib or MT-32. That's what classic PC games sounded like.

SaxxonPike wrote:

Then again, FM tone generation is basically "free" since it's done in the hardware, leaving precious CPU cycles for everything else.

Sadly it's not quite 'free' on a low-end system. The original OPL2 responded very slowly to commands, so you had to add in lots of delays (Yamaha recommended no less than 35 'dummy' reads after doing a write, to get the chip to settle). On a slow PC that means if you play music that updates every frame, you could end up spending about half your frame time updating the OPL2 registers.

Scali wrote:

Sadly it's not quite 'free' on a low-end system. The original OPL2 responded very slowly to commands, so you had to add in lots of delays (Yamaha recommended no less than 35 'dummy' reads after doing a write, to get the chip to settle). On a slow PC that means if you play music that updates every frame, you could end up spending about half your frame time updating the OPL2 registers.

I had no idea. That's kind of obnoxious for a delay. I wonder if one might be able to stagger some of those commands (especially for simultaneous notes and program changes) to reduce the impact that programming the OPL2 has on timing. Or maybe interleave writing registers with some other computation on the CPU in between - surely that number of reads isn't required, only the delay, correct?