Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Janizdreg

Chocolate Doom

Recommended Posts

lucius said:

...emulating palletized textures on the GPU - which seems pretty useless to me if not trying to model the light attenuation. I suppose you can save some memory but it just doesn't seem worth the cost of a dependent texture read just for that.

Palletized textures wouldn't mean an additional dependent texture read. That bit was your idea (when a lookup for light attenuation came into the equation) :)

Share this post


Link to post
fraggle said:

Thanks for the all the comments, guys. It definitely seems like it would be a good idea to add an 8in32 mode like Eternity has. It should then be straightforward to choose different defaults for Windows Vista/7.

I've just committed this which adds a -8in32 command line parameter that I believe ought to behave the same as Eternity. For the time being you can only enable it from the command line, but I'll add it to the configuration file and setup tool later.

Share this post


Link to post

Not sure if it's a bug with Chocolate Doom or not, but I'm having a huge problem with SDL_Mixer, or whatever runs the music in Chocolate Doom. It seems to me that the game freezes for about a second whenever the music loops. I really wouldn't mind, but Vista seems to have very little patience for this --- sometimes the delay is so sever that it stops Chocolate Doom and claims it "stopped working" before closing it.

The strange thing is that I don't remember this happening before, and I've been running this on Vista with no problem since 2008 with no such problem.

Share this post


Link to post
Wagi said:

Not sure if it's a bug with Chocolate Doom or not, but I'm having a huge problem with SDL_Mixer, or whatever runs the music in Chocolate Doom. It seems to me that the game freezes for about a second whenever the music loops. I really wouldn't mind, but Vista seems to have very little patience for this --- sometimes the delay is so sever that it stops Chocolate Doom and claims it "stopped working" before closing it.

The strange thing is that I don't remember this happening before, and I've been running this on Vista with no problem since 2008 with no such problem.

Happens on both Windows Vista and 7. There is some type of thread contention or priority issue between the main application thread and the MCI event thread used by SDL_mixer to push MIDI events to the driver. I have been over their code and I cannot see whatever would be causing it - I wouldn't be surprised if it's a bug in the Vista audio stack causing it.

However the fact you get a crash ("stopped working" indicates an illegal operation occurred) sounds like you are also getting bitten by the SDL/SDL_mixer multicore processor problem. There is also, somewhere in the code, possibly in the same place, an issue which will crash if the SDL audiospec callback thread and/or the SDL_mixer MCI MIDI event thread AND the application thread are not all running on the same CPU core.

To fix that you need to look for the affinity mask setting in Choco Doom's configuration file and configure it to a positive value such as 1, 2, 4, etc. depending on the CPU core you want the program to execute on. "1" usually works for most people.

Share this post


Link to post

I guess a decent question on this subject is, has anyone tried to actually write midi handling for Windows platforms independent of sdl_mixer yet? There's a ton of ports that could use it. I know denis did it for OSX with Odamex, so I just find it odd that nobody has attempted it for windows.

Share this post


Link to post
fraggle said:

There is no such setting. Chocolate Doom sets the affinity to 1.

Well ain't I a stinker :P You realize that disables the ability to customize what core or CPU it executes on, right?

Share this post


Link to post
Ralphis said:

I guess a decent question on this subject is, has anyone tried to actually write midi handling for Windows platforms independent of sdl_mixer yet? There's a ton of ports that could use it. I know denis did it for OSX with Odamex, so I just find it odd that nobody has attempted it for windows.


How about ZDoom? It contains a full MIDI sequencer that can output either directly to a Windows device or use one of several software synthesizers. The code should be self-contained enough for addition to other ports. For the software synthesizers all it needs is the ability to stream sounds to the hardware which should be a feature of any semi-decent sound library. (Oh, and of course, it does not have any multicore crash issues. ;))

Share this post


Link to post
Quasar said:

Well ain't I a stinker :P You realize that disables the ability to customize what core or CPU it executes on, right?

Yeah, I guess. I'm not sure why you'd want to do that, though.

Share this post


Link to post

Is there any possible way to disable vsync in Chocolate Doom when using directx? I've run multiple tests, and it appears that vsync is always forced in this mode, which is causing serious framerate issues to the point that it's unplayable.

I can't use windib, because I get that god-awful palette glitch. Also, I've noticed that when attempting to play in either 1280x1024, 1400x1050, or 1680x1050 resolution, the screen is always letterboxed/windowboxed to 1280x1000. Is there any specific reason for this, or is this a bug?

Share this post


Link to post
Blondie said:

Is there any possible way to disable vsync in Chocolate Doom when using directx?


Yes, you should be able force it off from your video drivers.

Blondie said:

which is causing serious framerate issues to the point that it's unplayable


Vsync does not normally cause any framerate issues in Chocolate Doom, not even under Vista/7.

Blondie said:

I can't use windib, because I get that god-awful palette glitch


Try -8in32 on the command line. You'll need the latest svn build.

Blondie said:

Also, I've noticed that when attempting to play in either 1280x1024, 1400x1050, or 1680x1050 resolution, the screen is always letterboxed/windowboxed to 1280x1000. Is there any specific reason for this, or is this a bug?


How are you measuring this? the sensitive thing to do here would be disabling/enabling "correct aspect ratio" from chocolate-setuo.exe, but it could also be your monitor messing with the image.

Share this post


Link to post
Porsche Monty said:

Vsync does not normally cause any framerate issues in Chocolate Doom, not even under Vista/7.

You're right! I forced vsync off through the drivers (I forgot I had them set to enable vsync if the application lacked the option). However, turns out vsync wasn't the issue: I still get severe stuttering when playing at certain resolutions when using directx. Incidentally, this only seems to occur with resolutions where an image is pillarboxed, letterboxed, or windowboxed within another resolution. -8in32 seems to fix this, but the framerate appears noticeably reduced, even choppy, in 32-bit mode when compared to resolutions that don't exhibit the stuttering issue in 8-bit mode. Also, -8in32 seems to negate vsync entirely, even if I have it forced in my drivers' settings. I'm using XP32, if it makes any difference.

Porsche Monty said:

Try -8in32 on the command line. You'll need the latest svn build.

That corrects both the palette-lag bug and the stuttering bug, as far as I can tell, in both windib and directx. However, like I said, the gameplay seems noticeably choppier in 32-bit mode, though I'm willing to sacrifice if there is no other way around these bugs. Ironically, however, it now seems that even directx exhibits the palette glitch if -8in32 isn't used with the latest SVN, whereas it didn't occur before. This technically forces me to use -8in32, no matter what. Has the latest SVN introduced another bug?

Porsche Monty said:

How are you measuring this? the sensitive thing to do here would be disabling/enabling "correct aspect ratio" from chocolate-setuo.exe, but it could also be your monitor messing with the image.

Disabling "correct aspect ratio" merely renders the image widescreen, instead of 4:3. My monitor isn't the culprit. Chocolate Doom literally forces a 1280x1000 image within a 1280x1024, 1400x1050, or 1680x1050 resolution. During palette changes, the black borders from the letterboxed/windowboxed image illuminate, so it technically is rendered in the proper resolution, just not at the desired dimensions. Here's what it says in my stdout.txt:

I_InitGraphics: Letterboxed (1280x1000 within 1280x1024)

Share this post


Link to post
Blondie said:

I still get severe stuttering when playing at certain resolutions when using directx. Incidentally, this only seems to occur with resolutions where an image is pillarboxed, letterboxed, or windowboxed within another resolution. -8in32 seems to fix this, but the framerate appears noticeably reduced, even choppy, in 32-bit mode when compared to resolutions that don't exhibit the stuttering issue in 8-bit mode


So we have:

8bit + directx + vsync + boxed resolution = stuttery but full framerate?

32bit + directx + vsync + boxed resolution = no stuttering but reduced framerate? (-8in32's supposed to be slower, but not anywhere near this much, and normally you shouldn't have to enable it on XP anyways)

Blondie said:

Also, -8in32 seems to negate vsync entirely, even if I have it forced in my drivers' settings. I'm using XP32, if it makes any difference


I'm using the exact same OS and -8in32 does not interfere with vsync whatsoever. If it's indeed happening, it's likely to be your video drivers. Which video card/drivers do you have?

Blondie said:

Ironically, however, it now seems that even directx exhibits the palette glitch if -8in32 isn't used with the latest SVN, whereas it didn't occur before. This technically forces me to use -8in32, no matter what. Has the latest SVN introduced another bug?


Works fine here, no need for -8in32.

I can only suggest you make sure the refresh rate for whatever resolution you've chosen is 70khz, that should deal with some of the stuttering.

Share this post


Link to post
Blondie said:

Also, I've noticed that when attempting to play in either 1280x1024, 1400x1050, or 1680x1050 resolution, the screen is always letterboxed/windowboxed to 1280x1000. Is there any specific reason for this, or is this a bug?

Chocolate Doom can only scale the screen to a particular set of dimensions (the dimensions of windowed-mode windows). When you choose a fullscreen resolution, it picks the largest scale size that will fit inside the screen. For 1280x1024, that is 1280x1000.


However, turns out vsync wasn't the issue: I still get severe stuttering when playing at certain resolutions when using directx.

Which resolutions?

Blondie said:

-8in32 seems to fix this, but the framerate appears noticeably reduced, even choppy, in 32-bit mode when compared to resolutions that don't exhibit the stuttering issue in 8-bit mode.

32-bit is always going to be slower than 8-bit, because there's an extra conversion stage that needs to be performed. Best suggestion I can give you is to pick a lower screen resolution.

Share this post


Link to post
Porsche Monty said:

So we have:

8bit + directx + vsync + boxed resolution = stuttery but full framerate?

32bit + directx + vsync + boxed resolution = no stuttering but reduced framerate? (-8in32's supposed to be slower, but not anywhere near this much, and normally you shouldn't have to enable it on XP anyways)

Pretty much, yes, although the framerate is also significantly reduced in 8-bit directx mode with fullscreen boxed resolutions, and vsync can be subtracted, since that was ruled out as after disabling it within my drivers.

Porsche Monty said:

Which video card/drivers do you have?

Sapphire ATI HD 3850 AGP with Catalyst 9.12.

Porsche Monty said:

I can only suggest you make sure the refresh rate for whatever resolution you've chosen is 70khz, that should deal with some of the stuttering.

Tried it, but to no avail. I'm beginning to suspect that it's something hardware-related.

fraggle said:

Chocolate Doom can only scale the screen to a particular set of dimensions (the dimensions of windowed-mode windows). When you choose a fullscreen resolution, it picks the largest scale size that will fit inside the screen. For 1280x1024, that is 1280x1000.

Ah, that would indeed explain the letterboxing/windowboxing in fullscreen. Thanks for clarifying!

fraggle said:

Which resolutions?

The only resolutions affected are those that letterbox, pillarbox, or windowbox the game image in fullscreen, specifically 1280x1024, 1400x1050, and 1680x1050. And it only happens when using 8-bit directx mode. Maybe it's specific to my system?

fraggle said:

32-bit is always going to be slower than 8-bit, because there's an extra conversion stage that needs to be performed. Best suggestion I can give you is to pick a lower screen resolution.

Thanks for the suggestion. 800x600 in 32-bit windib mode works perfectly! Of course, it's a non-native resolution for my LCD, but you have to do what you have to do. Just out of curiosity, do you happen to know why 8-bit windib mode still exhibits the glitch that causes the game to briefly lag during palette flashes when grabbing items, taking damage, etc.? I only ask because I get the best performance with that mode, but can't make use of it due to the bug. I assume that it differs from each setup, depending on complications with SDL.

Share this post


Link to post
Blondie said:

Just out of curiosity, do you happen to know why 8-bit windib mode still exhibits the glitch that causes the game to briefly lag during palette flashes when grabbing items, taking damage, etc.? I only ask because I get the best performance with that mode, but can't make use of it due to the bug. I assume that it differs from each setup, depending on complications with SDL.


That lag happens in ZDoom Directdraw 8bit mode mode when using VSync and grabbing items/taking damage. It's because of the altered palette for those effects, some reason VSync can't cope with it, and I don't think a fix has been found, aside from switching to non-palettized effects/Direct3D. I similarly get great performance with this mode, and it's really annoying that this stutter exists.

Share this post


Link to post

This palette lag thing is as interesting as it is frustrating. Here's how my XP installation behaves (Chocolate Doom):

. Fullscreen without vsync = mild lag
. Fullscreen with vsync = very slight lag
. Windowed mode = no noticeable lag

Share this post


Link to post

I had THOUGHT this bug was fixed as of SDL 1.2.14 myself. The suspected culprit code was a bizarre and unnecessary conversion of the existing screen buffer contents into the new palette by use of a closest color match on every pixel whenever the palette was changed, in SDL's code.

SDL's DirectX code is bullcrap anyway. It's using the DirectDraw 5 API, which is beyond deprecated. It's a wonder it even manages to work at all.

SDL 1.3 has dropped this code entirely; it has been replaced with a Direct3D-based 2D-in-3D system IIRC. However SDL 1.3 seems to be in eternal beta, and it is also a new API, meaning no port can simply change to it by dropping in a DLL - it will require a new i_ backend to be written for each port that wants to upgrade to it.

Share this post


Link to post
Graf Zahl said:

How about ZDoom? It contains a full MIDI sequencer that can output either directly to a Windows device or use one of several software synthesizers. The code should be self-contained enough for addition to other ports. For the software synthesizers all it needs is the ability to stream sounds to the hardware which should be a feature of any semi-decent sound library. (Oh, and of course, it does not have any multicore crash issues. ;))


FMOD doesn't handle these events? Has ZDoom had this code since ZDoom 1.22?

Share this post


Link to post
Ralphis said:

FMOD doesn't handle these events? Has ZDoom had this code since ZDoom 1.22?



FMODEx does have its own MIDI sequencer. ZDoom can optionally use it as an external playback device.

Right now it has the following output options: Windows system MIDI device, FMod, Timidity++ (as an external program), OPL emulation, GUS (basically a heavily rewritten version of an older Timidity) and FluidSynth. For FMod and Timidity++ the internal sequencer is only used to convert non-MID formats like MUS.

Most of this code is far more recent than 1.22. That version didn't even have FMod support if I remember correctly. The MIDI code as it is now was only being done in the last 2-3 years.

Share this post


Link to post
Graf Zahl said:

Most of this code is far more recent than 1.22. That version didn't even have FMod support if I remember correctly. The MIDI code as it is now was only being done in the last 2-3 years.

ZDoom used something called "Midas" for the sound in Windows and only switched to FMOD with the 1.23 betas. The switch from FMOD to FMOD Ex was with v2.3.0.

Share this post


Link to post
Quasar said:

I had THOUGHT this bug was fixed as of SDL 1.2.14 myself. The suspected culprit code was a bizarre and unnecessary conversion of the existing screen buffer contents into the new palette by use of a closest color match on every pixel whenever the palette was changed, in SDL's code.

Unfortunately, it's still present, and quite noticeably, in Chocolate Doom's 8-bit windib mode, although the severity appears to differ between each setup. In my case, the bug is so pronounced as to render this mode entirely useless, because the constant intermittent pauses during palette changes halts fluid gameplay altogether. The inclusion of a 32-bit mode has nonetheless provided a workaround, though.

Share this post


Link to post

Update: on third check, you were right about -8in32 disabling vsync in DiretcX mode under XP, it deals with the palette lag but introduces tearing. What a complete joke. SDL is like the "Lada" of libraries.

Share this post


Link to post

I wouldn't be too quick to judge, as it may be my fault. I turned double buffering off for 32-bit mode, which may be the cause of the tearing.

You should keep in mind that this 8in32 stuff is new and hasn't had much testing outside the few people trying it in this thread. I'm relying on you guys to provide feedback.

EDIT: Latest SVN version uses double buffering, and I've also stopped borders from flashing in boxed screen modes.

Share this post


Link to post
fraggle said:

EDIT: Latest SVN version uses double buffering, and I've also stopped borders from flashing in boxed screen modes.

<3

Share this post


Link to post

I can safely confirm the double buffer fix works here, vsync is on again, and what a great idea 8in32 was! it fixes the palette problem for Vista/7 users, but more importantly, the palette lag for me :)

What I still don't get is the "slower" part. At least on my 3.0ghz + GF6200 + XP-powered machine, the performance drop is unnoticeable regardless of the resolution. Makes you wonder if it's something only Vista/7 users get.

There's at least 2 more issues (graphics-wise) that would be great to have investigated/fixed at some point, and one of them is the speed inconsistency during screen wiping. Some times it wipes normally, some times it's slow and stuttery just like it was on a 80386, but since I never figured out a way to reproduce it on demand, there's no proper bug report.

Share this post


Link to post

Well screen wipes are a tricky thing: as I understand it, you're copying a lot of data around in a way that really doesn't agree with the way modern CPU caches want to work.

In fact I'm gonna go ahead and take a guess: do you get slowdown when your screen resolution's width is a multiple of 512 or 1024 but not if it's 640 or 1280?

Share this post


Link to post
Porsche Monty said:

Actually I run Chocolate Doom at 320x200.


I'd love to know what Graphics card you have. modern ones cant go below 640x480.

Share this post


Link to post
Csonicgo said:

I'd love to know what Graphics card you have. modern ones cant go below 640x480.


As stated previously on this page, a GeForce 6200 is what's on my main PC.

Share this post


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