AGS 3.3.0 Release Candidate

[Radiant]

Yes, I did. Could you please do something about this quirky bug?

(and if it's not very hard to make the close_mouth_end_speech work with voice samples, we'd highly appreciate it too!)

[Crimson Wizard]

Yes, I did. Could you please do something about this quirky bug?

Please, try to update this dll in AGS folder:
http://www.mediafire.com/download/8ypv9jha4jjg8b4/AGS.Native.dll

[Radiant]

That worked, thanks.

[Radiant]

Sorry to bother you, but there appear to be some other glitches with this build.

Game.SetAudioTypeVolume (eAudioTypeAmbientSound, x, eVolExistingAndFuture) doesn't work; ambient sounds are played at their normal volume regardless of this function call.

Game.SetAudioTypeVolume (eAudioTypeMusic, x, eVolExistingAndFuture) works but resets itself to full whenever a new room is entered. The same applies to eAudioTypeSound. Furthermore, both volumes reset to their normal (maximum) value as soon as speech begins, presumably since I've done Game.SetAudioTypeSpeechVolumeDrop (eAudioTypeSound, 0) at the startup of the game (the volume is set later as the result of moving a GUI Slider).

SetSpeechVolume (x) works, but if x == 0 then the speech is still audible, if very very soft. Mostly, it is noticeable to the player that something is being said.

Speech.PortraitY doesn't appear to do anything.

[Crimson Wizard]

Speech.PortraitY doesn't appear to do anything.

First of all, set Speech.CustomPortraitPlacement = true;

[Radiant]

Aha! I had forgotten about that part. Thanks, that works.

[Crimson Wizard]

Game.SetAudioTypeVolume (eAudioTypeAmbientSound, x, eVolExistingAndFuture) doesn't work; ambient sounds are played at their normal volume regardless of this function call.

There might be some difference of how audio types were differentiated in 2.72 and with newer audio system (since 3.2). I think that PlayAmbientSound (if that is what you use) does not really make a sound clip "ambient" in the AudioType sense. Instead, your particular sound clip must have a "Ambient" type set in its properties (or put into corresponding Audio folder with such property).
It also seems (from the quick glance into the code) that "old way" ambient sounds are controlled by SetSoundVolume, and only by that.

Actually, the new Audio System may be the main issue when upgrading to 3.2 and higher, you might need to spend some time adjusting your script to it.

Game.SetAudioTypeVolume (eAudioTypeMusic, x, eVolExistingAndFuture) works but resets itself to full whenever a new room is entered. The same applies to eAudioTypeSound. Furthermore, both volumes reset to their normal (maximum) value as soon as speech begins, presumably since I've done Game.SetAudioTypeSpeechVolumeDrop (eAudioTypeSound, 0) at the startup of the game (the volume is set later as the result of moving a GUI Slider).

This is strange, I don't experience such behavior... Maybe this is related to which script commands do you use to play music and sound...

SetSpeechVolume (x) works, but if x == 0 then the speech is still audible, if very very soft. Mostly, it is noticeable to the player that something is being said.

I can confirm this. It happens in 3.2.1 as well...


E: Now that I think about this, the demo you sent me before was done in 3.2.1 already? The sounds and music volumes seem to work properly there. Did you use different ways of setting them? Or it is the script that worked in 3.2.1 does not work in 3.3.0 anymore?
I am a bit lost, if you tried your game in 3.2.1 before, why are you upgrading from 2.72 again?

[Radiant]

Thank you for your response. May I make the feature request that if SpeechVolume is zero, speech is simply not played at all? It makes sense for players to try to disable speech by dragging the volume slider to zero.
(EDIT) Wait, never mind, I can fix that in code using SetVoiceMode ().

I can confirm that "old style ambients" are not affected by Game.SetAudioTypeVolume (eAudioTypeSound) either, and that using SetSoundVolume() does affect both regular sounds and old ambients, and that this function does not reset when changing rooms. Odd.

Regarding music, the only 'volume' commands in my script are as follows:

Code: ags

function game_start () {
  SetMusicMasterVolume        (80);
  game.speech_music_drop        = 0;
  Game.SetAudioTypeSpeechVolumeDrop (eAudioTypeAmbientSound, 0);
  Game.SetAudioTypeSpeechVolumeDrop (eAudioTypeSound,        0);
  Game.SetAudioTypeSpeechVolumeDrop (eAudioTypeMusic,        0);
  Game.SetAudioTypeVolume           (eAudioTypeMusic,       80, eVolExistingAndFuture);
  SetMusicRepeat              (1);
}

function interface_click (int interface, int button) {
  if (interface == CONTROLS) {
    if (button == 9) {
      Game.SetAudioTypeVolume (eAudioTypeMusic,        GetSliderValue (CONTROLS, 9),  eVolExistingAndFuture);
    }
  }
}

Then I play music with the PlayMusic(n) command. I note that simply invoking PlayMusic like that resets the volume (and indeed, it is called when I enter a new room). Is perhaps the issue that I'm using an old-style PlayMusic command with a new-style SetAudioTypeVolume command?

[Radiant]

Further investigation shows that setting System.Volume does work and doesn't reset when changing rooms, but it affects music and sound and speech all at the same time...

[Crimson Wizard]

Yes, messing old-style and new-style audio is not a good idea.

The PlayMusic calculates new music volume based on play.music_master_volume and room's music volume (old-style room property). It simply ignores new settings (AudioType volume).
This is done for compatibility with old games which did not know such settings.

I suggest you use either old music commands and settings, or only new ones, in most cases.



E: YUCK! Radiant's new avatar caught me off-guard.

[Radiant]

Ok, that's fair. I'm curious if there's some way to address the AudioClips as an array, e.g. music[30].Play() rather than aMusic30.Play()?

[Radiant]

Alternatively, I may just go back to using SetMusicMasterVolume() because my only issue with that was that it doesn't go down to zero. As you posted earlier,

Code: cpp

void SetMusicMasterVolume(int newvol) {
    if ((newvol<0) | (newvol>100))
        quit("!SetMusicMasterVolume: invalid volume - must be from 0-100");
    play.music_master_volume=newvol+60;
    update_music_volume();
}

I suppose the ugly but effective workaround would be to change "if (newvol<0)" to "if (newvol < -60)"    Then again, I don't think many people are interested in dragging a music volume to zero.

[Crimson Wizard]

Ok, that's fair. I'm curious if there's some way to address the AudioClips as an array, e.g. music[30].Play() rather than aMusic30.Play()?

Yes, it is a problem of new audio system...
Perhaps there might be a trick to deal with PlayMusic (I wonder will that work if you will set music master volume simultaneously with SetAudioTypeVolume?) Or maybe not???.
Other than that, you'll have to manually create and fill in a global array of music clips. Like:

Code: ags

AudioClip *MusicClips[100];

function game_start()
{
   MusicClips[0] = aMusic1;
   MusicClips[1] = aMusic2;
   // etc
}

Then you can use them:

Code: ags

MusicClips[30].Play();

[monkey0506]

This is getting off-topic, but the engine is already keeping track of all of the audio clips in an array. Is there any practical reason why this shouldn't be exposed to the user? Something like Game.AudioClips[] + Game.AudioClipCount would be extremely trivial to include. It might be worth considering introducing an Audio type, but I dunno. That's another topic.

Then again, I don't think many people are interested in dragging a music volume to zero.

I'd say that depends on the game and the player. I've played plenty of games with the audio completely muted while listening to my own music playlists. If the game has voice acting then I'm probably less likely to do that, but it can depend quite a bit on my mood as well.

[Radiant]

This is getting off-topic, but the engine is already keeping track of all of the audio clips in an array. Is there any practical reason why this shouldn't be exposed to the user? Something like Game.AudioClips[] + Game.AudioClipCount would be extremely trivial to include.

That would be nice to have

[Crimson Wizard]

This is getting off-topic, but the engine is already keeping track of all of the audio clips in an array. Is there any practical reason why this shouldn't be exposed to the user? Something like Game.AudioClips[] + Game.AudioClipCount would be extremely trivial to include.

Hey, this actually works .

Problem still is, though, that AGS editor does not let user to explicitly set audio clip's numeric id. This is all based on the order of import, therefore only relatively usable.

Also, AGSScript compiler fails to properly parse line like "Game.AudioClips[ i ].Play()":

room1.asc(17): Error (line 17): must have an instance of the struct to access a non-static member

This works:

Code: ags

AudioClip *clip = Game.AudioClips[i];
clip.Play();

In theory, you could have:

Code: ags

AudioChannel *PlayMusicNew(int index)
{
  AudioClip *clip = Game.AudioClips[index];
  return clip.Play();
}

Still, consider the problem with ids I mentioned above.
Well, let's continue this discussion somewhere else.

[monkey0506]

It's actually a long-standing issue in the compiler. If I knew what I was doing I'd love to see it fixed.

With no knowledge of what I'm talking about, I'd say that modifying the editor to allow assigning IDs for AudioClips should be relatively simple. But that's without looking at the code at all. I could take a look though and see what it would take. I gather this is something you want to go ahead and implement? There's some other information about the clips that the engine is keeping track of. Don't remember what...I was looking at it...before.

[Crimson Wizard]

With no knowledge of what I'm talking about, I'd say that modifying the editor to allow assigning IDs for AudioClips should be relatively simple. But that's without looking at the code at all. I could take a look though and see what it would take. I gather this is something you want to go ahead and implement?

Not sure I want to do this right away.
To keep things logical, we might as well allow to change id for other items, and this sounds like a serious change to editor gui.

[Radiant]

You can already change the IDs of sprites

Practically speaking, it'd be sufficient (for our project, at least) if importing a file named "Music###.ogg" automatically gives it ID ### in the editor (unless that ID is already taken, of course). I suppose a workable way of doing it would be to add a field 'ID#' to the properties, that rejects being changed to an ID that is already taken.

[Radiant]

Hm... I've created a test build of HQ on AGS3.3, and it turns out the music is really jumpy on Windows 8 machines, whereas in AGS3.2 it worked fine. This is not caused by system load or by antivirus software, and doesn't seem to occur on Win7 or on XP. Possibly this is because of the new music routines?