Chocolate Doom

Wagi said:

Just a curiosity: How well is the OPL emulator supposed to handle real MIDIs and a large number of voices playing at once? I tried using a custom-made MIDI in there the other day and OPL slowed it down to about half the tempo and some of the tracks didn't line up properly.

OPL isn't really finished, as it is to be as close as possible to DMX (and it's nowhere near done)

Wagi said:

Just a curiosity: How well is the OPL emulator supposed to handle real MIDIs and a large number of voices playing at once? I tried using a custom-made MIDI in there the other day and OPL slowed it down to about half the tempo and some of the tracks didn't line up properly.

This is a known problem. It doesn't handle some MIDI files properly, especially if they're multi-track files.

I need help in reverting a display setting in Chocolate Doom. I don't know what I did to my computer earlier, but now when I run Chocolate Doom, my games are no longer fullscreen and letterboxed. For example, the game now plays in a small window in the center of the screen with black surrounding the game.

My settings are set to Full Screen, 32 bit, Fix Aspect ratio, and 640x480, but the game does not take up the entire screen. Like I said, it's only a small window in the center of the screen surrounded by a lot of black space.

Thanks.

EDIT: Seemed to have fixed it, it was some setting with my laptop's video card (Intel GMA 4500). Set scaling from "center image" to "maintain aspect ratio". Need to see how this will pan out with my other games though.

../libopl.a(opl_obsd.o): In function `OPL_OpenBSD_PortRead':
/trunk/chocolate-doom/opl/opl_obsd.c:102: undefined reference to `inb'
../libopl.a(opl_obsd.o): In function `OPL_OpenBSD_PortWrite':
/trunk/chocolate-doom/opl/opl_obsd.c:107: undefined reference to `outb'
*** Error code 1

When I start up Chocolate Doom v1.6.0 in Mac OS 10.6.8, I get the message "WARNING: No known way to set processor affinity on this platform."  The app has never crashed on me (for any reason), but this wording makes it sound unfixable from my end.  Is that right?

I searched for this phrase here and on google, but everything I found was about recent Windows versions.

Xeriphas1994 said:

When I start up Chocolate Doom v1.6.0 in Mac OS 10.6.8, I get the message "WARNING: No known way to set processor affinity on this platform."  The app has never crashed on me (for any reason), but this wording makes it sound unfixable from my end.  Is that right?

I searched for this phrase here and on google, but everything I found was about recent Windows versions.

OS specific - as long as SDL doesn't die on you'll live on to see another day.
If you're really concerned then there might be another disc coming with your OSX distribution on which you may find a tool to set the affinity.

Fraggle may have a more in depth answer.

http://developer.apple.com/library/mac/#releasenotes/Performance/RN-AffinityAPI/_index.html

My understanding from that is that the OS doesn't allow applications to control this setting (because it presumes to handle such things intelligently itself), and is simply informing you of this fact.

As far as I'm aware, setting the processor affinity to run on only one CPU/core is to work around a SDL_mixer bug that only affected Windows; Chocolate Doom does set it on every OS, because there's not really much harm in it and the game doesn't benefit from multicore anyway.

I recall some other Mac OS X related sound problems, but I'm not sure what it was.

chungy said:

As far as I'm aware, setting the processor affinity to run on only one CPU/core is to work around a SDL_mixer bug that only affected Windows; Chocolate Doom does set it on every OS, because there's not really much harm in it and the game doesn't benefit from multicore anyway.

I recall some other Mac OS X related sound problems, but I'm not sure what it was.

It's still a shame that it's 2011 and anything that uses that library is forced to one core.

Yes it is, but I doubt complaining in the main Chocolate Doom forum thread is the proper way to get their attention :P

chungy said:

Yes it is, but I doubt complaining in the main Chocolate Doom forum thread is the proper way to get their attention :P

Yeah, I know, people are moving away from sdl_mixer, though, and perhaps one day Choco can too.

Xeriphas1994 said:

When I start up Chocolate Doom v1.6.0 in Mac OS 10.6.8, I get the message "WARNING: No known way to set processor affinity on this platform."  The app has never crashed on me (for any reason), but this wording makes it sound unfixable from my end.  Is that right?

I searched for this phrase here and on google, but everything I found was about recent Windows versions.

As far as I know it's never actually caused a problem on OS X. I'm not convinced that the affinity workaround is still actually even needed now.

There seem to be different opinions on what the problem was and what was causing it. My understanding was that it was an SDL_mixer problem, though someone told me (Quasar?) that they thought it was with SDL itself. The problem seemed to affect both Windows and Linux, but then there was some question of whether it was actually two separate bugs and only the Windows one needed the affinity fix.

There was certainly an identified race condition in SDL_mixer that got fixed several versions back, and I believe this was probably the cause of the problem. But the confusion over what the problem actually was means I'm not completely certain, so if I take the workaround out, it might break. That said, I'm really tempted to just rip it out and see what happens.

chungy said:

I recall some other Mac OS X related sound problems, but I'm not sure what it was.

A while back the game used to crash when the music looped. The SDL_mixer OS X native MIDI code got rewritten, which fixed that.

Unfortunately the rewritten code also had a bug - the game wouldn't crash, but the music would not loop! So the music would play through once and then just stop. That bug finally got fixed last week so hopefully everything will work fine now.

Sorry for breaking the concentration here and to change the subject topic, at least for a moment:

I had a question, which is, always with the goal of achieving the "original," authentic Doom experience: "Should I let Chocolate Doom stretch the output to 1080p? Or, should I keep it at 320x200 integer multiples such as (*5) 1600x1000?"

-- this one has been sitting on the rear of my mind for a while.

If you don't pick a 320 multiple resolution you will see some black space around the screen where it only stretched to the highest multiple that would fit I believe.

Best resolution would be 1600x1200. This way, each pixel can be cleanly transformed into a 5x6 block, respecting Doom's original aspect ratio (320x200 stretched vertically to fit a 4:3 screen).

Yeah, but then Chocolate Doom puts out a 1600 x 1200 block, which is scaled by the monitor to something that is no longer "cleanly transformed", as opposed to setting ChocoDoom to put out a 1080p image with a 1600x1200 block inside it, cleanly transformed.

edit: unless you are saying when the monitor stretches the image it will come out to be correct under 1600x1200? In that case you would need to make sure you set ChocolateDoom to not fix aspect ratio.

Honestly? If you want a "truly authentic" experience, play it on a CRT monitor in 320x200 mode, making sure it's displayed at the correct aspect ratio.

Otherwise, use one of the aspect ratio-corrected scaled-up modes. The higher resolution the better, but once you get past 800x600, it's diminishing returns and isn't likely to make a huge amount of difference. It's already pretty good even at 640x480.

The idea that 1600x1200 is "more authentic" than eg. 1280x1024 because you can do an exact scale-up, while being technically correct, in practise probably doesn't really make any real perceptible difference. The only thing really going for it is that you can use the scanline emulation hack if you want that.

DuckReconMajor said:

Yeah, but then Chocolate Doom puts out a 1600 x 1200 block, which is scaled by the monitor to something that is no longer "cleanly transformed",

No, I think you've misunderstood Gez's point. Doom is rendered at 320x200, but designed to be displayed on a 4:3 monitor. If you do an exact ratio scale up you get something like 640x400 (2x). But to display at 4:3 aspect ratio, it has to be stretched to eg. 640x480. At 1600x1200 you can do this "pixel perfect": 320 -> 1600 (5x) and 200 -> 1200 (6x). The lower resolutions work by interpolation between lines.

Ideally you'd want a monitor with a native resolution of 1600x1200 so the image can be properly upscaled and aspect ratio-corrected, which would also allow for the -scanline command to give you a genuine 320x200 CRT-like experience, but that (the scanline) is not going to look good on current LCD's or even Plasmas.

However, should you not be able to to find one of these monitors, I think Chocolate Doom could provide some sort of extra adjustable "canvas" resolution setting so to prevent cheap monitors from distorting the image.

fraggle said:

No, I think you've misunderstood Gez's point. Doom is rendered at 320x200, but designed to be displayed on a 4:3 monitor. If you do an exact ratio scale up you get something like 640x400 (2x). But to display at 4:3 aspect ratio, it has to be stretched to eg. 640x480. At 1600x1200 you can do this "pixel perfect": 320 -> 1600 (5x) and 200 -> 1200 (6x). The lower resolutions work by interpolation between lines.

Right, but the monitor isn't 1600x1200, so this "pixel perfect" image will be stretched, won't it?

Do any 1920x1080 monitors even let you use 1600x1200 as a display mode? My brother has a 1920x1080 and it certainly doesn't. (For myself, I have a 1920x1200)

At any rate, the ideal solution is to set Chocolate Doom to your native monitor resolution, but with an aspect-ratio corrected image. Lower resolutions like 800x600 or 640x480 can be tried if your computer isn't up to the task of the larger resolutions; lots of LCDs upscale these resolutions fairly badly, but as long as the game is relatively clear, it shouldn't be a huge problem.

DuckReconMajor said:

Right, but the monitor isn't 1600x1200, so this "pixel perfect" image will be stretched, won't it?

Yes, in a way that scales up exactly. That's the point.

All the other modes end up with fractional scales. For example: 640x480 (640 / 320 = 2, 480 / 200 = 2.4), 800x600 (800 / 320 = 2.5, 600 / 200 = 3). 1600x1200 scales up exactly in both dimensions (1600 / 320 = 5, 1200 / 200 = 6).

chungy said:

Do any 1920x1080 monitors even let you use 1600x1200 as a display mode?

Um... no, I wouldn't have thought so.

chungy said:

At any rate, the ideal solution is to set Chocolate Doom to your native monitor resolution, but with an aspect-ratio-corrected image.

True (at least technically!). Such an exact scale-up is what I am attempting right now. (Read more below.)

DuckReconMajor said:

If you don't pick a 320 multiple resolution you will see some black space around the screen where it only stretched to the highest multiple that would fit I believe.

I have picked 1920x1080, which is not a 320-multiple resolution.

Chocolate Doom then outputs at 1280x1000, which however is not, as Gez said, transforming "each pixel [...] into a 5x6 block, respecting Doom's original aspect ratio (320x200 stretched vertically to fit a 4:3 screen)."

In this case, it appears each pixel has been transformed into a 4x5 block, the resulting output ratio being 1.28 rather than the authentic 1.33 -- however, the difference is not significant, and the scale up is performed through integers.

The question is, desiring a native 1080p output: is this the best that can be accomplished? Or, am I missing something?

Alternatively, have you got any other ideas? etc.


EDIT:

Maes said:

IMO, the "best" that can be achieved is either letting the engine add letterboxing, or leave it up to the display to handle the stretching via hardware.

For it to be noted, I already am letting the engine put black bars on every side of the centered output -- the only way to respect integer scaling, as far as I am aware of.

I assume it's known by now that Medusa effect causes a fatal crash in Chocolate Doom, as opposed to the massive slowdown that would be seen in vanilla. If Medusa can't (or shouldn't) be emulated properly, it seems like there's got to be a better alternative to handling it than "Chocolate Doom totally explodes." But I'm not a programmer, so I wouldn't really know.

twipley said:

The question is, desiring a native 1080p output: is this the best that can be accomplished? Or, am I missing something? Alternatively, have you got any other ideas? etc.

1080p is just a much-hyped vertical resolution which has its roots as an integer multiple of the -theoretical- number of analog Standard Definition TV scanlines, aka about 540 depending on who you believe (PAL vs NTS vs SECAM etc.)

Computer displays had their own standards which followed much rounder multiples (of 192, 200, 240 or 256 for height), which have nothing to do with the TV-derived 1080 or any (sub)multiples of it. They are simply numerically incompatible and uncompromisable. Let alone that TV standards leave horizontal resolution undefined/implied by the useful bandwidth.

In order to fit a "1000p" display into 1080p at least height-wise, you need to do either a costly supersampling (LCM of 1000 and 1080 is 5400), or hack the engine as to render 80 extra scanlines e.g. draw a slightly larger view area with engine view angle stretching. IMO, the "best" that can be achieved is either letting the engine add letterboxing, or leave it up to the display to handle the stretching via hardware.

Maes said:
1080p is just a much-hyped vertical resolution which has its roots as an integer multiple of the -theoretical- number of analog Standard Definition TV scanlines, aka about 540 depending on who you believe (PAL vs NTS vs SECAM etc.)

I figured it was 1.5x720, and 720 is 1.5x480, and 480 is the number of visible scanlines on NTSC displays. ([offtopic]In analog-land it was around 486, but they rounded it to the nearest multiple of 16 to match the 16x16 block size of DCT-based encoders like MPEG2 and MPEG4. And since 1080 is not a multiple of 16, this means that most 1080p material is actually encoded at 1920x1088 with a flag to chop off the lower 8 lines.[/offtopic]) Or maybe 720=1.25x576 as used by PAL, I'm not sure...

At any rate, when I bought my monitor I made sure it was 1920x1200 so I wouldn't end up with some cheaply-made 1080p TV panel with the tuner left out. It could still be cheaply-made, but at least it's cheaply-made to be a monitor... This conveniently lets Chocolate Doom fill the screen vertically, which is arguably less accurate since the displayed area is over twice the size of the 14" monitor I originally played Doom on :-P

I also prefer the 1920x1200( 16:10 ) resolution.
From time to time I buy a cheap CRT(19"+) and for me this is the "ultimate" in Doom.

So fraggle, as far as I am able to see, Chocolate Doom tries to integer-scale the original resolution to the max vertically, and then checks how much to integer-scale it horizontally so as to most-closely attain 1.33?

Chocolate Doom can only scale up to certain fixed dimensions. These are the list of dimensions that are shown in the setup tool when the "Fullscreen" checkbox is disabled. When you run in fullscreen mode, it uses the largest of these scale-up dimensions that will fit within the screen resolution you're using.

fraggle said:

Chocolate Doom can only scale up to certain fixed dimensions. These are the list of dimensions that are shown in the setup tool when the "Fullscreen" checkbox is disabled. When you run in fullscreen mode, it uses the largest of these scale-up dimensions that will fit within the screen resolution you're using.

Oh! Thanks for the info, fraggle.

Then, which one of those would you think to best represent the authentic experience
(keeping in mind that the target monitor would be set to the 1920x1080 fullscreen mode):

- 1280x960: intended ratio (1.33); non-integer vertical scaling;
- 1280x1000: non-intended ratio (1.28); integer vertical scaling;

You're basically choosing between non-integer vertical scaling and non-integer horizontal scaling. 1280x960 is marginally better because it gives you the exact 4:3 aspect ratio but realistically it doesn't really make much difference.