The engine name in the configure.engine file was reverted to use
only ASCII characters. We cannot know what encoding will be assumed
by the terminal in which we run configure, so using non-ASCII
characters can result in unexpected results.
The engine and game name string literals in the source code were
changed to escape the non-ASCII character since there is no
guarantee that the compiler will assume utf-8 encoding for the
source code files.
The autosave refactoring that was done in
7adad5aaf5 used g_engine for identifying the
autosave slot. This worked for in-game save/load, but doesn't fit when
called from the launcher.
Fix by passing MetaEngine to SaveStateDescriptor ctor and using it for this
query.
Amends 7adad5aaf5.
This employs a "lazy" approach: the "format" for the credits stays
exactly as it was, i.e., perl code. Of course one may want to change
this to another format (e.g. YAML, JSON, XML; or also shell script or
AWK, like `configure.engine` uses). But I deliberately kept it simple,
to get a minimal change that is easy to verify. Any further changes to
e.g. the format can be layered atop this.
For each engine:
- Make a new folder detection
- Move detection-related files inside the folder
- Add a new module "enginename/detection"
- Add DETECT_OBJS here
- Adjust the normal engine module to remove detect_objs
- Adjust every file for the new changes.
Common::MacResMan is now able to open files from a specified
Common::Archive. This is a bit hacky as dynamic_cast is used to break
the Archive encapsulation to retreive the underlying FSNode. It should
however be more correct than the previous code that assumed files were
at the root of the currently running game's path.
AdvancedDetector constructs a Common::Archive from its FileMap based
filesystem cache and uses it to detect the mac resource fork files.
This cuts the time it takes to run the detection code with all the
engines enabled as dynamic plugins on the 3DS to 30 s from 280 s.
This removes filename methods when it matched the Engine method.
Secondly, ensuring there was an overriden getSaveStateName method
for engines that didn't do the standard target.00x save filenames
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.
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.
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.
op_getInventoryItem/op_setInventoryItem could operate on
inventoryItems[4] while inventoryItems has only 4 elements. This
effectively accesses the 'money' field right behind this array.
Due to a broken assert, this was never detected.
This commit fixes it by redirecting accesses to inventoryItems[4] to
money, and also fixes the assert.
An alternative solution would have been enlarging the array, and
removing the money field, but that would require more changes in the
engine.
