Doom Comic
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Misc. > Everything Else > Programming help wanted for Wolf3D Port!
 
Author
All times are GMT. The time now is 04:58. Post New Thread    Post A Reply
shadow1013
Junior Member


Posts: 228
Registered: 08-10


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

Last edited by shadow1013 on 10-31-11 at 00:16

Old Post 10-31-11 00:10 #
shadow1013 is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 8664
Registered: 07-06


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

Last edited by Maes on 10-31-11 at 00:36

Old Post 10-31-11 00:19 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
shadow1013
Junior Member


Posts: 228
Registered: 08-10


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 :(

Old Post 10-31-11 00:35 #
shadow1013 is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 8664
Registered: 07-06


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 ;-)

Old Post 10-31-11 00:38 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
shadow1013
Junior Member


Posts: 228
Registered: 08-10


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 **********

Old Post 10-31-11 00:40 #
shadow1013 is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Blzut3
Junior Member


Posts: 210
Registered: 06-04


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.)

Old Post 10-31-11 02:03 #
Blzut3 is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 8664
Registered: 07-06


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.

Old Post 10-31-11 10:56 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Super Moderator


Posts: 6000
Registered: 07-00


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!

Old Post 10-31-11 11:16 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 8664
Registered: 07-06



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)

Old Post 10-31-11 11:18 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
shadow1013
Junior Member


Posts: 228
Registered: 08-10


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

Old Post 11-01-11 01:03 #
shadow1013 is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
_bruce_
Forum Regular


Posts: 799
Registered: 11-07


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

Old Post 11-01-11 11:38 #
_bruce_ is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Super Moderator


Posts: 6000
Registered: 07-00



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!

Old Post 11-01-11 13:57 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 8664
Registered: 07-06


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?

Old Post 11-01-11 14:09 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
shadow1013
Junior Member


Posts: 228
Registered: 08-10


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

Old Post 11-01-11 16:56 #
shadow1013 is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
shadow1013
Junior Member


Posts: 228
Registered: 08-10


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..

Old Post 11-01-11 20:35 #
shadow1013 is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Super Moderator


Posts: 6000
Registered: 07-00



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?

Old Post 11-01-11 21:10 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
shadow1013
Junior Member


Posts: 228
Registered: 08-10


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)

Old Post 11-01-11 21:26 #
shadow1013 is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
geo
Senior Member


Posts: 1381
Registered: 10-05


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 :-)

Old Post 11-02-11 02:02 #
geo is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
shadow1013
Junior Member


Posts: 228
Registered: 08-10


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

Old Post 11-02-11 02:05 #
shadow1013 is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 04:58. Post New Thread    Post A Reply
 
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Misc. > Everything Else > Programming help wanted for Wolf3D Port!

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.

Forums Directory