A Future Development for CGALIB

Sunday, 17th December 2023

My next project has been held up by a show-stopping bug. I've found it difficult to track one kind of bug in OpenWatcom: the kind of memory corruption that doesn't appear till way after it happens, usually in an unchanged section of the program that's been working fine for a while.

The problem is that the OpenWatcom debugging tools don't appear to work for 16-bit DOS development. A debugger would help me find these errors a lot more easily. I know what part of memory is being corrupted, I just don't know when or how. A debugger could be set to watch that memory and alert me when it gets overwritten.

It would be a lot easier if I could develop the games under my modern OS of choice, where working debugging tools abound, and then compile them under DOS. I'd want to do that without necessarily having a whole different set of graphics and sound assets though, so I'd want to use the CGA 4-colour assets and the PC speaker noises.

So where does CGALIB come in? The easiest way to achieve what I want is if I could get CGALIB to work in a modern operating system. If it could handle bitmaps and fonts in the same way as the DOS version does, but just do things differently when it's time to write them to the screen.

I've taken a few first steps in this direction. I've taken a look at the facilities of SDL2, and written a modification of CGALIB which, instead of writing directly to CGA memory, plots the pixels on an SDL cnavas which is then transferred to the screen. This is partially working, but it's not reliable enough to use for development yet (it seems to randomly omit writes to the screen).

Once I get this working, it'll allow me to do a couple of things. Firstly I can proceed with the project that's currently stopped with a bug I can't trace; Linux debugging tools will make short order of that bug I'm sure.

The other thing I can do, is more easily release versions of my games for modern operating systems. I think that will significantly increase the number of players. DOS will continue to be the primary release OS, but those who aren't familiar with DOS emulation will get to play the games on their preferred OS.

If I can get this process working on my current project, then I can think about retro-fitting it to previous games, allowing Ossuary, The Anarchic Kingdom, Team Droid and Barren Planet to be played natively on Windows, Linux and maybe Mac.