printz

I'm considering porting Automatic Wolfenstein to DOS. This will allow me to both keep a low footprint on most data and be efficient, and more importantly, make it work wherever DOSBox can be installed (I can sidestep Android development by providing a DOS binary instead, for example. Currently I can run it on my phone, but performance sucks).

I've released an 'experimental' DOS binary here, however it requires Wolf3D 1.4 by Activision/GT. It also contains the source code (which is equivalent to Git commit 400bfcb 20130607 "Committed a tentative..."). It's a 16-bit binary built using Borland Turbo C 3. It's based on alpha01, which is older than the latest alpha02, and much older than the unstable Git builds.

Here's a demo video on map E1M1. Note that it uses the same robotic walking as alpha01 (I didn't port alpha02 or any Git revision to DOS, I wanted to start simple).

Changing C++11 of the SDL code to Borland C language was somewhat fun, because it resulted in streamlining of what was basically non-OOP static class code (I later changed that to OOP, but it was still working on singletons) into simple functions with either program or object-file scope.

However, I obviously had to face the limitations of the 16-bit segmented memory architecture. Since I work with lots of caches of 64x64 (map-sized) data, I'm going to consume a lot of space. I understand that I can use the 'far' qualifier if I want to get past the 64k near segment. Documentation on 16-bit unprotected programming seems quite low these days...

You may notice the performance penalty. Whenever the bot reaches an objective (item, secret wall), you'll observe a split-second lag. Pathfinding seems much slower here. Could it be that 'far' memory access is too slow? Currently it's storing the Dijkstra (in fact just breadth-first) search in a 4096-long priority queue that resides in the far memory.

Anyone with DOS knowledge can tell me how much code and how much data I can throw at a 16-bit program? :)