When detection is in dynamic plugin, the detection tables are included
twice. Once in the detection plugin and once in the engine for the game
scanner code.
We disable the feature in this case to prevent duplication as this
feature is only used in specific cases.
The engine is capable of rendering to any 16 bit or 32 bit format,
but the format conversion has a cost. This commit assumes that any
conversion that the backend may need to do would be at least as
efficient as the conversion that would be done in the engine, so
we select the best format for the engine that is supported by the
backend. There are three categories of formats:
1. The one used internally by the engine. When also used for the
backend we can do direct rendering.
2. For 32 bit games, two additional formats for which there is
an optimized color conversion.
3. Any other 16 bit or 32 bit pixel format, for which we have
generic color conversion.
Profiling with two games shows the following improvments:
- If we can use the internal engine format, we gain between 3%
and 5% compared to the next best formats, and between 11% and
14% with other formats.
- Otherwise if we can use the next best formats we still gain
between 6% and 11% over other formats.
If it's done in the constructor it's not possible to use extrapath, and
that may cause problem, e.g if people want to use the MT-32 emulator
for games that use MIDI music.
These are emitted by GCC when -Wundef is passed.
The AGS_PLATFORM_DEFINES_PSP_VARS may have previously caused those variables
to be present since undefined macros are assumed to be 0, thus the test would
have passed.
I tried once again to refactor the AGS codebase to use an RGBA
format that can directly blitted to the screen for performance,
but once again couldn't locate all the places that assume that
specific pixel format. So to at least provide some optimization,
I've implemented two fast for loops that handle converting the
AGS surface pixels to RGBA or ABGR for rendering
The AGS engine does not supports this and has a check when
saving that errors out when trying to save during a non-blocking
event (see can_run_delayed_command() call at the start of
save_game()). There is no such check when loading, but it
causes a crash. This can easily be reproduced in QfGII.
I experimented, but couldn't get the AGS in-game volume
controls to map to the ScummVM volume controls. The reason
being that the games frequently set the volume during their
startup, sometimes multiple times. The best I could do was
set up the different sound types in AGS to use the
Audio::Mixer::SoundType enum, so that any ScummVM volume
control will be respected in addition to the AGS volumes.