This raises the sound effect (SOUND_FX) channel group size from 5 to
21.
The rationale for this change is that the current SFX channel group size
is not enough in some situations (particularly during cutscenes and with
accelerated animations enabled), and decreasing the channel group size
for sound sources (currently 8, preserved as-is in this commit) doesn't
seem like the best solution at this point considering that the sound
source feature is neglected enough as it is. Three other channels are
reserved for the turn bell, turn timer countdown sound, and UI sounds,
and it'd be an even worse idea to drop those.
The SDL_mixer documentation suggests that increased mixer channel
allocations may be a memory usage concern with a high number of channels
("We're talking REALLY high!", their words), but hopefully this small
increase is good enough for our and the UMC making community's purposes
without impacting memory usage or performance on our main supported
platforms. At least Wesnoth's RSS didn't seem to change over a megabyte
when testing this patch on Linux (using ALSA).
Note:
Should this increased limit cause issues on some platform that matters
(hopefully not!) an alternative would be to reengineer the sound channel
selection done in sound::play_sound_internal() so instead of skipping
sounds when all channels are busy, the oldest playing channel is stopped
and reset to the requested sound, for channels in the SOUND_FX group.
However, this seems too complicated to do at this point for 1.12, so yet
another alternative would be to simply reduce the number of channels
reserved for sound sources and give those back to SOUND_FX.
For some reason, ~BG() used SDL_BlitSurface() directly instead of using
the alternate blit_surface() implementation, unlike every other image
path function type in existence that needs to do blitting.
This works the first time when scaling or cropping an image (say,
"misc/blank-hex.png~BG()~CROP(0,0,34,34)"), but the second time it's
used with different scaling/cropping parameters, it yields the result it
would without ~BG() in the pipeline. This is somehow remedied by this
change, and I don't see any potential issues arising from it anyway
(save for a negligible performance impact on ~BG(), maybe).
wesnoth.synchronize_choice checks the return value of toconfig fcn,
and if it indicated that it partially failed to convert the table,
it will chat a warning, IF wesnoth is running in debug mode
(that is game_config::debug = true, which is determined by e.g.
the command line flag --debug)
With this missing, certain combinations of actions/events would lead to
the ids of all CAs being dropped (e.g. in saves after using
[modify_ai]), which resulted in it not being possible to remove CAs any
more as that is done by id.
This fixes bug #21750.
Internally, the font_rgb="RR,GG,BB" specification for theme elements is
converted and packed into an unsigned 32-bits integer using the
0x00RRGGBB layout many SDL functions expect. However, for displaying the
unit status report we use ttext (the Pango+Cairo text rendering type),
which expects a different layout: 0xRRGGBBAA. This caused unit status
labels to lack a red channel value and use the blue channel as alpha.
Since the theme UI implementation ignores the alpha value by design (it
only expects three values), force alpha to be 0xFF and shift the color
value to the left so it matches ttext's expectations.
If I had to guess where this bug came from, I'd expect it was
accidentally introduced when converting the theme sidebar to use
Pango+Cairo since the font_rgb attribute seems to have gone unused and
undocumented for years.
