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.
- DataIO is a class that helps with fallback detection for MetaEngines.
- To prepare it for being included in the executable, get rid of unneeded engine dependencies & headers.
- A utility function is being used from util.cpp, simply prepare a static copy in fileio.cpp
- Leave a comment saying a copy is being used in util.cpp.
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.
When a user tries to add a game expecting it to be a particular
game for a particular engine, but a detector from another engine
happens to match some files that exist in the game directory and
reports on those files instead, this can cause a lot of confusion
because the detector doesn't say what engine or game it thought it
matched.
This patch adds the name of the matching engine as well as any
matching game IDs (if applicable) to the detector's logged output.
It also provides more specific guidance about where to send the
detection information (to the bug tracker), and properly wraps the
first part of the report to 80 columns.
Refs Trac#10272.
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.
Eugene Sandulenko
aryanrawlani28
Bastien Bouclet
trembyle
mataniko
Paul Gilbert
lawadr
Cameron Cawley
D G Turner
Martin Gerhardy
Colin Snover
Sven Hesse
Torbjörn Andersson