itch.io

If you thought 486s were eye-opening, try the 8088 ;-)  "I can only access 64K at a time?  All the registers are 16 bits wide?  What the hell is this crap?"

While we used Z-buffering in the demoscene for a few objects, I don't think it would offer an appreciable speedup for the kind of overdraw you're doing -- you still have overdraw, but this time in the zbuffer.  It would save a little time during rendering as you'd only be looking up texels once per onscreen pixel, but that's not much of a speedup...  

You might be onto something regarding a portal system.  Check Fabien's analysis of the Build engine, it might give you some ideas: http://fabiensanglard.net/duke3d/build_engine_internals.php

Building from scratch without prior experience in the platform is commendable, and your write-up will help people experimenting along the same lines.

I watched the video and didn't realize how much of a penalty there is with painter's algorithm -- there is a very disturbing amount of overdraw, nearly 5x the amount of actual pixels in the frame. Did you give thought to raycasting the vertices of the quads to quickly eliminate polys that don't need to be drawn? A 486 has way more system memory speed than video ram speed, so eliminating overdraw is worth the effort.

You're correct, you need a FAR pointer to access memory at arbitrary locations, such as CGA at B800:0000.  If you can inline assembler, this becomes a lot easier, as you can just set ES:DI directly to B800:0000 and DS:SI to the source of your graphics.  Good luck!

From the primary author of GCC-IA16: "This is true of the Mentor version. Since then, TK Chia has made some patches to add far pointer support. I haven't tried them yet and don't know where to get a binary (perhaps I'll try to make a new release at the start of April). I have heard that the FreeDOS folks have had some success with Chia's version and can now use that to build instead of Watcom, so if you can track down one of those guys they might have a good lead. Searching twitter for gcc ia16 might be a good start. "

My personal advice is to try to work within near pointers.  Far pointers is something you do because you have to, not because you want to.

You have a few options in 2017 for making 16-bit DOS games coming from a 32/64-bit GCC background:  An old 16-bit compiler like Borland C or Turbo C; OpenWatcom which can compile to a 16-bit output; or probably the best option, a newly-released toolchain based on GCC 6.2 available here: https://blogs.mentor.com/embed... (if the link didn't make it through, google for "Sourcery CodeBench Lite for IA16").

My DOS retrocoding is in a mix of Turbo Pascal and assembler, as the TP IDE allows coding/debugging on the old hardware itself.  But I'm old, and quite insane.

Having played it (great job!), this actually could be optimized all the way down to an 8088, as the playfield doesn't scroll.  A challenge for the next CGA JAM, perhaps.  :)