- 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.
- 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.
- 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.
The commit had the effect of disabling update altogether as there is
no check for the _updates variable and anything that is not "yes"
disables updates. Instead there is a test for the _sparkle variable
(that is already set to auto by default).
The two variables exist because potentially we could use something
other than Sparkle for the updates.
Also the bug was already fixed by rootfather in commits f204867 and
2615c68 by making sure that _updates is false if _sparkle is false.
This reverts commit 581b4ca5947ced7c8db62147eafc54694d4a4f31.
It seems that theoradec is not necessarily always linked to an external ogg library
The (xiph) reference implementation depends on the ogg (xiph) library, but optimized versions for various archs (etc the theorarm) might not have this requirement. So better to not prevent enabling it, if the test is passed, even if in some cases it may result to linkage errors if ogg (external) was not enabled.