Programming help wanted for Wolf3D Port!

[shadow1013]

So because I really don't know a place to come for this, I decided to post here. For a while now I've been trying to port the original sources for Wolfenstein 3D to a clean, nice looking 32bit codebase (It's still DOS, just compiled with 32bit WATCOM under DPMI) unfortunately, Although I have removed all of the 16bit assembler and either rewrote it in C (not much of that) or wrote a 32bit assembler version, and got rid of the 16bit memory model stuff that plagued the codebase, it still crashes upon startup and I can't locate the cause because I use dosbox to develop it, and it takes down the whole program. So if anyone would like to look over the code and maybe find why it doesn't work? Thank you in advance!

Here's the code: http://www.megaupload.com/?d=C3SPM8FT

[Maes]

Even though I -personally- don't find your project to be quite my cup of tea, if I had something that I knew for sure (or very probably) that it would end up in development hell, I'd just release anything I'd have done so far (with any due warnings/credits/disclaimers/notes) and let any takers handle it on their own/ask any questions later.

Edit: beat me to it :-p

[shadow1013]

lol, well this is kinda of my rock bottom, it's non-operational and everything I do to try to make it work seems to point to something else. idk. I wish anyone goodluck who decides to look. It's a tad bit cleaner than the original sources (tad being emphasized) and at least I got rid of those horrid precompiled scalers. At risk of being whiny, I WANT IT TO WORK :(

[Maes]

I never really bothered with the Wolf3D code before, but I took a peek at your stuff and it's scary how much one can understand if he has been exposed to Doom's code before. You can literally find prototype forms/equivalents of Doom code and functions in there, but as a whole it's much more crude, hideously platform specific and just feels haphazardly cobbled together.

Now, if I were to take it upon myself to create a "nicer, cleaner codebase" for Wolf3D, I would do it the same way I did it (and am still doing) for Doom ;-)

[shadow1013]

lol oh god. wolf3d feels like dooms predecessor to me in code, I see all sorts of things that remind me, and trust me, this code here is much cleaned up, for example, the menu system used to call mouse interrupts directly. and so much code is tied to handling Mode-X VGA its **********

[Blzut3]

Why reinvent the wheel? (I would have plugged my fork, but if the goal of your project is to port Wolf to 32-bit, it's already done there.)

[Maes]

Well that, and remembering that DOS programming is pretty much a lost dark art, especially when it comes to all those non-protected mode programming tricks and hacks to support all those different sound cards.

Even if your goal is to produce a pure DOS executable and never support any other platform (which IMO kinda defeats the purpose of "porting to 32-bit", especially if you intend to stick with DPMI and not go for full protected mode/flat memory using e.g. DOS4GW), you're probably better off using something like Blzut3's as a base, and "downgrade" to DOS from there.

[fraggle]

1. Why don't you set up DOS in VirtualBox? That probably won't crash.

2. How did you develop this? Did you go through an incremental process of migrating the codebase to 32-bit in small chunks? Or did you do the whole lot at once, then compile it and find it didn't work?

If the first case, then there must have been a particular point in development when the program stopped working. Roll back to an earlier version of the code and find which change broke it (you *are* using version control, right? Always use version control).

If the second case, you're probably screwed anyway. There's no way you're going to migrate all that 16 bit code and assembler at once and get it all right. The change is so large that you'll never be able to find all the bugs.

3. If in doubt, sprinkle printf() statements (with pauses) at carefully chosen places in the startup code, so you can find out where it's going wrong.

Good luck!

[Maes]

fraggle said:

3. If in doubt, sprinkle printf() statements (with pauses) at carefully chosen places in the startup code, so you can find out where it's going wrong.

(Y)

[shadow1013]

Well I had to do it all in one move otherwise the thing wouldn't compile. And I have noversion control :( but the printf statement always helps and thats how I had managed to solve many problems in the codebase already :D lol it crashes now in LoadLatchMem, but only sometimes. othertimes it skips. or whatever. it seems to be asynchronous

[_bruce_]

I second Fraggle's post.
Such a task is a fragile undertaking... piece by piece or you crash and burn.

[fraggle]

shadow1013 said:

Well I had to do it all in one move otherwise the thing wouldn't compile. And I have noversion control :(

All hope might not be lost, but if I were in your position I'd seriously consider starting over. Keep a copy of what you've done so far, as you will probably find a lot of your changes are still useful.

I'd think about how you can divide this project up into stages. As I see it, the big hurdles are: 1) eliminating the assembly code (porting to C), 2) getting it working with a 32-bit compiler, 3) porting to modern operating systems.

Start with a clean copy of the original 16-bit code and set up version control as the VERY FIRST THING YOU DO. Systems like Subversion are trivial to set up (you don't even need to run a server), and not very difficult to learn. It's worth the effort, not just because you can roll back to earlier versions, but also because it makes you think about your changes in a more careful and methodical way.

Try and get the original 16-bit code to compile with its original compiler. I don't know what compiler Wolf3D used but it shouldn't be too difficult to figure out. It's possible you might need to make some minor changes just to get it to compile but hopefully it should mostly work out of the box. Once you've done that, and you have the game running, set about converting all the assembler to C, so that you have a pure C codebase. If you've already converted parts of the code to C you can reuse that work. Don't convert it all at once - convert small chunks, maybe a function at a time, and test it out as you go.

Once you have a pure C codebase it shouldn't be *too* difficult to convert to a 32-bit DOS compiler like DJGPP. There will be some obvious things you'll have to work around - it's probably best to replace all instances of 'int' with 'short', for example. Code that calls interrupts to interact with hardware will probably need changing. Once you're done you should have a codebase that will pretty much work with modern compilers. Then rip out anything DOS specific, replace with SDL and get a modern source port up and running!

[Maes]

I am not as informed about the Wolf3D code as I am with Doom's, but is it really that much more "out of the box" ready-to-compile? Is it not missing important things like a sound system/sound drivers etc. like Doom's source release did?

[shadow1013]

Well it contains all original source modules including two object files including the data for the startup screen and the base palette, which are linked into the executable. Not only this but it contains a whole bunch of other source modules which contain either older versions of some files or fragments of other files, and lastly it contains two interesting files which implement span drawing, which is 32bit coda in wolfhack.c and wl_hack_a.asm

[shadow1013]

Wow I hadn't seen most of these responses. the original wolf3d source code works 100% out of the box with borland c (i forget which version i have it) and i have been porting it to watcom c with dos4gw. Umm i'm not sure how i'm supposed to do it incrementaly, because it isn't just the asm code that needs to be changed, but the C code is FILLED with references to 16bit memory model and other such things. so yeah..

[fraggle]

shadow1013 said:

but the C code is FILLED with references to 16bit memory model and other such things. so yeah..

I just had a look - there are certainly plenty of "far" pointers. Those are certainly easy to convert to 32-bit - just remove the "far" keyword. Is that all, or are there more fundamental things?

[shadow1013]

well the memory manager is pure of wonderful 16bit code :) and also the page manager, umm other than that its mostly just getting rid of the far pointers and converting the assembler code, which is what i did for the whole source, the only *new* parts being my assembler code in id_sd_a.asm replacing the original 16bit interrupts and the code in wl_scale.c, which replaces the original compiled-on-the-fly scalers with an actual normal looping scaler (which looking at it now I see I have a bug with the GetSpriteBitmap routine, in the deepest loop i shift left instead of right)

[geo]

Even if someone has already done a 32 bit port... keep going dude. Its your project and you're learning from it. I remake old Atari games for fun :-)

[shadow1013]

Thank you :) thats how I think of it, in fact I've done ports of all 3 released id1 engines to linux on x11 using only xlib and oss just for fun