This makes the game so much more enjoyable, at least for me. I’m now figuring out how to set the controls. Firstly I wanted the analog stick to behave like mouse, but that wasn’t working as you’d need to be moving with both hands. So I simply use it as a directional control with threshold, which also frees the arrow keys for other uses. My current idea is:
joystick: movement
joy button1: previous weapon
joy button2: next weapon
A B C: A B C
up: jump
left/right: strafe
down: map
The rumble is so strong it scared away my cats lol.
Meanwhile I’ve discovered a bug: if you die in the latest unlocked level you’ll unlock the next one xD I’ll be releasing new version with fixes and joyhat support soon.
I never had N-Gage, but my bro just bough one for XMas for my other bro so we’re playing around with it right now.
I am currently working on a tool for this using Python. I am learning how to use OpenGL for the first time, so it’s slow going, but I should have more time soon to flesh this out: https://git.pixelbath.com/pixelbath/anarch-mapper
In keeping with the spirit of Anarch, I am also releasing this into the public domain.
About OpenGL: you’ll probably find tutorials on modern OpenGL with shader etc.: definitely learn that. However also know there exists ancient OpenGL, which they will discourage you from, with so called fixed pipeline (no shaders), which is much more simple for programming (less flexible, it does most things for you), is sufficient for a lot of basic 3D and will run on more computers (because old GPUs may only support older versions of OpenGL). It’s also good to learn that and always consider it as an option. Here is a tutorial on it (it teaches you the old/simple OGL first, then goes on to teach the modern one).
I recently was motivated to try to compile a game for DOS, and I thought it would be cool to try to port Anarch.
Here’s my current progress. The weird colors are only because I haven’t changed from the default VGA palette yet, which I think I can change without too many issues.
My main concern is that the rendering appears to be getting corrupted somehow, and I’m not sure why. I am compiling it as a 32-bit DOS exe, but something is going wrong. Facing certain orientations makes the walls vanish, and it seems like the only a few sections of wall can render consistently, maybe around the top left of the level.
I’m building this in a VirtualBox VM running FreeDOS. The compiler I’m using is OpenWatcom. Just setting up a dev environment for this was a nightmare, so it’s not very easy to debug.
@drummyfish, do you have any idea what might be causing this? The game seems to be running correctly, it’s just the rendering that’s broken.
Edit: All I can remember changing in raycastlib.h that would make any difference is I changed the RCL_HitResult in RCL_castRay3D to be of size 3 instead of size constraints.maxHits, because the compiler required it be a constant.
Edit 2: I recorded the video with the game running at quarter width in an attempt to improve a choppy framerate. Here’s what it looks like at full 320x200 resolution:
Wow, amazing, if you make this playable and link me a repo I’ll add it to the list of unofficial ports.
Hmm not entirely sure, are you using double buffer for rendering? Source code would help.
EDIT:
All I can remember changing in raycastlib.h that would make any difference is I changed the RCL_HitResult in RCL_castRay3D to be of size 3 instead of size constraints.maxHits, because the compiler required it be a constant.
Make it higher just in case, like 64, you are likely accessing unallocated memory.
Yeah, I’m using double buffering, although I’m not blocking to sync with the vga card before I write the buffer to video memory.
I’ll try to upload the source soon. I’ll have to grab the files from the VM and make a git repo. I might make a repo with only the files needed for DOS so it’s actually easier to use there. For example, I had to rename some of the files so their names wouldn’t be truncated.
I just tried that, and it didn’t make a difference. The code makes it seem that 3 is the max size that would be allocated there anyway.
OpenWatcom has experimental C99 support (with an “undocumented” flag), and I was surprised to find that I only had to make a couple of small changes to the .h files.
FreeDOS seems to be a bit broken, and I had trouble actually using the compilers it says it comes with. Installing the packages doesn’t actually set any of the required path variables, and the OpenWatcom package wouldn’t extract unless I did it manually. I might try to get djgpp (a dos port of gcc) working now that I finally managed to get OpenWatcom to work. Maybe a change in compiler will be all it needs. I was hoping I wouldn’t have to go through the efforts of getting another compiler to work, though.
I was wrong about this. I had made changes in two places, but I had only increased the limit in one. Tracking that bug down was quite the adventure, though. I actually got gdb working in FreeDOS, and check out what debugging is like when the system is still in 320x200 resolution:
Anyway, I got it working. I also fixed the palette, and it’s working pretty well now (still no sound, no mouse, no saving):
For the record, the real hardware used in the video is an Intel Pentium 4 processor which is clocked at 1.3 GHz or higher, while original Doom could run smooth on an Intel 486 DX 66 MHz. Please correct me if I’m wrong.
Or Nokia N-Gage! This is the future.
