2 Suggestions: Audio and DrawingSurface

[Snarky]

If you normalized your audio to - 0.3dB maximum volume […] And then you would have to make all the other sounds more quiet, instead of simply turning that one sound up. Or obviously instead of doing that you will just turn the volume up in the audio editor, export and re-import it. But you will have to guess the right volume.

No, you can't really do that, because if the sound is normalized to -0.3 dB it's already (almost) as loud as it can get without clipping. You could play around with boosting only certain frequencies to make it appear louder, or boost the volume around the peaks (compression), but simply increasing the volume (amplitude) will cause clipping to some extent.

Wouldn't it be possible to use the same method as for turning the volume down in channels?

I'm not sure exactly what method you're referring to, but it would be possible to make it so that turning the volume of one sound above 100 actually just automatically reduces the volume of all the other sounds.

I'd think of it as having a game-wide property: MaxVolume, that is initially set to 100. And the actual volume that each clip is played at is the proportion of their volume level to this value (so Volume:50 is 50/100, or 0.5 of max). But if you set the volume of a clip above 100, let's say 120, the MaxVolume will automatically be increased to that value, and the effective volume of all clips is recalculated (so now Volume:50 is 50/120, or 0.42 of max).

You could object that this would suddenly make the volume of other things go down in the middle of the game, but you could make MaxVolume available in the editor, and set it yourself to the appropriate value so the volume is consistent throughout the game.

It would also be possible to code something like this up as a module.

Edit: Or there's the zero-coding approach: instead of playing all sounds at 100% volume by default, set the default volume to 50% and use that as your baseline for the audio mixing, which gives you room to boost the volume of particular clips if you need.

[Crimson Wizard]

@TheManInBoots, so , regarding the DrawImage/Surface problem.

I've read your last comment on that, and I still need to confirm something:

1. The game colour depth is 32-bit, correct (double checking)?
2. There's an option in General Settings - Visuals - Sprite alpha rendering style, is it set to "Proper Alpha Blending"?
3. What are sprite colour depths (I assume 32-bit too but double checking again), they are both imported with alpha channel preserved, and when you say that sprites have "transparent background", you mean it's alpha transparency, and not "magic pink" color in both of them?
4. When you created DynamicSprite from existing sprite (to use for Basesurface), did you provide preserveAlphaChannel parameter?

EDIT: Forgot to ask, but probably not important
5. which version of AGS were you using?
6. where is the final sprite applied to (room object?).


And another thing -

Notice that there is no problem whatsoever with it when I draw a surface with the ID 22 sprite as image unto that previous Basesurface.
The halftransparent parts of the original sprite are beautifully depicted without problem that way.

Again, to make sure I understand correctly, you did following:
- Get DrawingSurface from sprite 22; I assume you create a dynamic sprite from 22 first to do so?
- used Basesurface.DrawSurface( surface from 22 ) with some transparency parameter.


I'd like to underline, that DrawImage is already expected to do everything correctly if sprites have alpha transparency. So possibly what happened there is either mistake in your game or mistake in the engine.



UPDATE:
DrawSurface method is a separate issue here. I guess that this function is useful when you don't have an original sprite and surface comes from room background or similar thing. In that case you are stuck with this limited function, or have to copy surface onto a DynamicSprite first, which is an extra step and extra resource. So this request seem logical.

Something that bothers me, is that one will have to create DrawingSurface in order to paint room background somewhere first. So it's still one redundant step. I think, in the future it may be better to have a way of referencing room backgrounds and other similar non-standard images, directly, just like you reference sprite with slot ID. One of the options here is to actually assign a sprite ID to the room frame(s) and its masks. And maybe even handle these as regular sprites internally. Then everything will just go through DrawImage with no need to have duplicate methods.

[TheManInBoots]

No, you can't really do that, because if the sound is normalized to -0.3 dB it's already (almost) as loud as it can get without clipping.

Oh yes, I got that wrong.
I probably confused normalizing with mixing somewhere in there.

Edit: Or there's the zero-coding approach: instead of playing all sounds at 100% volume by default, set the default volume to 50% and use that as your baseline for the audio mixing, which gives you room to boost the volume of particular clips if you need.

That's a really great idea! Something I can implement right away, which will give me the playroom I need. It's good practice in pre-mastering to set all audio to -6dB to create more playroom for mastering, so setting the volume to 50% (depending on how AGS works with volume, if that's half the energy level, it would mean to -3dB) would do almost exactly that!
Thanks for the idea!

I'm not sure exactly what method you're referring to, but it would be possible to make it so that turning the volume of one sound above 100 actually just automatically reduces the volume of all the other sounds. [...] (so now Volume:50 is 50/120, or 0.42 of max).

That's exactly what I would be looking for.

You could object that this would suddenly make the volume of other things go down in the middle of the game

I would envision a module like that to register the maximum value used in the entire game from the very beginning on, and adjusting all audio right from the beginning to it.
Or maybe you can feed the module the maximum value manually with a function after you "mastered" all audio files, so all volume is correctly adjusted constantly.

Given the dampened enthusiasm I received for this suggestion I expect I will have to create this module myself.
Your module proposal, would it be possible using only standard channel functions, such as they are mentioned e.g. in the manual?
If I wanted to create the same thing, but so that you can actually change the default volume value of the audio file to more than 100 directly in it's property grid, would I have to learn how to create plugins?
Just theoretically, if I wanted to add a function that is able to read the actual dB level of the audio file in AGS, it would be over a plugin as well, correct?


Crimson Wizard,

It's one item of your checklist exactly.
When I imported the DynamicSprite from existing sprite I did not check preserveAlphaChannel as true.
That's the reason it did not work.
I assume you won't need too much information anymore.
But just a few details:
1-3: Check! Yes for all.
5:3.5.0.23
6: yes, on object.

For drawingsurface:
I created Basesurface from Dynamic Sprite, which was created from sprite 1.
Then I drew unto Basesurface the DrawingSurface called Imagesurface, which I created from a DynamicSprite, which again was created from Sprite 22. The original sprite 22 contained half transparent parts, so I did not add an additional alpha channel.

If you're for any reason still curious I can obviously tell you more.
That makes this part of the thread  possibly more suited for Beginner's Technical.
But I really thank you for your help!

One of the options here is to actually assign a sprite ID to the room frame(s) and its masks. And maybe even handle these as regular sprites internally. Then everything will just go through DrawImage with no need to have duplicate methods.

Sounds great! And useful

[Crimson Wizard]

It's one item of your checklist exactly.
When I imported the DynamicSprite from existing sprite I did not check preserveAlphaChannel as true.
That's the reason it did not work.

I feared it's the case.

Actually, I am now thinking to change the default value of preserveAlphaChannel to true for the next version, because it makes more sense this way, as it is not a common thing when you want to strip alpha transparency when cloning your sprite.

[TheManInBoots]

Yeah... seems more intuitive that way!