I've just started using Chocolate Doom recently, and I think it is excellent! I'm definitely going to be using it for all of my vanilla Doom stuff from now on!

Question: If you had to estimate, how far off are we from a stable, full version of v2?

Share this post


Link to post

I have a question: how does Chocolate Doom render the screen, palette-wise? Does it display the RGB values in full 24-bit color, displaying the full range of 0-255? Or does it limit rendering to the VGA palette of RGB values being limited in the range of 0-63? And if it does quantize things into the 0-63 range, does it handle the rounding in the same way that the vanilla executable did? And does it multiply the VGA color values by 4.0 when rendering to the 24-bit plane, or does it adapt it in a different way?

Share this post


Link to post
Sodaholic said:

I have a question: how does Chocolate Doom render the screen, palette-wise? Does it display the RGB values in full 24-bit color, displaying the full range of 0-255?


Internally, Chocolate Doom handles palettes just like vanilla did. However, the way the image is displayed will depend on your choice of colour depth. It can output at 8-bit (originally what vanilla did), 16-bit or 32-bit. 32-bit looks exactly the same as 8-bit, but 16-bit isn't large enough to allow for a proper conversion so the colours will be noticeably off.

Sodaholic said:

Or does it limit rendering to the VGA palette of RGB values being limited in the range of 0-63?


The palettes themselves are definitely custom and fully 8-bit. There's a gamma shift bug in vanilla Doom (that's also replicated in Chocolate) which prevents the exact original colours from being used, but it's something so subtle you don't notice unless you're kind of looking for it.

Sodaholic said:

And if it does quantize things into the 0-63 range, does it handle the rounding in the same way that the vanilla executable did? And does it multiply the VGA color values by 4.0 when rendering to the 24-bit plane, or does it adapt it in a different way?


If any of this is true, we must have been living under different rocks. As far as I know, the only palette in an ID Tech 1 game that gets a similar treatment would be the 16 color one from Hexen's intro screen.

Share this post


Link to post
Sodaholic said:

And does it multiply the VGA color values by 4.0 when rendering to the 24-bit plane, or does it adapt it in a different way?

Multiplying by 4.0 is not accurate. 63*4=252; but 63 is the maximum and it should be 255.

A better approach is to use bit shifting like this:
r8bit = r6bit << 2 | r6bit >> 4;
g8bit = g6bit << 2 | g6bit >> 4;
b8bit = b6bit << 2 | b6bit >> 4;

So 00111111 becomes 11111100 | 00000011, or 11111111.

Share this post


Link to post
Gez said:

Multiplying by 4.0 is not accurate. 63*4=252;

In practice, nobody would not notice the difference (just a very slight dimming).

Share this post


Link to post
Sodaholic said:

I have a question: how does Chocolate Doom render the screen, palette-wise? Does it display the RGB values in full 24-bit color, displaying the full range of 0-255? Or does it limit rendering to the VGA palette of RGB values being limited in the range of 0-63? And if it does quantize things into the 0-63 range, does it handle the rounding in the same way that the vanilla executable did? And does it multiply the VGA color values by 4.0 when rendering to the 24-bit plane, or does it adapt it in a different way?

Up to and including the most recent release, the full 0-255 color range was used - this was fixed several months back.

Share this post


Link to post

AFAIK that's not what was done. To get this right you should do something like Gez described, i.e. copy the 2 most significant bits there.

I can remember years ago having problems with some old DOS-era images where the palette was converted by just shifting the 6 bit colors 2 bits left, leaving the 2 lowermost bits 0. It lookes slightly off.

It only got correct after copying the 2 uppermost bits into these empty bits.

Share this post


Link to post

In light of the recent "revelation" that chocolate-doom does not record vanilla demos just as vanilla did on start, will this ever be corrected?

Share this post


Link to post

I just noticed that the default.cfg file generated by the Chocolate Doom setup tool when settings are saved without modifying absolutely anything, actually differs from that generated by vanilla's under the exact same circumstances.

Besides the name of the file itself being in lowercase rather than uppercase, there's other details like the spacing between the settings and there values, missing settings, missing lines and even wrong values.

Actually, "wrong" might not be the most appropriate word to describe any of these differences as it's very possible that Chocolate Doom's generating the files the way some other (and if so, certainly older) version of the setup tool did.

I'm using the original Doom installations from ID Anthology (the second build with the fixed TNT/Plutonia games) as reference, the very last official DOS Doom bundle, and each setup tool from each of the games generated the same file with the same CRC32 (F7508002), so I think it would make sense to base the generated file on this particular version rather than something else.

Again, just a suggestion in the name of perhaps superfluous accuracy.

Here's the two cfg's for easy side to side comparison: http://depositfiles.com/files/bx1zhwvv1

Best regards.

Share this post


Link to post
Porsche Monty said:

I just noticed that the default.cfg file generated by the Chocolate Doom setup tool when settings are saved without modifying absolutely anything, actually differs from that generated by vanilla's under the exact same circumstances.

Besides the name of the file itself being in lowercase rather than uppercase, there's other details like the spacing between the settings and there values, missing settings, missing lines and even wrong values.

Most of this should be by design. The configuration files should be compatible between Chocolate/Vanilla but I don't consider it a bug if the files don't precisely match. For example, in Chocolate Doom's configuration files the values are aligned, while in the ones Vanilla generates, they aren't always aligned because tab characters are used. It looks nicer and doesn't affect compatibility.

It's also worth noting that, if I remember correctly, Vanilla Doom's setup tool adds a couple of parameters into the configuration file that the game discards - "comport" and another one that I forget. It's not worth supporting that.

EDIT: Just checked the config. These are the differences that I can identify:

  • Formatting / indentation (I explained above)
  • Inclusion of dummy variables 'showmessages' and 'comport': these aren't used: setup.exe adds them for some reason and Vanilla Doom strips them out when you run it.
  • snd_channels is 8 instead of 3, which is a more sensible default nowadays. snd_musicdevice defaults to 8 (General MIDI) which corresponds to native MIDI playback.
  • the other snd_ variables are zero by default (Chocolate Doom/Setup preserves them but doesn't use them at all).
  • chatmacro* has the proper defaults instead of "no macro"
  • The Vanilla setup file has some weird "0" line at the end.
All of this looks fine to me.

Share this post


Link to post

I am having an inexplicable problem with running a vanilla DooM map using Chocolate DooM. The game "crashes" while starting up, but there is no error message, and I know it's not a VPO error (which typically is identified when a map crashes). The crash occurs even when the player start is in a small, undetailed, enclosed space.

I thought it might be a problem with node building, and I've tried to build the nodes using different utilities, but the map does not start up at all.

The map is part of a multi-map wad, and the other maps start up and play just fine.

Is there a way to run a batch file to run the map, so that when it crashes I'll know what the cause is?

[Incidentally, the map plays just fine in GZDooM.]

Share this post


Link to post

Is it a very large map? You may have exceeded the blockmap limit.

Try dropping this config file into /Doom Builder/Compilers/Nodebuilders/ and picking "ZenNode - Vanilla Optimized" as your nodebuilder for vanilla-compat maps, and see if that helps. It'll compress the blockmap, among other things.

If that doesn't solve it, my usual troubleshooting method for maps that cause the game to quit for no apparent reason is to (after making a backup to be safe) try deleting about half of the map, loading it, seeing if it works or not, then undoing the deletion (of course) and either trying a different area if it still didn't work, or further narrowing down the problem area by testing with a smaller area deleted. Once you can get the problem area isolated, you can either find what's wrong with it or just redraw the room if necessary.

Recently I had this happen and the problem turned out to be a 1-sided line I had forgotten to delete in the void after reshaping some sectors.

Share this post


Link to post
esselfortium said:

Recently I had this happen and the problem turned out to be a 1-sided line I had forgotten to delete in the void after reshaping some sectors.

Don't advanced ports like PrBoom+ or ZDoom log warning messages about this kind of stuff?

Share this post


Link to post

A corrupted blockmap and single-sided linedefs with the two-sided flag set are two things that are liable to make Chocolate Doom crash silently.

Share this post


Link to post
Gez said:

Don't advanced ports like PrBoom+ or ZDoom log warning messages about this kind of stuff?

ZDoom use to crash, but apparently since 2.5.0 it shows the warnings in the console and the map is playable. Pr+ logs those warnings in stdout.txt.

Share this post


Link to post
Never_Again said:

and single-sided linedefs with the two-sided flag set


Do you perhaps mean a one-sided linedef without a front sidedef?

Share this post


Link to post
esselfortium said:

Is it a very large map? You may have exceeded the blockmap limit.

No, I ruled that out. The map has only 386 sectors, and 2,477 linedefs. Blockmap size is 13,146 bytes.

Try dropping this config file into /Doom Builder/Compilers/Nodebuilders/ and picking "ZenNode - Vanilla Optimized" as your nodebuilder for vanilla-compat maps, and see if that helps. It'll compress the blockmap, among other things.

I'm using zdbsp, and I looked at your parameters vs mine:

your parameters = "-c -o%FO %FI -X";
my parameters = -g -w

The key difference with my parameters is the absence of extended node building, and the presence of another set of GL-optimized nodes. I suspect that this ought not to be causing my problem.

If that doesn't solve it, my usual troubleshooting method for maps that cause the game to quit for no apparent reason is to (after making a backup to be safe) try deleting about half of the map, loading it, seeing if it works or not, then undoing the deletion (of course) and either trying a different area if it still didn't work, or further narrowing down the problem area by testing with a smaller area deleted. Once you can get the problem area isolated, you can either find what's wrong with it or just redraw the room if necessary.

This might be the only way for me to go, although Gez & ToD's suggestion about ZDooM logging any errors may provide a clue.

Recently I had this happen and the problem turned out to be a 1-sided line I had forgotten to delete in the void after reshaping some sectors.

I believe I can rule this out as well, but I'll take another look.

EDIT: GZDooM's log does not indicate any error. If it is indeed a corrupt Blockmap, is there an easier solution than trial-and-error?

Share this post


Link to post

Email me a copy of the map and I'll have a look at it for you.

Share this post


Link to post
Never_Again said:

...make Chocolate Doom crash silently...

Which it does because the SDL parachute is garbage.

I think it would benefit the Chocolate project greatly if it were to install a Structured Exception Handler (SEH) on Windows, as Eternity does, and disable the so-called parachute. This is what enables Eternity to pop up a crash reporter program containing the stack dump and other details when it has a problem.

Share this post


Link to post
TimeOfDeath said:

ZDoom use to crash.


Note: a crash is not the same as a controlled abort with an error message (which is what you got in this case.)

But yes, there's a workaround in place now because it was highly annoying that such maps couldn't even be analyzed in the engine without fixing them.

Share this post


Link to post
EarthQuake said:

Do you perhaps mean a one-sided linedef without a front sidedef?

No, that makes Chocolate Doom abort loading the level, with nothing relevant in stderr.txt or stdout.txt (whereas vanilla loads such a level with no complaints).

Quasar said:

I think it would benefit the Chocolate project greatly if it were to install a Structured Exception Handler (SEH) on Windows, as Eternity does, and disable the so-called parachute.

Indeed, at least in debug mode.

Share this post


Link to post
fraggle said:

Email me a copy of the map and I'll have a look at it for you.

Done, thanks.

Share this post


Link to post
ReX said:

Done, thanks.

I had a look at the level you sent me. The problem is that it has too many scrolling walls (78 of them). The Vanilla limit is 64 lines and the game crashes if you exceed it. I suggest you rework the level to make some of the lines non-scrolling.

Share this post


Link to post
fraggle said:

I had a look at the level you sent me. The problem is that it has too many scrolling walls (78 of them). The Vanilla limit is 64 lines and the game crashes if you exceed it. I suggest you rework the level to make some of the lines non-scrolling.

Easily managed. Many thanks for your help. I wasn't even aware of such an obscure limitation.

@duckreconmajor, it's not so much scrolling faces as much as scrolling skin walls on (at least one) complex shape. But what you said was funny. Sounds like the beginnings of a joke wad.

Share this post


Link to post
ReX said:

Easily managed. Many thanks for your help. I wasn't even aware of such an obscure limitation.


Doom is full of weird limits.

Share this post


Link to post

Just thought I'd make a note that after some hair pulling and source code reading I've finally got OPL3 pass through working on my Model 55 CMI8738 (Model's 37 and below still have the legacy ports at 0x388)

So here's the Gist of it, use cat /proc/ioports to find the base address of the card (in my case 0xe800) then add 0x50 to it (making 0xe850) plug that into chocolate-doom.cfg replacing the default 0x388 and start chocolate-doom with sudo /usr/games/chocolate-doom -iwad blah

Dunno how many other cards this will work on seeing as the ones with opl3 compatible ports on a very few and far between. This was done on

Mageia 2 Linux, x86_64 with a £3 generic Chinese cmi8738 5.1 card

(Other chip sets will need to be looked at to see where they place the ports in PCI address space)

Lemonzest/cow

Share this post


Link to post

My CMI8738-LX appears to be at e800 as well.
But no luck here on Windows 7.

Chocolate-Doom outputs this:
S_Init: Setting up sound.
IOperm_InstallDriver: ioperm driver installed.
IOperm_UnInstallDriver: ioperm driver uninstalled.
OPL_Init: Using driver 'SDL'.

Share this post


Link to post

have you edited fm_port=0xe850 to in chocolate-doom.cfg?

I get

I_Init: Setting up machine state.
NET_Init: Init network subsystem.
S_Init: Setting up sound.
OPL_Init: Using driver 'Linux'.
D_CheckNetGame: Checking network game status.

snd_samplerate 44100
opl_io_port 0xe850

^^ from my chocolate-doom.cfg file (had to edit it by hand)

I think on win you need some isport.sys from cygwin? does it work on 64bit windows?

Share this post


Link to post
Guest
This topic is now closed to further replies.