OpenXcom Forum
Contributions => Builds & Ports => Topic started by: macifom on October 09, 2020, 04:27:54 am
-
Greetings fellow X-Com enthusiasts,
First of all I'd like to thank SupSuper and all of the other contributors to OpenXcom for making one of the greatest PC games of all time accessible to players young and old on new platforms. I recently, for solace and distraction, shifted much of my computer usage back to an ancient Power Mac G4. One of the complaints most commonly leveled against that generation of Macs was the dearth of games and no omission could be more painful than your favorite and mine, X-Com UFO: Defense. I regularly play OpenXcom on my Linux box and was surprised when I couldn't find a PowerPC Mac build anywhere. Over the weekend, I decided to personally address this oversight. The result, after struggling mightily with issues arising from the obsolescence of the platform, is this 10.5 PowerPC-exclusive build of v1.0.
There are, sadly, a few issues I've yet to work out:
- AdLib music doesn't work. I verified that the AdLib CAT and data are loading and that the YM3812 emulation is initialized and fed chunks but I can't hear it in the mix. Sound effects and MIDI work just fine, however.
- The first segment of the intro FLI plays back too quickly.
- The OpenGL scalers aren't compatible with the GeForce2 MX or likely any other card compatible with my Power Mac G4.
- There's console spew on startup about malloc double frees due to a bug SDL_mixer 1.2 that wasn't fixed until after its last release. I could roll my own SDL_mixer or add a patch to the TigerBrew formula but haven't yet as it doesn't seem to affect anything.
Some observations from my time hacking on this:
- Recent OpenXcom master is sprinkled with C++11 which is great but not compatible with GCC 4.2, the most recent compiler available to me. I decided to revert to the 1.0 tag rather than rewrite the new and improved code.
- Third-party OS X PPC git builds as recent as 2017 that claim to have worked around TLS version issues can no longer authenticate with GitHub.
- There's a PPC fork of Homebrew - the tool the wiki recommends for installing OpenXcom dependencies on OS X - called TigerBrew and it kinda sorta works. You can't update due to the aforementioned git issues and the packages are both woefully out of date and still configured for much later, intel-only OS X releases but you know, it's a good starting point.
- The OpenXcom devs were aware that yaml-cpp 0.5.2 was broken and put a warning about it into cmake. However, I discovered that 0.5.3, the last version I can compile, is also broken. I had to build 0.5.1 to get OpenXcom to save anything without yaml-cpp's emitter exploding.
- Someone kindly tried to anticipate and address potential endianness issues in the OpenXcom source but the FLI/FLC player code was broken due to unnecessary byte swapping for the literals used to identify movie type (i.e. FLC vs FLI) and other parameters. As a result, on my big endian PowerPC G4 the intro movie would fail to be identified as either an FLI or FLC and, due to dodgy error handling, ultimately produce a crash. I patched it up but there's no need to upstream the change as all of the FLC player code has since been replaced.
- One of the things preventing me from compiling the v1.0 sources was the absence of posix_memalign on Mac OS X 10.5. Thankfully the OS already guaranteed the alignment OpenXcom was requesting! Phew.
Anywho, I had a lot of fun with this and am enjoying yet another playthrough of X-Com! Although I highly doubt anyone else will find it useful, please comment if you end up trying out my build. Remember that you'll need to drop the usual data files into the Resources/data folder of the app bundle itself.
-
Recent OpenXcom master is sprinkled with C++11 which is great but not compatible with GCC 4.2Where exactly? AFAIK OXC still use C++03, only place what I know that use new standards is branch OXCE that require partial C++17
And for version, 1.0 is baaad, lot of work and fixes goes to recent version (support for TFTD) and if you really can't compile new version then at least go back to version before offending code was added.
-
/src/Engine/FileMap.cpp, /src/Interface/Text.cpp and possibly others (checking) use std::map<Key,T,Compare,Allocator>::at which is a C++11 STL feature according to the docs which I unfortunately can't link to. There's some use of C++03 features such as the 'override' specifier that are easy to deal with. If anyone here really wants it, I could look into rewriting or reverting FileMapp.cpp. I wasn't aware that v1.0 was 'bad' apart from the lack of TFTD support. Figured a tag with that name would get a decent amount of testing... but yeah, looking at the FLI/FLC player code and such I'm not surprised to learn its a wee bit buggy.
-
https://github.com/OpenXcom/OpenXcom/blame/master/src/Engine/FileMap.cpp#L52
Funny this was added 6y ago... and its from C++11:
https://en.cppreference.com/w/cpp/container/map/at
Overall even if it not C++11 this should be changed, this code two times access map for same value, and in first case throw away correct result.