- Include it in intern.h, so everything functions normally.
- However, now we can include detection-related things from intern.h in other files, without including unnecessary things.
- Also makes it match other engine conventions.
- Engine files get a copy of detection_enums, while metaengine & detection.cpp get a copy of detection.h as well as detection_enums.
- Entire code was located in the main sword2.cpp file.
- Seperate detection-related code to detection.cpp
- Seperate other MetaEngineConnect related code to metaengine.cpp
- detection.h serves common code between the above files
- A enum value has been copied from sword2.h into the detection TU to avoid duplicate copy
- the detection.h has static function definitions for detecting games.
- This is because metaengine.cpp includes it & detection.cpp does as well.
- If we keep the methods as static, we can truely seperate out everything detection related.
- Move detection code used by createInstance & MetaEngine to a common header - detection_internal.h
- Move steam-related method & table to detection_steam.h
- More info in comments.
- Also, we remove the static keyword so other TU's can use the functions defined.
- This change has a catch.
- Because creating an instance depends on game detection code from detection.cpp, we cannot exclude it from Scumm.
- For Statically linked Scumm, we can simply exclude these detection files, because they're already being built.
- For dynamically linked Scumm, we can add it to our executable.
- Thus, for dynamically linked Scumm, one catch is that we have duplicated code (detection.o in our executable, as well as scumm.dll), but that shouldn't be a big problem considering the advantage it gives us: Detection without a plugin loading.
- MetaEngineConnect requires these at compile time.
- In order to avoid including everything from detect_tables, we just move the one thing we need into header, and include that in metaengine.cpp
- Also include it in detection_tables.h to restore orignal functionality.
- These structs are necessary for detection, as well as the engine itself.
- So, we move it to a common header file, include it once in both the files.
- This way, we won't have to include agi.h inside detection translation unit, which saves us much junk code going into the executable.
- Detection related code, and the class MetaEngine lives in detection.cpp
- Things which require the engine to be loaded, are in metaengine.cpp - the relevant class is called MetaEngineConnect.
- Update modules for the necessary changes.
- MEC: MetaEngineConnect.
- How do games handle save/load if MetaEngine (detection) is seperate from MetaEngineConnect (engine factory)?
- Most of the changes are quite similiar. ConfMan finds us the relevant MetaEngine, then simply use the new helpers from PluginMan.
- The new helpers will help convert a relevant MetaEngine into the other format or vice versa.
- Once the matching is complete, simply invoke functions by:
plugin->get<MetaEngineConnect>().engineMethod();
- Refer to previous commits to see the new class changes & notes.
- These include various functions and functionalities related to save/load.
- These are shifted, because the MEC class will house things that can be dynamic in nature.
- The MetaEngine class is fully & only dependent on ScummVM code, so it can always be built into executable.
- In runGame(), in main.cpp, we get a plugin of type MetaEngine.
- This MetaEngine cannot createInstances, but it just a helper class.
- Connect a MetaEngine class with it's factory class - MetaEngineConnect.
- Then, simply call the method.
- We have a default createInstance method overridden from MetaEngine from before in AME.
- So, just leave that as-is, and call the child class's function from there.
- Lastly, in AMEC - the generic createInstance is called, so we redirect it to call the one in the MetaEngine.
- Then, games can be run normally.
- Changed so we can get any type of plugins.
- This used to always return PLUGIN_TYPE_ENGINE.
- Because now we can differentiate between engines and metaengine, this must be changed.
- For now, return METAENGINE by default
- Do NOT use pluginMan and load plugins, etc, etc.
- Get MetaEngines from memory, since they're always built in statically.
- Use detectGames method to detect games.
- MetaEngines will now always go to the executable.
- But, because they still live in engine projects and are connected via a macro, they will need to be differentiated from Engines.
- This macro, and it's use in future will help in that.
Note: No detection objects added currently. It's just an empty variable uptill now.
- These DETECT_OBJS will be seen in action in the new commits
- They contain engine_name/detection.o
- They have MetaEngine code, which has detection features.
- This way, Executable will have linked against the detection.o files
- Detection.cpp files will be individually compilable and not dependent on engine
