• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

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

esselfortium said:
Most of them are much more interested in the DOS version's source that's also on the CD.
Click to expand...
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. :ROFLMAO:
 
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.
 

Attachments

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)?
 
tt said:
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)?
Click to expand...
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:
    C: 
    #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:
    C: 
    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 :)
 
Last edited:
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.
 
tt said:
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.
Click to expand...
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.
 
esselfortium said:
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.
Click to expand...
Compiling Ultimate Doom with Cw7 version on CD worked without any changes needed on 68k.
 
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?
 
olePigeon said:
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?
Click to expand...
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.
 
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.
 
Last edited:
Some tidbits I've got so far - all based on UDOOM 1.0.2, but should work on any version I'd imagine. Notably, added some detail to the timedemo exit screen with all the variables that dramatically change performance.

There is a built in FPS counter - seems to be accurate too. Attached is a compiled version with the FPS counter enabled.

Did some real basic tests: level 1, no music, no movement, just seeing how fast it will render the initial view. This is on a SE/30 with an upgraded Diimo clone accelerator and Micron Xceed on external monitor.

1696534951491.png
Biggest issue with running a timedemo right now is that singletics does not work as expected - it renders a black screen and does nothing - so timedemo doesn't work. Lion moved BuildNewTic() into NetUpdate(), and while it has a case to exit if singletics is set, it does not work.

With some tinkering around, it seems like HSendPacket is required in NetUpdate (hence why black screens on singletics), but I am not sure why that is without looking deeper (and I'm not familiar with Doom).

Pretty sure by doing moving buildnewtic into netupdate rather than calling buildnewtic in TryRunTics, this changes singletic behavior, as NetUpdate() is called multiple times per tic potentially. May need to try to create a new BuildNewTic() function and restore the original Doom function flow.

Code: 
Enable FPS counter
    I_IBM.c
    #define __LION_SHOWFRAMERATE 0 change to 1

Remove splash screen
    I_MAIN.C
    Comment out else LionSplash()

Timedemo w/ enhanced info (FPS)
    G_GAME.c
   
    Change G_CheckDemoStatus as below
   
extern int detailLevel, viewwidth,gSndSfxVolume;
extern  Boolean                            gMusicOff, gLargeGraphics;
char detailLvl_human[3] = {'L','M','H'};

boolean G_CheckDemoStatus (void)
{
    int             endtime;
    float fps;
   
    if (timingdemo)
    {
        endtime = I_GetTime ();
      fps = ((float)gametic)/(endtime-starttime)*35;
       
        I_Error ("timed %i gametics in %i realtics\n%f FPS\nview width: %d\ndetail: %c\nmusic: %c\nsound: %c",
                gametic, endtime-starttime,fps,viewwidth,
                detailLvl_human[detailLevel],gMusicOff?'N':'Y',gSndSfxVolume?'Y':'N');
                           
    }
   
    Uncomment G_Timedemo in G_GAME.C

    In D_MAIN.C, function D_DoomMain

    Around line 1330 or so (doesn't really matter)
    add:
     G_Timedemo("demo1");
     D_DoomLoop()
 

Attachments

Got timedemo working by copying netupdate and hacking out some pieces to "rebuild" BuildNewTic - removed for loop and some other bits. Then restoring tryrunticks to call BuildNewTic if in singletic mode.

Probably could do with further work but for the moment it gives me something to work with. Added @esselfortium hashtable work to ultimate doom - had to modify doomdefs.h for the new structure definition and fix/add some prototypes to both that and w_wad.proto.h, but it works.

That said, I don't see any performance increase. Maybe I am bottlenecked elsewhere. If someone wants to run these on a 68040 we'll get a quantifiable performance improvement.

On my system, I did find that Doom is benefiting from more cache or faster FPU (not sure which). My upgraded diimo clone benchmarks at 26% faster compared to the stock configuration, but my clockspeed is only 16% faster. FPU is 58mhz rather than 25mhz and the cache is 128k rather than 64k. Perhaps at some point I'll pull the FPU to figure out which is making the difference.
 

Attachments

zigzagjoe said:
On my system, I did find that Doom is benefiting from more cache or faster FPU (not sure which). My upgraded diimo clone benchmarks at 26% faster compared to the stock configuration, but my clockspeed is only 16% faster. FPU is 58mhz rather than 25mhz and the cache is 128k rather than 64k. Perhaps at some point I'll pull the FPU to figure out which is making the difference.
Click to expand...
I suspect it is the cache, isn't Doom entirely based around integer maths? Plus games tended to be coded to not use such things so that they ran on as many machines as possible. But it would be interesting to know for sure.
 
Phipli said:
I suspect it is the cache, isn't Doom entirely based around integer maths? Plus games tended to be coded to not use such things so that they ran on as many machines as possible. But it would be interesting to know for sure.
Click to expand...
I agree, I think it's probably the cache. I've heard the same, Doom is supposed to be using a lot of fixed point for speed and accessibility reasons. I did see use of the math stdlib though and floats though on a quick trawl of the source, so it's possible Lion might have taken a step back....
 
I happen to have a Macintosh LC630 (68LC040 at 33MHz) and just got the Ultimate Doom 1.0.2 compiled from source on it.
photo_5255788550434183551_y.jpgphoto_5255788550434183552_y.jpg


Really interested now to apply your patches and post back the numbers.
I am not yet familiar with CW, but can a profiler of some sort there help see whats going on?
What about QuickDraw? How suspicious is it and could there exist (faster) alternatives to it?
 
You must log in or register to reply here.

Similar threads

zigzagjoe
Fast! CompactFlash for Macintosh PDS/NuBus
4 5 6
Replies
106
Views
19K
zigzagjoe
zigzagjoe
David Cook
Writing an Application that Runs in Mac OS System 1 Using CodeWarrior Gold 11
2
Replies
21
Views
10K
David Cook
David Cook
atommclain
Open system call failing on System 6 but working on System 7
2
Replies
28
Views
6K
cmholm
C
Snial
MacAsm MiniMorse Masochism
Replies
7
Views
3K
superjer2000
superjer2000
David Cook
Memory adventure: MicroMac SIMMdoubler II and 68851 MMU in a Macintosh II
2
Replies
21
Views
6K
jasa1063
jasa1063
Back
Top