itch.io

[NOTE: This was run from the EXE, and compared against DOSBox-X behaviour. The lives indicator was missing in both cases, which may suggest that the EXE is an older build.]

Nice to find a game that actually runs too *fast* on my Covington! (Well, OK, one can still get used to it...) You may need to look through how you're doing your delays.

Also there's something funky with the keyboard handling on real hardware where for some reason I end up accelerating indefinitely if I use the up arrow key, but playing using the numpad is fine. Not sure how it would get the escape but not the break code somehow...

One more thing: A real screen tends to take a while to switch modes - mine does it in about 1 second. A "Press any key to begin" / "Press any key to exit" would help massively here. Or in the latter case, switching to SCREEN 0 would be better, as the text will stay around when the program closes.

Anyway, this game was fun. I do wonder what it would take to do a CGA version of this...

Tested on a system with a Covington CPU and FreeDOS 1.0.  Runs at a slowish but still perfectly playable framerate ("slowish" meaning it's fast enough that I can't give an estimate as to what it actually is, though it feels like 15 FPS).

So, in short: It works!

And a critique: There doesn't seem to be a way to delete a misplaced piece of train track.

On a Covington (266 MHz Pentium II Celeron, no L2 cache) and an onboard 2 MB S3 Trio64V2/DX w/ video BIOS version 2.04.07, I get about 896 for 320x240 32bpp and about 804 for 320x240 16bpp. Higher resolutions make it notably slower for some reason (about half the speed for 640x480?). VGA fallback is about 993 for 320x200 8bpp.

Thanks for fixing it, it now works fine out-of-the-box.

And yeah, I did know that the Covington was a bit weak. But maybe I should try optimising a game specifically for this CPU - having a 16 KB data cache might be manageable for some funky stuff...

Tried on real hardware (using FreeDOS 1.0), seems to work OK aside from the fact that the keyboard buffer fills up with garbage and then I hear a bunch of beeping. I thought it was the fault of my DPMI server at first (I'm using HDPMI32) but nope, it also happens with DOS4G/W.

Are you able to clear the key buffer every frame?

EDIT: I managed to make a program to temporarily hook INT 0x1C so that I could clear the buffer every theoretically-default PIT tick (~18.22Hz) and that seems to work well enough. Anyway, I probably get about 5-6 FPS on a 266 MHz Celeron (Pentium II type).

I got an actual (Free)DOS machine up and running and have some dev tools on it, so I'll be using that for development and testing. Had I not done that I would be using 86Box instead.

Oh yeah, machine specs:

• Model: HP Brio 8314
• CPU: Covington! Slot 1 266 MHz Celeron (P2 era)
• Chipset: i440EX + PIIX4E
• RAM: 256 MB PC133 (chipset maximum, likely being clocked at 66 MHz)
• HDD: Some 4 GB drive, or is it 8 GB I'm not sure, either way it's slow and sometimes loud... but from a read speed perspective I can also use a disk cache
• Graphics: S3 Trio64V2/DX, 2 MB RAM (will not be using SVGA so the first 256 KB is all I'll be using, and this chip does support the VGA wraparound!)
• Sound: PC speaker, Sound Blaster 16 (semi-PnP variant), 14.4k modem
• Network: D-Link NE2000 clone
• Screen: Some Sony LCD TV, which is fine except when I want to use a 640x350 mode in which case it clips the right side off
• Mouse: PS/2, Logitech ball mouse with scroll wheel (will be using the CTMOUSE driver if I use this!)
• Joystick: Currently none, but maybe I'll find the Logitech Wingman 3D that we might still have as that's the only thing I've got that supports gameport (yes, this box has USB, but no I will NOT be programming a driver for it)

And some decisions:

• Development tools: fasm 1.x - if I change my mind it'll be Turbo Pascal 7
• Code model: Single code segment, single separate data segment, I don't feel like hosing my code segment thanks... but I do need to remember to keep constant strings in the data segment
• Game type: Platformer
• Graphics:
  • Mode 0Dh 320x200x4bpp with the default EGA palette - I could opt for Mode 13h 320x200x8bpp to speed up development time
  • Assuming a VGA chipset (NOT an EGA chipset) just so I can use Write Mode 3 where necessary
  • Drawing algorithms: Pondering a few, which will probably not be optimised for the slowness of an actual VGA card:
    • Tile rendering: 16x16 + 8x8; solid 4bpp + transparent 4bpp + transparent 1bpp (for fonts); aligned + unaligned
• Sound: PC speaker. Maybe FM music if I have time. I am not going to attempt to do PCM audio on the SB16, that card is a bit too easy to overwhelm.

And of course some references:

• Ralf Brown's Interrupt List
• VGADOC4b (not because it's accurate, but because it's convenient)
• Various EGA, VGA, SVGA datasheets (IBM's EGA reference has a schematic which can clarify some behaviours; some SVGA datasheets explain things that IBM clearly didn't)