Baron of Hell
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Chocolate Doom
Pages (52): « First ... « 44 45 46 [47] 48 49 50 » ... Last »  
Author
All times are GMT. The time now is 12:40. Post New Thread    Post A Reply
Arjak
Mini-Member


Posts: 96
Registered: 08-07
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?
Old Post 04-14-12 01:40 #
Arjak is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Sodaholic
Banned


Posts: 2204
Registered: 04-07
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?
Old Post 06-04-12 20:48 #
Sodaholic is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Porsche Monty
Member


Posts: 456
Registered: 06-10
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.

__________________
Pirates are nothing but trash. Be a good citizen and support SOPA/PIPA.
Old Post 06-08-12 19:04 #
Porsche Monty is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 9148
Registered: 07-07
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.
Old Post 06-08-12 19:35 #
Gez is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
andrewj
Senior Member


Posts: 1515
Registered: 04-02
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).
Old Post 06-09-12 03:55 #
andrewj is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Super Moderator


Posts: 6568
Registered: 07-00
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.
Old Post 06-09-12 16:43 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7451
Registered: 01-03
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.
Old Post 06-09-12 17:18 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Csonicgo


Posts: 4304
Registered: 03-04
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?
Old Post 06-16-12 02:55 #
Csonicgo is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Porsche Monty
Member


Posts: 456
Registered: 06-10
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.

__________________
Pirates are nothing but trash. Be a good citizen and support SOPA/PIPA.
Old Post 06-18-12 15:13 #
Porsche Monty is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Super Moderator


Posts: 6568
Registered: 07-00
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.
Old Post 06-18-12 20:42 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
ReX
Senior Member


Posts: 1732
Registered: 05-00
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.]
Old Post 07-09-12 15:13 #
ReX is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
esselfortium
Cumulonimbus Antagonistic Posting


Posts: 5964
Registered: 01-02
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.
Old Post 07-09-12 18:37 #
esselfortium is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 9148
Registered: 07-07
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?
Old Post 07-09-12 19:11 #
Gez is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Never_Again
knows his birth month


Posts: 917
Registered: 04-03
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.
Old Post 07-09-12 19:30 #
Never_Again is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
TimeOfDeath
Forum Regular


Posts: 2009
Registered: 06-06
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.
Old Post 07-09-12 21:55 #
TimeOfDeath is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
EarthQuake
9.5 on the Richter!


Posts: 2824
Registered: 05-03
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?
Old Post 07-09-12 22:16 #
EarthQuake is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
ReX
Senior Member


Posts: 1732
Registered: 05-00
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?

Last edited by ReX on 07-10-12 at 14:07
Old Post 07-10-12 13:57 #
ReX is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Super Moderator


Posts: 6568
Registered: 07-00
Email me a copy of the map and I'll have a look at it for you.
Old Post 07-10-12 14:48 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 5148
Registered: 08-00
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.
Old Post 07-10-12 18:48 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7451
Registered: 01-03
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.
Old Post 07-10-12 18:53 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
TimeOfDeath
Forum Regular


Posts: 2009
Registered: 06-06
My bad, and thanks for adding the work around. :)
Old Post 07-10-12 20:45 #
TimeOfDeath is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Never_Again
knows his birth month


Posts: 917
Registered: 04-03
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.
Old Post 07-11-12 14:03 #
Never_Again is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
ReX
Senior Member


Posts: 1732
Registered: 05-00
fraggle said:
Email me a copy of the map and I'll have a look at it for you.
Done, thanks.
Old Post 07-11-12 16:18 #
ReX is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Super Moderator


Posts: 6568
Registered: 07-00
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.
Old Post 07-11-12 22:17 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
DuckReconMajor
Forum Legend


Posts: 4190
Registered: 01-09
lol ReX's level is World of SP_FACE1.
Old Post 07-12-12 00:00 #
DuckReconMajor is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
ReX
Senior Member


Posts: 1732
Registered: 05-00
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.
Old Post 07-12-12 16:04 #
ReX is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 9148
Registered: 07-07
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.
Old Post 07-12-12 16:20 #
Gez is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Lemonzest
Mini-Member


Posts: 62
Registered: 09-06
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
Old Post 07-16-12 09:20 #
Lemonzest is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Randy87
Mini-Member


Posts: 81
Registered: 05-05
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'.
Old Post 07-16-12 21:55 #
Randy87 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Lemonzest
Mini-Member


Posts: 62
Registered: 09-06
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?
Old Post 07-17-12 01:11 #
Lemonzest is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 12:40. Post New Thread    Post A Reply
Pages (52): « First ... « 44 45 46 [47] 48 49 50 » ... Last »  
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Chocolate Doom

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts 		HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.

Message Board Statistics