Since lua_pushlightuserdata and lua_touserdata operate on (void *)
values, it is tricky to fix these warnings "correctly" without looking
at invasive changes to a significant amount of Lua internal code.
Since these pointers to consts are already being recast to drop the
const qualifications, then removing the const on the underlying value
declaration does not further expose this to change and stops the
compiler warnings associated with this.
Anyone with a better fix for this can restore the const
qualifications later.
This flag is removed for a few reasons:
* Engines universally set this flag to true for widths > 320,
which made it redundant everywhere;
* This flag functioned primarily as a "force 1x scaler" flag,
since its behaviour was almost completely undocumented and users
would need to figure out that they'd need an explicit non-default
scaler set to get a scaler to operate at widths > 320;
* (Most importantly) engines should not be in the business of
deciding how the backend may choose to render its virtual screen.
The choice of rendering behaviour belongs to the user, and the
backend, in that order.
A nearby future commit restores the default1x scaler behaviour in
the SDL backend code for the moment, but in the future it is my
hope that there will be a better configuration UI to allow users
to specify how they want scaling to work for high resolutions.
This fixes tons of warnings with clang from a recent xcode version on
macOS (and possibly other systems) complaining that an instantiation
of _singleton is required but no definition is available.
This matches the behaviour of the Pluto rewrite Eris, and avoids
casting the integer indices to void *.
I verified this code by running this method in parallel with the current
lightuserdata/void* approach and asserting the retrieved objects were
identical when loading a savegame.
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.
