[Mac OS X] 3D audio and reverb, auto-aim bug; Xslimmer failing

edited 2012 Apr 16 in General
I was testing the latest version of Doomsday and I noticed in Mac OS X the "3D Sound" option in Mac OS X seems to be mostly fixed which is pretty cool. Although the reverb volume is way too high by default and kind of drowns out the sound effects. I set it to half the volume or a little less and it seems a lot better that way.

The only thing that would make the sound better is if there was a prologic spatialisation mode for sound effects like dakrplaces has. That would make the sound even more "3D". ;)

One odd thing to me though is at least the rocket launcher seems to auto-aim even if you have it off. The rocket launcher is one reason besides the fact that mouse-look is standard these days. I could be pointing the rocket launcher up at an angle but if a monster is below the rocket will angle down and hit the baddie or if they are on the sides from where I'm pointing it'll go to the sides almost like the drunk missiles in ROTT. I don't want this. :P

One more thing.. the 64-bit release doesn't seem like it's really 64-bit. What I mean is... I have eDuke32 and when I run it through xslimmer it slims it to a 64-bit only build but when I run Doomsday through it it shows up as 32-bit.

Comments

  • I was testing the latest version of Doomsday and I noticed in Mac OS X the "3D Sound" option in Mac OS X seems to be mostly fixed which is pretty cool. Although the reverb volume is way too high by default and kind of drowns out the sound effects. I set it to half the volume or a little less and it seems a lot better that way.
    I do the same. I think the default reverb strength needs to be set at 0.5
    The only thing that would make the sound better is if there was a prologic spatialisation mode for sound effects like dakrplaces has. That would make the sound even more "3D". ;)
    Doomsday already does do something similar but its not great in practice atm. We plan to address this with a sound grid in a later release.
    One odd thing to me though is at least the rocket launcher seems to auto-aim even if you have it off.
    There is a mixup in the menu presently in that it displays "autoaim: OFF" rather than "no autoaim: ON". Flip that option and it should work as expected.
    One more thing.. the 64-bit release doesn't seem like it's really 64-bit. What I mean is... I have eDuke32 and when I run it through xslimmer it slims it to a 64-bit only build but when I run Doomsday through it it shows up as 32-bit.
    Which version of Mac OS are you running?
  • I'm on Lion 10.7.3 on a Core i5 27 inch iMac.

    Yeah I set mine to about 0.5 as well.

    BTW, would that "sound grid" provide spatialization the way I'm talking about? What I mean is.... Darkplaces has a mode you can turn on in the sound where it encodes positional audio into the two channels so when it gets decoded by a pro logic sound processor you get 3D sound as in surround sound. Like when you pass by torches in quake they pan and fade to the correct speaker or if a character is shooting behind you you hear them shooting behind you... or to the left or right depending on where they are located in relation to you in the game.

    That type of mode is compatible with a wider array of computers than true multichannel surround. Especially on Mac. In order to get true mulitchannel surround with the few games that support it one has to have a mac that has a mini displayport and then hook that up to a reciever with an HDMI adaptor then switch to it via Audio MIDI setup then configure the number of channels in there. But many computer oriented sound systems only have optical cables and can only do 2 channel sound or passthrough DD from movies.

    It'd be nice for example for when an imp throws a fireball at you to hear it pan to a rear speaker and make an impact sound there.

    Darkplaces supports both prologic and discrete but I actually like to use their prologic mode more than their discrete mode since it also affects music not just environment sounds. The prologic mode is actually more consistent.
  • Ah I get what you mean. To offer a Prologic encoded output we'd have to implement a few configuration options, it should be possible though (FMOD supports it).

    I guess I am simply spoiled by my own audio hardware setup which dynamically encodes a 5.1 surround output for transporting to my surround amp (hence I've not missed it).
  • Yeah, I have two options on my system for 3D sound from games.

    A) The game supports true Multichannel sound via Uncompressed PCM via HDMI cable.

    B) The game supports encoding positional data to a prologic compatible downmix... and I have my optical cable selected in my receiver for two channel sound (and passthrough for anything AC3\DTS encoded).

    What you mentioned is Dolby Digital Live or DTS Connect which is not available to me.

    And like I said before I'd actually prefer option B because option A would be 1:1 to the speakers meaning the audio tracks would not get matrixed into surround sound.. only play form the front left and right. I'd be eternally grateful if you did implement a prologic compatible mix!

    About configuration options that reminds me how Darkplaces has the following:
    "snd_spatialization_control" "1"
    "snd_spatialization_max" "1"
    "snd_spatialization_min" "0.90"
    "snd_spatialization_occlusion" "3"
    "snd_spatialization_prologic" "1"
    "snd_spatialization_prologic_frontangle" "30"
    

    BTW, I tested to see if Doomsday would work in Uncompressed PCM mode via HDMI cable and it didn't.. it only played sound from the front left and right speakers.

    BTW, I got one more question... what's up with the HUD stretch option? I noticed it looks stretched if it's set to 0 and not stretched when set to 1 on my 16:9 display.
  • One more thing.. the 64-bit release doesn't seem like it's really 64-bit. What I mean is... I have eDuke32 and when I run it through xslimmer it slims it to a 64-bit only build but when I run Doomsday through it it shows up as 32-bit.
    Note that the actual Doomsday executable is called Doomsday.app and it's bundled inside the frontend, which is called Doomsday Engine.app.

    The 10.6+ build contains a Doomsday.app with x86_64 and i386 architectures. The frontend is always ppc+i386.
  • DaniJ wrote:
    I think the default reverb strength needs to be set at 0.5
    I agree. Overall the 3D sounds need lots of work, but we haven't gotten around to it yet.
  • Actually I knew that about the actual engine being inside the outside bundle which is the front end. But what I said still stands. It seemed like even that is actually 32-bit and not 64-bit. I even double checked to make sure I downloaded the version that says 64-bit on the DMG name.

    Well, I ran it through Xslimmer which removes "unneeded" architectures and languages from an app bundle and previously it seemed to make both 32-bit even though usually if an app has 32-bit and 64-bit it slims it to just 64-bit. However, I tried it again but this time I did the inner one first before doing the outer one and now the inner one (the engine itself) is just 64-bit.

    Well, that's interesting. With the binary slimmed to just 64-bit for the engine it fails to load, fmodex fails to load and it shows up as if there's no resources. If it slims it to just 32-bit for both then it works.
  • Well, that's interesting. With the binary slimmed to just 64-bit for the engine it fails to load, fmodex fails to load and it shows up as if there's no resources. If it slims it to just 32-bit for both then it works.
    Activity Monitor shows Doomsday being an "Intel (64-bit)" binary when running it, so it sounds like your Xslimmer utility is not processing the binary correctly.
    $ file Doomsday.app/Contents/MacOS/doomsday 
    Doomsday.app/Contents/MacOS/doomsday: Mach-O universal binary with 2 architectures
    Doomsday.app/Contents/MacOS/doomsday (for architecture x86_64):	Mach-O 64-bit executable x86_64
    Doomsday.app/Contents/MacOS/doomsday (for architecture i386):	Mach-O executable i386
    
    $ file dsFMOD.bundle/libfmodex.dylib 
    dsFMOD.bundle/libfmodex.dylib: Mach-O universal binary with 3 architectures
    dsFMOD.bundle/libfmodex.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
    dsFMOD.bundle/libfmodex.dylib (for architecture i386):	Mach-O dynamically linked shared library i386
    dsFMOD.bundle/libfmodex.dylib (for architecture ppc7400):	Mach-O dynamically linked shared library ppc
    
  • Well, for most other applications it works fine like when I run eduke32 through it I get a 64-bit only binary just fine. But not for Doomsday apparently.

    I did verify that the engine runs in 64-bit when untouched however. So, Doomsday will just have to be the one app so far I've added to its exclusion list for slimming.
Sign In or Register to comment.