Its not caused by a bug in Doomsday - we can't fix it. Google "sdl_mixer midi volume windows" and you'll see countless reports of the same problem for all kinds of applications.
Our only real option for MIDI going forward is to look at entirely different solutions e.g., changing the volume of every note in the MIDI according to the user's volume setting or even manual synthesis.
Why does the beta6.4 midi volume work perfectly? All the other Doom ports seem to work just fine, too. If it's not a Doomsday issue, then why do only the last few beta releases have problems with the music volume?
Its a known problem in Windows Vista/7... I didn't notice that you are in fact using XP. In that case it is something we can fix - please submit a bug report.
Speaking of MIDI, and the ways that OS-level support is being reduced... It would be great if DE would allow selection of available MIDI output devices, and for a number of reasons.
The reason affecting the greatest number of users would be the fact that Vista and Win7 no longer provide a control panel interface for choosing the default MIDI device. This means even though a few modern sound cards (most X-Fi, as well as some cheap off-brand cards) have hardware MIDI synthesis available, most users will still get the crappy built in Windows software synthesizer. Almost anything sounds better than the Windows soft synth, and it also hurts performance a little.
Similarly, this would get around a problem with SDL's MIDI output under Linux etc. By default, SDL sends MIDI output to an ancient SDL-specific fork of TiMIDIty, which is woefully outdated and only supports GUS patches for the sound bank. My understanding is that SDL will likely never update to the newer, vastly improved TiMIDIty++ due to changes in the license. Ironically, the built-in SDL version of TiMIDIty doesn't even work in most Linux distros unless you've already installed that distro's stand-alone TiMIDIty package, making the SDL version not only lousy, but pointless and redundant as well. Allowing the user to specify an ALSA MIDI port (as done in SCUMMVM, for instance) would not only make it easier for users to get output from any hardware MIDI devices they might have, but it would also enable passing the MIDI music to modern builds of TiMIDIty (or Fluidsynth, if one prefers).
Is that a feature request that would be seriously considered if formally submitted?
It would certainly be considered if doable. However as yet I've uncovered no information at all about selecting the output device during SDL_mixer initialization.
The TiMIDIty option you speak of is a compile-time one and because the SDL_mixer interface is now part of the engine it would mean building multiple versions of the engine. Although since TiMIDIty is only really useful for *nix users, asking them to compile their own is a non-issue really.
BTW: Apparently it IS possible to change the default MIDI synth under Vista/7 but as you say, not via the control panel. As such we can't really recommend anyone do it but if you do want to - take a look at this thread on the vistax64 forums. Note that I've not yet tried this myself.
Hmm. I was thinking it had to be possible since ScummVM uses SDL and is able to do that, but at second glance, it looks like it might not be using SDL_mixer.
I'm aware of the registry hack for Vista, but I've not seen it tried in 7, and there seem to be complications in 64-bit versions. I'll experiment with it once I've got a card with hardware synthesis, which I'm hoping will be soon. Even if it works, that still leaves trouble in my preferred OS.
The Lost Souls seem to have some very odd clipping bugs in beta 6.8. Sometimes when attacking - they get stuck inside the player, and attack non-stop (you can't move when they are stuck inside you). This can kill you in seconds. I've seen them get stuck inside other monsters, and even a lamp at one point. The weirdest thing was that they somehow managed to attack me while I was against a wall, and knocked me outside the void. Yes, I was stuck outside a wall and couldn't get back. Clipping issues with Lost Souls seem to be very common, especially in cramped spots with other sprites.
The Cacodemons seem to have some clipping issues as well. In one of the maps I'm working on, I have 4 Cacodemons in a tight space next to each other. When they see me, then tend to move and get stuck inside each other. I saw 3 of them all stuck. This has never happened before. I know it's a Jdoom 6.8 beta issue, because it never happens in Zdoom or 1.8.6 of Jdoom. I assume that other monsters have these same clipping issues, since I've now seen it in two of them...
The same issue is present with all of the enemies as it is due to a problem in the common movement code. Its a known issue - there is already a report submitted at the tracker.
1. You can no longer sneak up on monsters while invisible. They still shoot in the wrong direction like they are supposed to, but in beta 6.8 they can see you from across the room instantly. You are supposed to be able to walk right up to them before they finally see you while invisible.
2. If I pull down the console while in the menu and type "warp xx", I get a segmentation violation every time. It seems that I have to start a new game first, then type "warp xx" in the console. This happens on a fresh installation of 6.8 with Doom2 (no addons or mods). This is what the end of the log says:
----------------------------------------------------------------------
DOOM 2: Hell on Earth
----------------------------------------------------------------------
Game state parameters:
>warp 05
Changing map...
P_LoadMap: "MAP05"
convertMap: Attempting conversion of "MAP05".
WadMapConverter::Convert: Attempting map conversion...
WadMapConverter::Convert: DOOM map format.
BSP_Build: Built 428 Nodes, 429 Subsectors, 2135 Segs, 1071 Vertexes
Balance +1 (l13 - r12).
Build subsector tables...
Build line tables...
convertMap: Successful.
R_InitLinks: Initializing
Map 5: The Waste Tunnels
Author: id Software
Segmentation Violation
1) There is no mention of this behaviour in the DOOM wiki Partial Invisibility article and I don't recall seeing any logic to support it in the source code. This should be checked in vanilla DOOM.
2) This is a known issue and is already in the bug tracker.
1. You can no longer sneak up on monsters while invisible. They still shoot in the wrong direction like they are supposed to, but in beta 6.8 they can see you from across the room instantly. You are supposed to be able to walk right up to them before they finally see you while invisible.
The ability to sneak up on monsters while invisible was a change ZDoom made to the behaviour. In the original Doom, all invisibilty does is make monsters shoot in the wrong direction.
The ability to sneak up on monsters while invisible was a change ZDoom made to the behaviour. In the original Doom, all invisibilty does is make monsters shoot in the wrong direction.
I guess my memory of vanilla Doom has faded over the years! I never thought Zdoom changed stuff like that, but apparently I was wrong. Sorry for the invalid bug reports then.
Are other people experiencing severe lag in Doom with beta6.8? Whenever I playtest some of the levels I'm creating, they run like a slideshow. I have one map that runs at about 20fps with every option I can find in control panel turned off, including dynamic lights. I'm not using any resource packs, either. It's just a bare Doomsday installation with Doom2.wad. At the moment, most of the levels I have created for my upcoming WAD are unplayable in Doomsday because of the lag. They run at 100% in Zdoom.
Is there anything I should experiment with to increase these speeds?
Edit: I tried with Doomsday 1.8.6, and got 40fps on the laggiest part, WITH all of the add-ons turned on (models, high-res textures, etc.). Will the betas ever be as fast as 1.8.6?
I tried with Doomsday 1.8.6, and got 40fps on the laggiest part, WITH all of the add-ons turned on (models, high-res textures, etc.). Will the betas ever be as fast as 1.8.6?
I'm pretty sure we've covered this a few times by now here on the forum. Basically 2.0 will ultimately perform considerably better than 1.8.6 At present though there are a few bottlenecks (temporary and necessary) that are having a very noticeable effect on performance.
I tried with Doomsday 1.8.6, and got 40fps on the laggiest part, WITH all of the add-ons turned on (models, high-res textures, etc.). Will the betas ever be as fast as 1.8.6?
I'm pretty sure we've covered this a few times by now here on the forum. Basically 2.0 will ultimately perform considerably better than 1.8.6 At present though there are a few bottlenecks (temporary and necessary) that are having a very noticeable effect on performance.
Hopefully 2.0 comes out before I'm finished with my project then! I've got about 20 levels left to complete, so it will be a looong time coming.
Comments
Our only real option for MIDI going forward is to look at entirely different solutions e.g., changing the volume of every note in the MIDI according to the user's volume setting or even manual synthesis.
The reason affecting the greatest number of users would be the fact that Vista and Win7 no longer provide a control panel interface for choosing the default MIDI device. This means even though a few modern sound cards (most X-Fi, as well as some cheap off-brand cards) have hardware MIDI synthesis available, most users will still get the crappy built in Windows software synthesizer. Almost anything sounds better than the Windows soft synth, and it also hurts performance a little.
Similarly, this would get around a problem with SDL's MIDI output under Linux etc. By default, SDL sends MIDI output to an ancient SDL-specific fork of TiMIDIty, which is woefully outdated and only supports GUS patches for the sound bank. My understanding is that SDL will likely never update to the newer, vastly improved TiMIDIty++ due to changes in the license. Ironically, the built-in SDL version of TiMIDIty doesn't even work in most Linux distros unless you've already installed that distro's stand-alone TiMIDIty package, making the SDL version not only lousy, but pointless and redundant as well. Allowing the user to specify an ALSA MIDI port (as done in SCUMMVM, for instance) would not only make it easier for users to get output from any hardware MIDI devices they might have, but it would also enable passing the MIDI music to modern builds of TiMIDIty (or Fluidsynth, if one prefers).
Is that a feature request that would be seriously considered if formally submitted?
The TiMIDIty option you speak of is a compile-time one and because the SDL_mixer interface is now part of the engine it would mean building multiple versions of the engine. Although since TiMIDIty is only really useful for *nix users, asking them to compile their own is a non-issue really.
BTW: Apparently it IS possible to change the default MIDI synth under Vista/7 but as you say, not via the control panel. As such we can't really recommend anyone do it but if you do want to - take a look at this thread on the vistax64 forums. Note that I've not yet tried this myself.
I'm aware of the registry hack for Vista, but I've not seen it tried in 7, and there seem to be complications in 64-bit versions. I'll experiment with it once I've got a card with hardware synthesis, which I'm hoping will be soon. Even if it works, that still leaves trouble in my preferred OS.
Should I submit these bugs or what?
1. You can no longer sneak up on monsters while invisible. They still shoot in the wrong direction like they are supposed to, but in beta 6.8 they can see you from across the room instantly. You are supposed to be able to walk right up to them before they finally see you while invisible.
2. If I pull down the console while in the menu and type "warp xx", I get a segmentation violation every time. It seems that I have to start a new game first, then type "warp xx" in the console. This happens on a fresh installation of 6.8 with Doom2 (no addons or mods). This is what the end of the log says:
2) This is a known issue and is already in the bug tracker.
The ability to sneak up on monsters while invisible was a change ZDoom made to the behaviour. In the original Doom, all invisibilty does is make monsters shoot in the wrong direction.
I guess my memory of vanilla Doom has faded over the years! I never thought Zdoom changed stuff like that, but apparently I was wrong. Sorry for the invalid bug reports then.
I'll go ahead and save everyone else the trouble:
http://blurredproductions.files.wordpre ... epalm2.jpg
Is there anything I should experiment with to increase these speeds?
Edit: I tried with Doomsday 1.8.6, and got 40fps on the laggiest part, WITH all of the add-ons turned on (models, high-res textures, etc.). Will the betas ever be as fast as 1.8.6?
Hopefully 2.0 comes out before I'm finished with my project then! I've got about 20 levels left to complete, so it will be a looong time coming.