Recently we started to use this as new semantics, although in the past
we used simly <engine>_H. Now these guard defines are consistent with
rest of the files which are used in the engines.
Changing the language in-game causes the language to be set for the target in the
scummvm.ini file. Then the next time we try to start the engine, if was causing an error
(Sword25 failed to instantiate engine: Game data not found) because there was no match
for the path and language in the detection table. Setting the language to Unknown in
the detection table for this multilingual data file fixes the issue.
When selecting non-English language, the scripts default to using
German voices. This commit edits the file path on the fly to use instead
English voices for all languages other than German. This implements bug
#6804 - SWORD25: add option to choose language speech.
If the English voice pack is not present it falls back to using German voices.
The way this is implemented here however does not allow to use German
voices with English text or English voices with German text. This could be
achieved with a slightly different implementation of the same idea.
Some backends like GCW0 do no support graphics >320x240 due to
the hardware limitation (downscaling is possible but it will ruin
the pixel hunting which is often part of the gameplay).
Instead of manually updating the list of engines, we now introduce
a new dependency.
I marked all relevant engines, but some, like tinsel, require more
work with putting their relevant high-res games under USE_HIGHRES
define.
(Look https://sourceforge.net/p/scummvm/bugs/6980/)
The warning messages were appearing because when PRECACHE_RESOURCES is
not defined, ResourceManager's `requestResource()` was used to manually
"cache" them. When you do that, ResourceManager "locks" the resource
once, so you must `release()` it later.
Resources were not released, and warnings appeared. When you
`release()` resource, it still is loaded ("cached"). Resource's
`getLockCount()` is 0, though, so it might be unloaded by
ResourceManager if there is a lot of resources.
The original was ignoring Lua errors in that scene and was
restoring the state with longjmp.
We are yet to see the platform compatibility, but Lua's code
is too tangled to make simple replacement with error() work.
Another possible alternative would be to rework the original
game scripts. We will do it if this commit is problematic.
The call to lua_growstack in unpersistThread would unconditionally at
least double the size of the stack. This caused memory usage to grow
exponentially (literally) with the number of serialized threads.
Bugs #6977, #6999.
When using the constructor of Panel which directly calls unpersist _color was
uninitialized. However, unpersit uses setColor which assumes _color is
initialized properly. Caused valgrind warnings when loading.
