Chocolate Doom

[twipley]

twipley said:

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

fraggle said:

You're basically choosing between non-integer vertical scaling and non-integer horizontal scaling.

What are you meaning? I thought 1280/320 was giving out 4, therefore integer horizontal scaling in both output cases.

fraggle said:

1280x960 is marginally better because it gives you the exact 4:3 aspect ratio.

But then again, it features non-integer scaling, which, technically, is less authentic than "exact" scaling, is not it? So, how does that weigh less in the scale compared with non-authentic aspect ratios?

(I am just wondering really, more so than arguing for the direct sake of arguing.) -- twipley

[fraggle]

Oh. Yes, you're quite right. Sorry. Choice is between accurate aspect ratio or integer scaling. But again, I don't think it makes a huge amount of difference. I'd probably choose 1280x960 (correct ratio) myself.

[DuckReconMajor]

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.

This is what I was trying to say earlier, just in crappier words.

[twipley]

fraggle said:

I don't think it makes a huge amount of difference. I'd probably choose 1280x960 (correct ratio) myself.

Alright. Thanks for the input.

Perhaps using such high resolutions, the significance of performing whether integer scaling or not diminishes anyway; in perceptual terms, that is.

DuckReconMajor said:

This is what I was trying to say earlier, just in crappier words.

Indeed. I wonder how did I miss understanding that post to its full extent.

[twipley]

Sorry for the double post. -- (I would need a hand here, fellows!)

How I am supposed to run it in the 1280x960 centre area of a 1920x1080 output? To run it in a 1280x1000 area, I am using "-width 1920 -height 1080," but when I want to compare that in screenshot form to the former, I wonder if "-width 1280 -height 960" is what should be used in order to keep the native 1920x1080 resolution (and black bars) intact.

Another thing I am wondering about is how to take screenshots in order for resolution comparison to be made. I am able to "print screen" using 1280x1000, but using 1280x960 the taken screenshots for some reason contain heavy artifacts, which render the comparison impossible. I am not sure "-devparm" is of any help here, as the taken screenshots are limited to being quite of a low resolution.

[Porsche Monty]

Change the color depth to 32bit from chocolate-setup. That's one thing to try if you're getting artifacts with printscreen.

[twipley]

Porsche Monty said:

Change the color depth to 32bit from chocolate-setup. That's one thing to try if you're getting artifacts with printscreen.

Porsche Monty, you are right! Doing so (wonderfully!) fixed the issue.

fraggle said:

Choice is between accurate aspect ratio or integer scaling. But again, I don't think it makes a huge amount of difference. I'd probably choose 1280x960 (correct ratio) myself.

I have done some tests, and I think the difference is way more perceptible if using a non-standard aspect ratio such a 1.28.

the best thing for 16:9 1080ps might therefore be running a 1280x960 rectangle output inside a 1920x1080 whole-screen output.

How would one be supposed to do so, though? "-width 1280 -height 960" switches the screen resolution to the latter non-native value, while what is looked for is maintaining the native 1920x1080 resolution.

[twipley]

Well since, as Mr. Duck Major as put it,

DuckReconMajor said:

if you don't pick a 320 multiple resolution you will see some black space around the screen where it only stretches to the highest multiple that would fit,

and if there is no way for one to use the 1920x1080 native resolution in combination with a "1280x960" output instead of a "1280x1000" one,

could a feature request be proposed? It would indeed be nice, in my opinion, to make that possible, for example through "-geometry 1280x960 -width 1920 -height 1080," or something to that effect.

Would that be something you would find worthwhile to implement, fraggle? I imagine such features may take a lot of fiddling around to code, test, and implement, but still, what do you think?


-- as a due compensation for the double post, here is a bug report:

Import the first registry key, then problems will happen on firing up the game, then import the second to fix it back.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Console\%SystemRoot%_system32_cmd.exe]
"FullScreen"=dword:00000001

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Console\%SystemRoot%_system32_cmd.exe]
"FullScreen"=-

(Note that I am unable to reproduce this issue, which I had last year, though. In other words, when one sets the Windows-XP "console" to fire up in fullscreen mode from its properties dialog, a flag is added that made Chocolate Doom unable to start up properly. The bug may have been fixed already, but I am pretty sure it was affecting me in v1.5.0 using "-width 1920 -height 1080" under my back-then platform configuration. Hope this can be of any help. Probably an overall-insignificant and -incomplete bug report, though -- sorry about that!)

[fraggle]

twipley said:

could a feature request be proposed? It would indeed be nice, in my opinion, to make that possible, for example through "-geometry 1280x960 -width 1920 -height 1080," or something to that effect.

Would that be something you would find worthwhile to implement, fraggle? I imagine such features may take a lot of fiddling around to code, test, and implement, but still, what do you think?

It's a slightly obscure thing to want control over, but it can certainly be done. I'd probably do it as a "hidden" config file variable - rather like, for example, the autoadjust_video_settings variable.

(Note that I am unable to reproduce this issue, which I had last year, though. In other words, when one sets the Windows-XP "console" to fire up in fullscreen mode from its properties dialog, a flag is added that made Chocolate Doom unable to start up properly. The bug may have been fixed already, but I am pretty sure it was affecting me in v1.5.0 using "-width 1920 -height 1080" under my back-then platform configuration. Hope this can be of any help. Probably an overall-insignificant and -incomplete bug report, though -- sorry about that!)

Thanks for the report, can you please file it as a bug via the bug tracker? When people send me bug reports by forum posts or emails they tend to get lost and forgotten about.

[twipley]

fraggle said:

It's a slightly obscure thing to want control over,

Indeed, it's quite obscure a thing to want control over, but at the same time it's the only way for some to maintain the aspect ratio (which can be quite a perceptible thing) while also maintaining the native monitor resolution.

I wrote "for some" as for some people, it seems the graphics drivers are not in a position to add the black bars by themselves, and thus need to rely on the software to maintain the native monitor resolution.

fraggle said:

but it can certainly be done. I'd probably do it as a "hidden" config file variable.

I am definitely staying tuned for this one. I agree with the "hidden" part of it, but at least it would be there for those who need it.

Thanks in advance for keeping this suggestion into consideration, fraggle. You said in an interview you would not know what features will reveal themselves in need of being implemented in the future, and I believe this one is one of them. <(+_+)>

fraggle said:

Thanks for the report, can you please file it as a bug via the bug tracker? When people send me bug reports by forum posts or emails they tend to get lost and forgotten about.

Sure thing. [Done.]

[twipley]

Well, I am feeling slightly uncomfortable monopolising the thread as I feel I am now doing, but let me do so for be it just a brief moment.

Let the choice now be made between, quote unquote, "non-integer vertical scaling and non-integer horizontal scaling," although both resulting in the intended aspect ratio. That would bring us to either:

- 1333x1000 (integer-scale-factor vertical scaling);
- 1280x960 (integer-scale-factor horizontal scaling);

I think those might be two interesting outputs to a 1920x1080 monitor.

"Which one, though, would be better than the other?"

EDIT: I think the answer to this question might be to go with the 1333x1000 one, because, on the one hand, it is bigger, and, on the other (although I am not sure if that matters at all), it "preserves the scanline structure."

EDIT2: I have been thinking about it, and would not it be better to just, upon entering the full-screen mode, integer-factor scale it to the most on the vertical axis, then stretching the horizontal axis so as to reach the intended 4:3 ratio? It seems to me the best that could be done about it, in terms of mimicking the original Doom experience. I know there were not any black borders back then, but hey! (What could one ever do about it anyway.)

[fraggle]

Just a heads up to anyone running a dedicated server (and I know there are several people doing this). The master server has changed IP address, so you will need to restart your servers to pick up the change. Incidentally, I've submitted a fix so that this hopefully won't be necessary in the future, but that change isn't part of any release yet.

[Porsche Monty]

Not sure if this is supposed to happen for whatever reason but the doom-v2-win32 zips are missing the executables since r2496.

http://people.oregonstate.edu/~delbelb/chocolate-doom-v2-win32/

[exp(x)]

Porsche Monty said:

Not sure if this is supposed to happen for whatever reason but the doom-v2-win32 zips are missing the executables since r2496.

http://people.oregonstate.edu/~delbelb/chocolate-doom-v2-win32/

I'll take a look at my build logs.

[Porsche Monty]

Sorry about sounding pushy, but any updates on this?

Regards.

[exp(x)]

I took a look at it briefly, but wasn't able to fix it. I think there is a problem with my build environment. Unfortunately it's not a high priority for me right now, so I don't know when I'll get around to fixing it. If you need a particular build, I'm sure someone else will be able to make one for you if you ask.

[Porsche Monty]

I don't really need any of these builds in the strict sense of the word, but I do enjoy playing with new features and fixes not yet available in the official releases. They're also great for helping developers spot the occasional bug introduced during development cycles.

Anyways, thanks for having looked into it.

[chungy]

I'll try to make a build when I get home later today if no one else has.

[axdoomer]

I already did a build of r2503 for Windows using CodeBlocks:
http://www.mediafire.com/?cbixn663pyut1a5

[Porsche Monty]

I actually managed to build it myself, but it suffers from the same problem as yours: "I_SDL_InitSound: use_libsamplerate=5, but libsamplerate support not compiled in"

[chungy]

I've taken a bit of a stab at it but I'm having trouble building libsamplerate under mingw32 (I'm on Linux)...

[Porsche Monty]

Wish someone would do whatever's necessary to allow Chocolate Doom v2 to be built without the bloating debug crap and the libsamplerate thing on by default. There's several lines in the script that suggest this could be accomplished with certain switches, but it's still more confusing to me than I'm happy to admit.

Such an embarrassment.

[chungy]

Well I already could build it without libsamplerate if that's what you want. As for the debugging information, run strip on the binaries afterwards ...

[Porsche Monty]

Actually libsamplerate is exactly the reason I was using exp(x)'s binaries rather than mine.

Thanks for the tip on removing the debug stuff, though.

[exp(x)]

My builds are working again. I deleted the bad zips and am letting my script catch back up to the current revision. You may want to double check the new builds.

[Porsche Monty]

Everything's back to normal it seems. Thanks for that :)

[Janizdreg]

exp(x), it looks like the university deleted your account (or gives a 404 for some other reason). If this is indeed the case, do you have an alternative webspace available where you could store the builds?

[exp(x)]

There was an unexpected power outage in the building that houses that server. It's only a temporary issue.

http://intranet.net.oregonstate.edu/blog/archives/3486

[entryway]

Chocolate-doom forgets to overwrite plyr->mo->health variable with deh_god_mode_health in cheat_god()

Dehacked overwrites both values: plyr->mo->health and plyr->health

From dehacked/data.h

long miscoffs[22][NUMVERS] = {
...
0x759E3L, 0x75963L, 0x759C3L, 0x7BB63L, 0x7BEA3L, // godhealth
...
0x759EFL, 0x7596FL, 0x759CFL, 0x7BB6FL, 0x7BEAFL, // Godhealth

Load this deh with Chocolate-Doom

Doom version = 21
Patch format = 6

Misc 0
God Mode Health = 166

Load any level, type IDDQD twice. Now you will die when your health becomes below 66%. Works correctly with doom2.exe

Also you can compare DOOMHACK.EXE и DOOM2.EXE
0007BB63: A6 64
0007BB6F: A6 64

[neubejiita]

http://svn2.assembla.com/svn/pedroduarteps2dev_public/lsdldoom_PS2/trunk/src/qmus2mid.c

This seems to be the qmus2mid source. I hope this is helpful somewhat.