Porting LinuxDoom to System 7 (or trying to) - progress and questions

[Phipli]

Someone should probably give some of these folks a quick rundown on how not to trash Mac files... They seems to be having great fun extracting Mac files onto windows.

Is this Mac/PC Doom source code on ebay legit?

Oh wow, never thought Id have seen the day...

www.doomworld.com

 

[esselfortium]

Someone should probably give some of these folks a quick rundown on how not to trash Mac files... They seems to be having great fun extracting Mac files onto windows.

Is this Mac/PC Doom source code on ebay legit?

Oh wow, never thought Id have seen the day...

www.doomworld.com

Most of them are much more interested in the DOS version's source that's also on the CD.

 

[Phipli]

Most of them are much more interested in the DOS version's source that's also on the CD.

I can tell by some of them writing it off as not really much new / interesting. They are amusingly just completely stepping over the Mac source and forgetting it is there.

I'm absolutely in awe of the person or people who paid $5k and then uploaded it. That is quite a community spirited act.

Now if everyone would do their bit and download a copy so it can never be pushed under again when ID realise what has happened.

 

[esselfortium]

Last night I backported an optimization from modern Doom ports into Doom II 1.0.2 using the source release. The optimization is the use of a hashtable instead of a slow linear search for W_GetNumForName (used for lump lookups, i.e. finding assets within the WAD), and porting it over to this codebase was pretty quick and straightforward with only some self-inflicted bumps along the way.

There's not (currently) an FPS counter that can be enabled in this port, but the difference in performance was palpable testing the new compile on my 040 Mac II. It's still choppy in big open areas like when you come down the first lift in Doom II MAP29, but it's substantially less choppy than the retail 1.0.3 build I had to compare with.

Another thing of interest:
The 68k ASM routines for DrawSpan and DrawColumn (in the file Draw68K.asm) seem to have been used as-is from an email John Carmack sent the devs, in which he mentioned that he didn't spend much time on it, he doesn't really consider himself a 68k programmer, and that it "could certainly be improved". This is way out of my depth to even attempt to do anything with, but it would be interesting to see how much more optimization is possible, either via hand-rolled asm by an expert, or via seeing if a more modern compiler can generate faster asm from the equivalent C functions.

I've attached an archive with the modified W_WAD.C and the compiled 68k application with hashtable optimization, for anyone who wants to play around with it.

 

[tt]

This is really awesome to see. I tried Doom on an accelerated SE/30, so it would be cool to try it again with further optimizations. Do you have any tips on how to set up the dev environment? For the files attached, are the files placed into a Doom folder with the level files (sorry, going by memory)?

 

[esselfortium]

This is really awesome to see. I tried Doom on an accelerated SE/30, so it would be cool to try it again with further optimizations. Do you have any tips on how to set up the dev environment? For the files attached, are the files placed into a Doom folder with the level files (sorry, going by memory)?

Download and mount the ISO from archive.org.
Copy the CW7, Doom II 1.0.2, and UltDoom folders off of the ISO to another disk.

For Ultimate Doom, you should be able to open the 68k or PPC project file (the files ending in .µ) directly in the CodeWarrior 7 version provided and compile without any issues.

The included Doom II source seems to have been built with CodeWarrior 6, but it's fairly trivial to get it building with 7 by copying in a couple of revisions from the Ultimate Doom source:

1. Copy over the DGMacHeader68k and DGMacHeaderPPC files from UDOOM 1.0.2:sys:MacHeadersƒ: and replace the older versions in the Doom II 1.0.2 project's equivalent subfolder.
2. Find the Sound Manager version check in I_MAIN.C (trying to compile will error on this and clicking the error will take you right to it), and replace it with the ifdef'd version from the UDoom source:
   

   #ifndef __powerc
       vers = SndSoundManagerVersion();
       if ((vers & 0xFF000000L) < 0x03000000L)
   #else
       vers = SndSoundManagerVersion();
       if (vers.majorRev < 3)
   #endif
       {
           ParamText("\pDoom II requires Sound Manager 3.0 or later in order to run. Exiting to Finder.", "\p", "\p", "\p");
           InitCursor();
           Alert(rAlertErrGeneral, NULL);
           goto ShowAndBail;
       }

3. Also add the necessary ifdef to the InitManagers struct:
   

   void InitManagers (void)
   {
    	tWord						i, err;
    	MenuHandle			menu;
    	long						result;
   #ifndef __powerc
    	long						vers;
   #else
   	NumVersion			vers;
   #endif
   	FileFilterUPP		doomFileFilterProc;
   	short					numCalled;
   	EventRecord			macEvent;

   
   Press cmd-M or pick Make from the Project menu, and it should successfully compile Doom II now. Have fun!
   
   To run it, just put DOOM2.WAD (for Doom II) or DOOM.WAD (for Ultimate Doom) into the folder with the application. You can press S during the opening logos to skip them and pop up a simple launcher.
   
   One thing I haven't been able to figure out is how to get the .lib files to rebuild successfully from the .asm files in /libs/, so as a result there's not currently an easy way to modify the 68k asm routines that are being used. It seems like they used MPW for it (which is also provided), but I could only find an up-to-date-looking makefile for the PPC version, which of course doesn't include the 68k asm files. There is an older 68k makefile in one of the backup folders on the disc somewhere, but I couldn't get it working with the current source version, and I'm not sure if it would even build those libs or not. Someone who actually knows what they're doing with MPW's makefiles could presumably figure it out, but that person is not me

 

[tt]

Thanks for explaining. It sounds like there's a ton of information to sift through on the CD image.

Is the correct version of CW 6 or CW Pro 6? Doe it needs to be compiled on a PPC machine for a 68k target? I just recently started messing with CW and all the versions and how to tell which version to use is confusing.

 

[esselfortium]

Thanks for explaining. It sounds like there's a ton of information to sift through on the CD image.

Is the correct version of CW 6 or CW Pro 6? Doe it needs to be compiled on a PPC machine for a 68k target? I just recently started messing with CW and all the versions and how to tell which version to use is confusing.

It's CW, not CW Pro. I believe 7 and 5 are both included on the CD, I've been using 7.
I haven't tried compiling it from a 68k machine, so I'm not sure if that will work, but I think it will?

And yes, there is a huge amount of stuff on the CD.

 

[zigzagjoe]

It's CW, not CW Pro. I believe 7 and 5 are both included on the CD, I've been using 7.
I haven't tried compiling it from a 68k machine, so I'm not sure if that will work, but I think it will?

And yes, there is a huge amount of stuff on the CD.

Compiling Ultimate Doom with Cw7 version on CD worked without any changes needed on 68k.

 

[olePigeon]

I know this is way beyond the scope of "simply" porting DOOM to System 7, but could this game somehow use the AT&T DSPs found on many video cards to accelerate it somehow and improve performance?

 

[MOS8_030]

I remember Doom II ran great on my 840av Quadra. With the Simpsons mod it was absolutely hilarious!

 

[ArbysTPossum]

I do wonder how well a 40Mhz 68040 on a 40Mhz bus runs Doom.

 

[Phipli]

I do wonder how well a 40Mhz 68040 on a 40Mhz bus runs Doom.

What 040s do you have? Some overclock easily. Performa 630 is a good machine to overclock.

 

[Arbee]

I know this is way beyond the scope of "simply" porting DOOM to System 7, but could this game somehow use the AT&T DSPs found on many video cards to accelerate it somehow and improve performance?

My understanding is that DOOM worked in the first place because it's not doing any of the math that DSPs are good at (especially multiply-and-accumulate, which is fairly fundamental to both true 3D graphics and audio). If the DSPs can actually draw into the framebuffer on those cards it might be interesting to try something, but if you're limited to pushing work packets over NuBus and then retrieving them and drawing the results it's probably not gonna be a win.

On the Quadra AVs where the DSP shares the bus and address space with the '040 it could be more interesting, but there's an OS running on the DSP and preemptive multitasking of DSP tasks to deal with and I imagine MacOS would be sad if you didn't cooperate with that stuff.

 

[ArbysTPossum]

I have a 25Mhz accellerator for an LCII and it's bad, I also have a Quadra 605 overclocked from 25Mhz to 33Mhz. I also have a 33Mhz 030, and I've tried Doom on all of these. I also know that programs have an issue running at 512 x 384, so I need this FVGA program to kinda fake a 640x480 mode, then it runs at a better speed. This is why a Doom port that could possibly run better is exciting. Either better code or options to turn off features, I would take anything. I've seen how Doom runs on a variety of my systems, and I don't feel like a 68040 should have such a hard time running Doom.
Edit: Heretic and Hexen run even worse! My goodness, even Duke 3D runs better than Hexen, in large part. Unrelated.