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

Chocolate Doom

Recommended Posts

myk said:

I'm sure fraggle can clarify this, but I don't see why it wouldn't work, as it's independent of true MIDI, and based on what's in SDL_mixer. The page says nothing about it lacking TiMidity support in Macs.

fwiw, i do have fully working sound.. midi is the only thing that doesn't work..

but perhaps it's because my Mac uses a PowerPC processor, and not an X86?

Share this post


Link to post

evildragon said:
Page 19 addresses why I have no music. Ironically it was me who brought it up.

But keep in mind TiMidity is not MIDI. It's an alternate way of playing MIDI files. What seems to be causing a problem is the native MIDI support (done through the Quicktime API).

Someone should test it and see. In Windows at least, all one needs to do is, after getting the patches, to place timidity.cfg in the engine's directory, and then edit that CFG file's path to the patches directory.

Though, if fraggle totally disabled music on Mac OS X in the source, it won't work unless it's enabled before compiling.

Share this post


Link to post
Graf Zahl said:

I doubt you will have any success with it. NVidia completely removed all support for low resolutions from their latest line of drivers.


Thanks for telling me. I won't be using NVidia anymore, that's for sure.

Share this post


Link to post

Not using NVidia anymore? Don't you think that you overreact a little?
Are there even any other applications aside from Chocolate Doom that have any real use for such resolutions? I can't remember a single post-Windows-95 game that did not make use of at least 640x480.

And I wouldn't expect ATi to keep support for these low resolutions for long. If NVidia thought it's be ok to remove support it's obvious that the reasons for that might apply to other manufacturers as well.

Share this post


Link to post
evildragon said:

fwiw, i do have fully working sound.. midi is the only thing that doesn't work..

but perhaps it's because my Mac uses a PowerPC processor, and not an X86?

SDL_mixer has native MIDI code for MacOS (as it does for Windows), but there is a bug that causes it to crash when playing music on a loop - when the music loops, the program crashes. To work around this, music in Chocolate Doom is disabled by default on OSX.

I think that the bug is a PowerPC / Intel compatibility bug and that the library hasn't been updated for the Intel Macs, so you may find that it works okay if you have a PowerPC Mac. You should be able to turn the music back on in the setup program.

Share this post


Link to post
c.imp said:

Then i use "SET SDL_VIDEODRIVER=directx" invironment variable.
And now:

2048 x 1536
1920 x 1440
1920 x 1200
1920 x 1080
1856 x 1392
1792 x 1344
1600 x 1200
1600 x 1024
1280 x 1024
1280 x 960
1152 x 864
1024 x 768
960 x 720
800 x 600
720 x 576
720 x 480
640 x 480
640 x 400
512 x 384
400 x 300
320 x 240
320 x 200
And the same list in FAR's fullscreen mode too.

entryway told me that it make that variable build in prboom+ code with simple OS kernel detection. If 9x kernel presents "SET SDL_VIDEODRIVER=directx" sets automatically.

But your one weeks old builds works without this! Only new build has broken detection of available videomodes under 9x and requires "SET SDL_VIDEODRIVER=directx" variable as prboom+ did some time ago.

ps.
Hmmm... maybe old choco builds just forcing "SDL_VIDEODRIVER=directx" like prboom+ did now, and in new version you disable this?

Ah, okay. The video mode detection code is dependent on the video driver used. I've only been testing this on Linux, so I hadn't noticed this.

Thanks, this is really useful.

Share this post


Link to post
fraggle said:

SDL_mixer has native MIDI code for MacOS (as it does for Windows), but there is a bug that causes it to crash when playing music on a loop

Also SDL_mixer causes application to crash from time to time on multicore systems. At least it's true for Windows. Prboom+ has process_affinity_mask variable and its value is 1 by default.

// Ability to use only the allowed CPUs
// For example it is necessary for buggy SDL_mixer (<=1.2.8 at least)
void I_SetAffinityMask(void)
{
#ifdef _WIN32
  if (process_affinity_mask)
  {
    if (SetProcessAffinityMask(GetCurrentProcess(), process_affinity_mask))
    {
      lprintf(LO_INFO, 
        "I_SetAffinityMask: manual affinity mask is %d\n",
        process_affinity_mask);
    }
    else
    {
      lprintf(LO_ERROR, 
        "I_SetAffinityMask: failed to set process affinity mask (errorcode: %d)\n",
        GetLastError());
    }
  }
#endif
}

Share this post


Link to post
fraggle said:

SDL_mixer has native MIDI code for MacOS (as it does for Windows), but there is a bug that causes it to crash when playing music on a loop - when the music loops, the program crashes. To work around this, music in Chocolate Doom is disabled by default on OSX.

I think that the bug is a PowerPC / Intel compatibility bug and that the library hasn't been updated for the Intel Macs, so you may find that it works okay if you have a PowerPC Mac. You should be able to turn the music back on in the setup program.

Oh it's disabled in the setup program? Ok, when I get home later I'll check it...

Share this post


Link to post
fraggle said:

SDL_mixer has native MIDI code for MacOS (as it does for Windows), but there is a bug that causes it to crash when playing music on a loop - when the music loops, the program crashes. To work around this, music in Chocolate Doom is disabled by default on OSX.

I think that the bug is a PowerPC / Intel compatibility bug and that the library hasn't been updated for the Intel Macs, so you may find that it works okay if you have a PowerPC Mac. You should be able to turn the music back on in the setup program.

This isn't an Intel-related bug, I remember Doomsday Engine had to work around it back in 2004 or 2005, long before Intel Macs existed. Their workaround was to export the music to a temporary .mid file and play it through Quicktime. Far from the best solution, but apparently the SDL guys don't feel like fixing this as it's been that way for four years now...

Share this post


Link to post
evildragon said:

Oh it's disabled in the setup program? Ok, when I get home later I'll check it...

I just committed a fix to svn, so you should get the correct video modes list now. It might take a while until a new svn build is uploaded; I don't know how RazTK's build system works.

entryway said:

Also SDL_mixer causes application to crash from time to time on multicore systems. At least it's true for Windows. Prboom+ has process_affinity_mask variable and its value is 1 by default.

I didn't know about this (I have a single processor machine). Thanks!

Share this post


Link to post
fraggle said:

I just committed a fix to svn, so you should get the correct video modes list now. It might take a while until a new svn build is uploaded; I don't know how RazTK's build system works.

I'm not having any video problems.. Did you quote the wrong person?

Share this post


Link to post
evildragon said:

I'm not having any video problems.. Did you quote the wrong person?

Er, yes, sorry. That was meant for c.imp :-)

Share this post


Link to post
esselfortium said:

...but apparently the SDL guys don't feel like fixing this as it's been that way for four years now...


I don't think they feel like fixing anything in SDL_mixer. It took about 3 years for MIDI volume setting to even work properly in Windows. MP3s are still broken and always will be. And as you're well aware, on your own machine it somehow loses the sound buffer and returns to us a bad pointer on which Windows will throw a write protection error part-way through.

Share this post


Link to post

Can't DOSBox's OPL3 emulation be somehow ported into SDL or directly to Chocolate Doom (and other engines)?

DOSBox is under the GPL, so there shouldn't be any license issues.

EDIT: Hmm... DOSBox itself uses SDL, so maybe some of the work is already done?

Share this post


Link to post
myk said:

Can't DOSBox's OPL3 emulation be somehow ported into SDL or directly to Chocolate Doom (and other engines)?

DOSBox is under the GPL, so there shouldn't be any license issues.

Depends. The original fmopl (0.37) is under GPL, but the better one (0.70) by Jarek Burczynski is under a different incompatible license.

SDL_mixer is a awful library, you are forced to use its mixing system even if you just want the music samples in a buffer to mix yourself. For EDGE I simply incorporated the timidity player code directly (with a LOT of code cleanup and some small fixes and improvements).

Share this post


Link to post

I was surprised to notice that Chocolate DOOM still suffers from the bug where skies don't change between episodes in DOOM2.

Share this post


Link to post
Never_Again said:

I was surprised to notice that Chocolate DOOM still suffers from the bug where skies don't change between episodes in DOOM2.

That's a vanilla bug, so don't expect Chocolate Doom to fix it.

Share this post


Link to post
Never_Again said:

I was surprised to notice that Chocolate DOOM still suffers from the bug where skies don't change between episodes in DOOM2.

This was actually fixed before the Doom source release, I explicitly changed it to work the same as Vanilla.

Share this post


Link to post

Fraggle, I just fixed the description of the bug in the Doom wiki, which was head over heels in relation to how the engine behaves. I didn't change the technical part, which may need updating, because I'm not sure how the mechanism works exactly in regard to the written code.

Share this post


Link to post
myk said:

Fraggle, I just fixed the description of the bug in the Doom wiki, which was head over heels in relation to how the engine behaves. I didn't change the technical part, which may need updating, because I'm not sure how the mechanism works exactly in regard to the written code.

I reverted your change because you had it backwards. If you use idclev to warp or load from a savegame, you get the correct sky for that level. It's only if you play through the entire game that you'll notice the bug - ie. the sky will never change from the MAP01 brown sky for the entire game.

Share this post


Link to post

fraggle said:
It's only if you play through the entire game that you'll notice the bug - ie. the sky will never change from the MAP01 brown sky for the entire game.

Perhaps my description could be fleshed out so people can't get confused, but on the other hand yours is plain wrong. Warping to a level will give you the right sky for that level, but once you get to the next section, the same sky will remain. The proper sky change only works if you start from the menu, otherwise the sky change is broken.

Try this; warp to level 11, and enter level 12; SKY1 is still used. The same happens to a "movie" recording of the whole game. Only the first sky is used. Or a recording of the second episode including the secret levels will use SKY2 for levels 31 and 32*. Likewise, if you jump to level 32 and exit, level 16 will display SKY3. But start a game normally from the menu, and play all the way to any level (12, 31, 21) and the skies will change as "intended".

By the way, Chocolate Doom seems to be working properly (as in my version).

EDIT:

* Actually, that's if you record from level 12 (technically the start of the 2nd section), COMPET-N starts the "second episode" from level 11, and as a result its movies of the "second episode" use SKY1 all the way through.

Share this post


Link to post

I think we're basically both saying the same thing, except for this -

myk said:

Perhaps my description could be fleshed out so people can't get confused, but on the other hand yours is plain wrong. Warping to a level will give you the right sky for that level, but once you get to the next section, the same sky will remain. The proper sky change only works if you start from the menu, otherwise the sky change is broken.

(Also, your version of the wiki article):
However, the sky is reset per section when the game is started from the menu, making the bug less obvious to more casual players.


This is wrong. It makes no difference whether you start with -warp 1 or whether you start from the menu with "new game" - the sky doesn't change when you get to MAP12. I just tried it myself and when I start on MAP12, I get brown skies.

The problem is that the sky is never updated when the level starts, only when the game itself starts (whether that is by the "new game" menu option, -warp, savegame load, or idclev). The sky will never change just as a result of transitioning between levels.

Share this post


Link to post

You're quite right. At some point I took the idea of the sky working properly from the menu for granted and didn't test that in particular (reminds me of when I answered a post assuming Doom can't play MIDI, and only MUS).

Check out the change I made to the wiki article's 3rd paragraph.

Share this post


Link to post

I have tried to compile chocolade-doom from SVN with vc2008 and got one billion errors and zillion of warnings. This is my patch for the latest revision: http://prboom-plus.sourceforge.net/choco_vc9.zip

before -> diff -> after

You can fix the rest six warnings himself

Also, I could not find
1) src\chocolate_doom_icon.c from ChocolateDoom.vcproj
2) data\chocolate-doom.ico from msvc\win32.rc

Share this post


Link to post
entryway said:

I have tried to compile chocolade-doom from SVN with vc2008 and got one billion errors and zillion of warnings. This is my patch for the latest revision: http://prboom-plus.sourceforge.net/choco_vc9.zip

before -> diff -> after

You can fix the rest six warnings himself

Also, I could not find
1) src\chocolate_doom_icon.c from ChocolateDoom.vcproj
2) data\chocolate-doom.ico from msvc\win32.rc

Thanks! I've applied your patch to svn. I use gcc for all my builds, so I don't really notice problems with the MSVC build.

Share this post


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