evildragon Posted February 8, 2008 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? 0 Share this post Link to post
chungy Posted February 8, 2008 Your processor makes no difference at all. 0 Share this post Link to post
evildragon Posted February 8, 2008 Ok. Page 19 addresses why I have no music. Ironically it was me who brought it up. 0 Share this post Link to post
myk Posted February 8, 2008 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. 0 Share this post Link to post
Csonicgo Posted February 8, 2008 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. 0 Share this post Link to post
Graf Zahl Posted February 8, 2008 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. 0 Share this post Link to post
fraggle Posted February 9, 2008 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. 0 Share this post Link to post
fraggle Posted February 9, 2008 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. 0 Share this post Link to post
entryway Posted February 9, 2008 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 } 0 Share this post Link to post
evildragon Posted February 9, 2008 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... 0 Share this post Link to post
esselfortium Posted February 9, 2008 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... 0 Share this post Link to post
fraggle Posted February 9, 2008 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! 0 Share this post Link to post
evildragon Posted February 9, 2008 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? 0 Share this post Link to post
funduke Posted February 10, 2008 Hello! I found something, called "Strawberry DooM" here: http://sourceforge.net/project/showfiles.php?group_id=211429 It's obviously a variation of Chocolate DooM, but what are the differences? Greetings Funduke 0 Share this post Link to post
RazTK Posted February 10, 2008 There's an article about it on the Doom Wiki. 0 Share this post Link to post
funduke Posted February 10, 2008 Thank you for the fast info, RazTK! :) Greetings Funduke 0 Share this post Link to post
fraggle Posted February 11, 2008 evildragon said:I'm not having any video problems.. Did you quote the wrong person? Er, yes, sorry. That was meant for c.imp :-) 0 Share this post Link to post
Quasar Posted February 11, 2008 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. 0 Share this post Link to post
myk Posted February 11, 2008 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? 0 Share this post Link to post
andrewj Posted February 12, 2008 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). 0 Share this post Link to post
Never_Again Posted February 22, 2008 I was surprised to notice that Chocolate DOOM still suffers from the bug where skies don't change between episodes in DOOM2. 0 Share this post Link to post
exp(x) Posted February 22, 2008 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. 0 Share this post Link to post
fraggle Posted February 23, 2008 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. 0 Share this post Link to post
myk Posted February 23, 2008 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. 0 Share this post Link to post
fraggle Posted February 23, 2008 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. 0 Share this post Link to post
myk Posted February 23, 2008 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. 0 Share this post Link to post
fraggle Posted February 24, 2008 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. 0 Share this post Link to post
myk Posted February 26, 2008 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. 0 Share this post Link to post
entryway Posted February 27, 2008 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 0 Share this post Link to post
fraggle Posted February 28, 2008 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. 0 Share this post Link to post