Chocolate Doom

[evildragon]

MikeRS said:

have you checked your IWADs?

MD5 (doom.wad) = c4fe9fd920207691a9f493668e0a2083
MD5 (doom2.wad) = 25e1459ca71d321525f84628f45ca8cd
MD5 (plutonia.wad) = 75c8cf89566741fa9d22447604053bd7
MD5 (tnt.wad) = 4e158d9953c79ccf97bd0663244cc6b6

Random errors can happen with corrupt ones.

yes, all my iwads are fine.. I got the Doom II one directly off the original DOS CD.. I also got my Ultimate Doom version from that disc at EB Games.. So they are both from pressed CDs, and work fine on the PC version of Chocolate Doom, and every other Mac Doom port..

[fraggle]

evildragon said:

fraggle, I can help with the text-mode setup thing. I'm familiar with how DOS displays text, and I can easily explain this..

In real DOS mode, you get the text characters from the VGA BIOS (the actual ROM on the VGA card itself). In Windows window-mode, it is a true type font or a system bitmapped font.

On a computer with an MCGA graphics chip (now those were the days ;) ), the DOOM setup program does NOT have those lines, in real DOS mode.

so, trying to perfect it would be hard, as on each computer, it could look possibly different, depending on your VGA card, or DOS TSR that replaces the VGA BIOS fonts.

Thanks for this, I suspected something along these lines.

Now, hopefully you or someone can help me with Chocolate Doom on a Mac. I use CD on my windows laptop, but my desktop is a Mac and would love to use it on it.. Here's my post on another Doom forum (i accidentally thought you were on that forum)

here is the error.. i can see the title screen, but as soon as I press Escape, it just blanks out..

Do you have an Intel or PowerPC Mac? What is the output from "uname -a" ?

Also, the titlescreen lacked music. I also waited for the Doom Demo to run, and it crashes with the same problem too...

This is deliberate. There is a bug with the OSX native midi support in SDL_mixer that causes a crash when the music loops, so music is disabled by default on OSX.

(btw, your original port, is awesome! exactly how i remember the DOS version)

Thanks!

[esselfortium]

fraggle said:

This is deliberate. There is a bug with the OSX native midi support in SDL_mixer that causes a crash when the music loops, so music is disabled by default on OSX.

Hmm. I believe what Doomsday Engine does in OS X to avoid this issue is convert the mus to midi, create a temporary file with the midi it's playing, and then use the Quicktime sound library stuff (I think) to play that midi, instead of SDL_mixer.

[evildragon]

it's a PowerPC Macintosh, G4 1.5GHz..

uname-a

Darwin brandons-mac-mini.local 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh powerpc

[fraggle]

esselfortium said:

Hmm. I believe what Doomsday Engine does in OS X to avoid this issue is convert the mus to midi, create a temporary file with the midi it's playing, and then use the Quicktime sound library stuff (I think) to play that midi, instead of SDL_mixer.

This is what SDL_mixer does behind the scenes. There's just a bug in the library; it seems that it isn't using the Quicktime API properly. It might be worth looking at Doomsday to see what it does and if it can shed any light on the SDL_mixer bug. I was already going to look at the Dosbox MIDI code, which also implements a Quicktime backend.

it's a PowerPC Macintosh, G4 1.5GHz..

Interesting. I regularly test on OSX (my gf has a macbook pro), but I haven't tested on any non-intel architecture for a while. Last time I checked it was all working properly, but possibly some endianness problems have crept back in.

EDIT: I managed to get remote login access on a PPC Mac. It seems gcc on the latest versions of OSX does some structure field alignment optimisations: ie. it inflates the size of structures to align their fields for faster access. This screws up some of the Doom code that relies on structure alignment when reading data from disk. I know how to fix this and should be able to get a (hopefully) fixed version up soon.

[evildragon]

PrBoom on Mac does it also.

Btw, is there a way to change the resolution on Chocolate Doom? Because Macs don't really have 320x200, 320x240, and 640x400, and when it does 640x400 double-pixeled, it really shows up as a wide-screen image on a 640x480 VGA signal. So the aspect ratio is lost anyway.. So I was hoping for 640x480 double-pixeled..

(i noticed that the PC version could do the double-pixel stuff.. and on the title-screen before the crash on the mac, i could see the wide-screen image as it appeared to run in a 640x400 res.)

[andrewj]

fraggle said:

I managed to get remote login access on a PPC Mac. It seems gcc on the latest versions of OSX does some structure field alignment optimisations: ie. it inflates the size of structures to align their fields for faster access. This screws up some of the Doom code that relies on structure alignment when reading data from disk. I know how to fix this

I'm curious, how are you going to fix it: compiler option, pragmas, or using __attribute__() stuff?

[fraggle]

Ajapted said:

I'm curious, how are you going to fix it: compiler option, pragmas, or using __attribute__() stuff?

I'm using __attribute__(packed), but hiding it behind a #define named PACKEDATTR. This is exactly the same approach used by PrBoom. I've gone through the source and identified which structs need the attribute. Interestingly, it seems like PrBoom is missing the attribute on some structures, so maybe that's the cause of the crash.

I use the same compiler on all architectures (gcc), so this should be okay for now. The #define hides any direct dependency on gcc, though.

evildragon, if you could remove your ~/chocolate-doom directory and re-run the build-chocolate-doom script again, hopefully this has fixed your problem..

[entryway]

fraggle said:

it seems like PrBoom is missing the attribute on some structures, so maybe that's the cause of the crash.

On which?

[evildragon]

just rebuilt it, same thing.. here's the error, it looks the same too me..

brandon-maceacherns-mac-mini:~ Brandon$ cd chocolate-doom
brandon-maceacherns-mac-mini:~/chocolate-doom Brandon$ ./chocolate-doom
                         Chocolate Doom 0.2.0
Z_Init: Init zone memory allocation daemon. 
zone memory: 0x59e7000, 1000000 allocated for zone
DEH_Init: Init Dehacked support.
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
saving config in /Users/Brandon/.chocolate-doom/default.cfg
W_Init: Init WADfiles.
 adding doom2.wad
===========================================================================
                         DOOM 2: Hell on Earth
===========================================================================
 Chocolate Doom is free software, covered by the GNU General Public
 License.  There is NO warranty; not even for MERCHANTABILITY or FITNESS
 FOR A PARTICULAR PURPOSE. You are welcome to change and distribute
 copies under certain conditions. See the source for more information.
===========================================================================
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon - [.......R_GenerateLookup: column without a patch (BIGDOOR6)
R_GenerateLookup: column without a patch (BIGDOOR7)
R_GenerateLookup: column without a patch (SW1CMT)
R_GenerateLookup: column without a patch (SW1WOOD)
R_GenerateLookup: column without a patch (SW2CMT)
R_GenerateLookup: column without a patch (SW2WOOD)
R_GenerateLookup: column without a patch (WOOD3)
R_GenerateLookup: column without a patch (WOOD4)
R_GenerateLookup: column without a patch (WOOD5)
...............................
P_Init: Init Playloop state.
I_Init: Setting up machine state.
NET_Init: Initialise network subsystem.
S_Init: Setting up sound.
D_CheckNetGame: Checking network game status.
startskill 2  deathmatch: 0  startmap: 1  startepisode: 1
player 1 of 1 (1 nodes)
Emulating the behavior of the 'Doom 1.9' executable.
HU_Init: Setting up heads up display.
ST_Init: Init status bar.
Error: Bad V_DrawPatch
Abort trap
brandon-maceacherns-mac-mini:~/chocolate-doom Brandon$ 

[fraggle]

Sorry, my bad. Looks like it isn't structure alignment after all. I wrote a test case program that I ran remotely on a PPC Mac, to print the size of a structure, problem is that I misread the structure :-)

I've tracked down the real problem, and this might need fixing in PrBoom[-plus?] as well. In r_data.c, there is a structure named texpatch_t which has an originx member. This is an int. It is initialised from an endinanness-corrected value from a patch_t structure, read from disk. In patch_t, originx is a short. The endianness conversion macros (SHORT and LONG) return an unsigned integer. So a few texture patches with negative offsets get screwed up: those negative offsets get transformed into positive, very large offsets. Hence the "column without a patch" errors. My fix is to change the texpatch_t originx, originy members to shorts.

I've uploaded what I hope should really be a fixed version now, so please delete ~/chocolate-doom and re-run the script again :-)

EDIT: Interestingly, the original versions of SHORT and LONG evaluate to signed values (there are casts in the macros). I switched recently to using the SDL endianness macros, but didn't include the casts, so possibly this is the problem.

[evildragon]

I was hoping that would work, lol.. it did fix the first errors, but the bad V patch one at the end still occurs, which keeps bouncing me out of Chocolate Doom.. (oddly enough, any running applications before launch, lose their ability to minimize, including Finder.. though, that happens to any full screen application that crashes)..

brandon-maceacherns-mac-mini:~/chocolate-doom Brandon$ ./chocolate-doom
                         Chocolate Doom 0.2.0
Z_Init: Init zone memory allocation daemon. 
zone memory: 0x59e7000, 1000000 allocated for zone
DEH_Init: Init Dehacked support.
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
saving config in /Users/Brandon/.chocolate-doom/default.cfg
W_Init: Init WADfiles.
 adding doom2.wad
===========================================================================
                         DOOM 2: Hell on Earth
===========================================================================
 Chocolate Doom is free software, covered by the GNU General Public
 License.  There is NO warranty; not even for MERCHANTABILITY or FITNESS
 FOR A PARTICULAR PURPOSE. You are welcome to change and distribute
 copies under certain conditions. See the source for more information.
===========================================================================
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon - [......................................]
P_Init: Init Playloop state.
I_Init: Setting up machine state.
NET_Init: Initialise network subsystem.
S_Init: Setting up sound.
D_CheckNetGame: Checking network game status.
startskill 2  deathmatch: 0  startmap: 1  startepisode: 1
player 1 of 1 (1 nodes)
Emulating the behavior of the 'Doom 1.9' executable.
HU_Init: Setting up heads up display.
ST_Init: Init status bar.
I_InitGraphics: 320x200 resolution is not supported on this machine. 
I_InitGraphics: Video settings adjusted to compensate:
        letterbox mode on (aspect_ratio_correct=1)
        screenmultiply=2
NOTE: Your video settings have been adjusted.  To disable this behavior,
set autoadjust_video_settings to 0 in your configuration file.
Error: Bad V_DrawPatch
Abort trap
brandon-maceacherns-mac-mini:~/chocolate-doom Brandon$ 

[fraggle]

There's probably another signed/unsigned issue hiding somewhere in the source, probably in the V_DrawPatch code. Anyway, try again (sorry about this :-)

[evildragon]

don't worry about it ;) This reminds me of the day I BETA tested for Microsoft Windows ME, Whistler (XP), and Vista.. Bug? Reinstall the whole OS.. lol this is a piece of cake compared to that ;)

anyways, that worked, i got good-ol classic Doom working in it's original quality on my Mac..

thanks for the help! (and im glad there are still active developers these days)

EDIT: I found a 320x240 mode, with 4:3 fixed, and that on my Mac does allow full-screen, but it's "fuzzy" vertically, as if there's billinear filtering going on..

If I turn off aspect ratio correction and select 320x200, it just knocks me into 640x480 with letter boxing...

EDIT2: Just noticed a small bug, but is probably got to do with SDL... If you use the mouse to move, the mouse cursor appears for a single-frame per movement.. the mouse cursor also flashes if you pick up a powerup (from the screen flash)

[fraggle]

evildragon said:

EDIT: I found a 320x240 mode, with 4:3 fixed, and that on my Mac does allow full-screen, but it's "fuzzy" vertically, as if there's billinear filtering going on..

If I turn off aspect ratio correction and select 320x200, it just knocks me into 640x480 with letter boxing...

Aspect ratio corrected 320x240 is pretty nasty. Try turning the aspect ratio correction back on again and selecting 640x480 instead.

I should probably make aspect ratio corrected 640x480 the default if you don't have proper 320x200, at the moment the default is 640x480 letterboxed.

EDIT2: Just noticed a small bug, but is probably got to do with SDL... If you use the mouse to move, the mouse cursor appears for a single-frame per movement.. the mouse cursor also flashes if you pick up a powerup (from the screen flash)

Yeah, I get the same thing on the (Intel) Mac I test on. It seems to be a known problem, because the most recent version of SDL has fixed it. Unfortunately, the most recent version of SDL also has a nasty bug on Macs that causes it to randomly crash when you press keys, so I'm sticking with a slightly old version for now :-)

Good to hear things are working now, and thanks for the bug report!

[evildragon]

I tried the 640x480 4:3 aspect ratio, and there was no change.. Actually, my monitor reported that they were both the same scanrate, then I checked the terminal window, it never went into 320x240 anyway..

Macs don't have 320x200, 320x240, and 640x400 it seems, even if I try to add them, I get Kernel Panics at boot, just by "having" them..

EDIT: Here's the effect.

Letterboxed 640x480..
http://blackevilweredragon.spymac.com/noscale.gif

4:3 Corrected 640x480
http://blackevilweredragon.spymac.com/scale2.gif

It does a little filtering.. For a Mac, I don't know of any work around, unless there was a 640x480 double-pixeled mode with 1:1 pixel ratio, but then that would defeat the aspect ratio correction, but it would clear up the image for PowerPC Mac users (I think it only affects the last-gen PPC Macs, not sure though)

[fraggle]

The aspect ratio correction gets better the higher the resolution you use. If you run at 1600x1200 you get perfect scaling (no blurring at all), but things tend to get a bit slow then just due to the sheer number of pixels that need to be blitted to the screen. Personally, I find that the blurriness is barely visible at 640x480 anyway.

[evildragon]

heh, to me, i like seeing my CRT's scanlines, like i remember it doing when i used to play the game.. and being I use a good Trinitron CRT, the bluryness at 640x480 4:3 is visible to me..

I could have sworn though that the original Doom engine did support 320x240.. i remember that an ISA VGA card compared to a PCI card on the same computer and monitor yielded a different aspect ratio, thus thinking different resolutions (the ISA card being 200 lines, and the PCI one 240 lines)..

It's been 8 years since I last used Vanilla Doom

[Csonicgo]

Most VGA monitors actually displayed 720x400 whilst playing doom.

[evildragon]

Csonicgo said:

Most VGA monitors actually displayed 720x400 whilst playing doom.

I can also explain this.

A VGA monitor can not actually display 200 lines or 240 lines of resolution. So, the VGA card duplicates each line (double scanned), and 200 lines becomes 400 lines, and 240 lines becomes 480 lines. An old VGA monitor like the IBM 8512, will even have 3 POTs, one called 350 line, 400 line, and the other 480... Here's more information on how VGA works: http://www.stanford.edu/class/cs140/projects/pintos/specs/freevga/vga/crtcreg.htm

http://www.kryslix.com/nsfaq/Q.7.html



(I have a feeling Fraggle knows all this though ;) )

Thing is though, those monitors "guess" what the horizontal pixels are, because by rules of a raster CRT, you can put as many horizontal pixels as you want, but all the monitor looks for is how many lines.. So if it sees 400 visible lines, it assumes it's DOS 80x25, which is 400 lines with 720 horizontal pixels (if you edited the text characters to sprites or something.. the demo "Yo!" does this). Thing is, 320x200 uses this same exact mode on the DAC. Other "gueses" the CRT make, are if 600 lines, it must be 800x600, if 768 lines, it must be 1024x768. LCD's on the other hand, are a little smarter, and will tell you exactly what pixels are visible, as they have to lock on the phase and clock.

BUT, on a Macintosh, 400 line modes do NOT exist, and won't exist. It is my guess that it's Apples way of making their Macs stand out from PC's, by removing the critical 400 line mode that was used for both text mode, and 320x200 modes. However, Intel Macs regain these modes, but PowerPC Macs don't have them even, and enabling it produces a Kernel Panic at boot.

[chungy]

I doubt Apple had anything to do with it--most likely IBM not even caring about adding those kinds of modes to PowerPC. Several other architectures (Sun SPARC, for example) also lack it.

[fraggle]

Um, I don't think the choice of processor determines what video modes are available :-)

[evildragon]

fraggle said:

Um, I don't think the choice of processor determines what video modes are available :-)

Different boot ROMs, different video ROMs to interface them. You can't slap a PC video card in a PowerPC Mac, but you could on an Intel Mac. (haven't tested this, but intel Macs have EFI, and now have AT BIOS emulators, so it "should" work.. PowerPC macs have OpenFirmware, which a PC video card can't interface with)

I haven't found the cause for the lack of low resolution modes, but I seriously suspect it has to do with the ROMs either on the boot ROM, or the video ROM. Nothing a hack couldn't fix. ;)

EDIT: Oh, and operating system. (for mac os x, video modes are selected by monitors EDID. windows it's selected by video card driver)

[aleksej]

Latest builds (1043 and newer) lacks 320x200 mode. It is just temporary issue or new vision what port needs in future and what not?

[Csonicgo]

c.imp said:

Latest builds (1043 and newer) lacks 320x200 mode. It is just temporary issue or new vision what port needs in future and what not?

Iirc lots of video cards hate 320x200 for some dumb reason but I'm sure fraggle is working on it. :)

fraggle said:

Um, I don't think the choice of processor determines what video modes are available :-)

yeah, we wish that were the case.. :(

[Graf Zahl]

c.imp said:

Latest builds (1043 and newer) lacks 320x200 mode. It is just temporary issue or new vision what port needs in future and what not?

It's not the latest build but the video driver.

For the vast majority of users these video modes have absolutely no use whatsoever so the graphics hardware developers save the time spent on implementing and maintaining these modes into their drivers.

[Csonicgo]

Graf Zahl said:

It's not the latest build but the video driver.

For the vast majority of users these video modes have absolutely no use whatsoever so the graphics hardware developers save the time spent on implementing and maintaining these modes into their drivers.

maintaining? iirc most new video cards can now set any resolution you would ever want. Low resolutions shouldn't require "maintenance" at all. I hope this is a temporary problem.

I'll report it to nVidia, as I hear some people are having trouble getting low resolutions to work with their new drivers.

[fraggle]

c.imp said:

Latest builds (1043 and newer) lacks 320x200 mode. It is just temporary issue or new vision what port needs in future and what not?

If you go into the Display configuration dialog in Chocolate Setup and turn fullscreen mode on, is 320x200 listed? If not, your card does not support 320x200 mode.

If you really think that Chocolate Doom is doing things wrong and that your card really does support 320x200 mode, you can force it to try to use that mode by editing chocolate-doom.cfg and setting autoadjust_video_settings to 0, screen_width to 320 and screen_height to 200.

[Graf Zahl]

Csonicgo said:

maintaining? iirc most new video cards can now set any resolution you would ever want. Low resolutions shouldn't require "maintenance" at all. I hope this is a temporary problem.

I'll report it to nVidia, as I hear some people are having trouble getting low resolutions to work with their new drivers.

I doubt you will have any success with it. NVidia completely removed all support for low resolutions from their latest line of drivers.

[evildragon]

Graf Zahl said:

I doubt you will have any success with it. NVidia completely removed all support for low resolutions from their latest line of drivers.

Considering that the VGA monitors can't actually scan as low as 200 lines (lowest is actually 350 lines), and since 320x200 gets double scanned to 640x400, if you can do 640x400, just chose that. Even though in the frame buffer it's a different resolution, to the monitor, it's exactly the same.

I got the specifics btw as to why it's double scanned, if you'd like to know. Got in contact with someone who programmed for PC's back in the days..