Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

printz

Members
  • Content count

    10832
  • Joined

  • Last visited

About printz

  • Rank
    I will always remember

Recent Profile Visitors

6447 profile views

Single Status Update

See all updates by printz

  1. 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? :)

×