Standalone OpenSupaplex built locally on clean macOS Monterey on M2 mac without Rosetta2

[eirnym]

My goal was to build OpenSupaplex locally as a fully standalone application for macOS Monterey on M2 mac working without Rosetta2 requirement.

I fetched and built SDL2 and SDL2_Mixer as follows:

• libogg and libtheora (I don't know if latter is strictly required, I installed it for a good measure) - was taken from MacPorts, but linked statically, so can be taken from anywhere
• SDL has been built using XCode build project (can be built as an universal library)
• SDL_Mixer has been built XCode by specifying to enable MUSIC_OGG
• SDL and SDL_Mixer framework were replaced in OpenSupaplex files
• settings were changed by adding CodeSignOnCopy, it was required by XCode
• XM music was replaced by OGG using ffmpeg and minor changes in the audio.c file. This eliminates any additional libraries for reading and interpreting XM (#46)

Some paths were fixed to point to proper files to make sure, that XCode 14 recognises all files used:

• Some relative paths contain one more .. than required
• Some paths were absolute and contain user folder. These can be recognised by grepping git for spadrino

Minor changes were made to make XCode happy, like many C functions doesn't have any preceded declarations.

Please let me know if any of these changes are welcome.

[sergiou87]

Hi there!

As mentioned in #46, going back from XM to OGG is not an option, since that change was made on purpose for performance reasons. From what I see and remember, I added both SDL2 and SDL2_mixer frameworks to the repo: https://github.com/sergiou87/open-supaplex/tree/master/macos/OpenSupaplex/Frameworks

I can't check right now if those are universal (I doubt it), but maybe getting universal versions of those frameworks and changing the Xcode project settings to build it for ARM could be enough 🤔

[eirnym]

They are quite old and x86 only. It would be way better if they could be built during main app building.

Also I'd love to see this game in MacPorts.

About ogg vs xm I'd rather want to see an option in build (at least) and download packages. Also I don't see any significant loss of interpreting ogg and other music formats in other games. So I don't know about which computers you're talking about. If there's really a significant loss in decoding ogg format, it's a fault of SDL2 or SDL2 usage.

[sergiou87]

So I don't know about which computers you're talking about

I'm talking about PSP, Nintendo 3DS, Nintendo DS... If the original game worked fine with something worse than these XM files, I think this could too 😄

They are quite old and x86 only. It would be way better if they could be built during main app building

As mentioned here, I think it'd be more fruitful to contribute to the SDL2 and SDL2_mixer repos with improvements to bring Universal builds. That way other projects can take advantage of it too. Long live open source!

Also I'd love to see this game in MacPorts.

That'd be super cool! Does using Frameworks make that impossible for any reason?

[eirnym]

PSP, Nintendo 3DS…

I'd made a special release for them with XM rather than resign completely from ogg format for the rest. For the rest it's a good idea to have this as an option (as a build option as well)

contribute to SDL and SDL_Mixer

I still prefer to have no binary frameworks in the repo. Following ways I consider as preferred implementation.

• install and and test an external library to configure the game and link statically
• use submodules to download, update and build frameworks to use later on.

As I wrote this, I'd change build system to meson/ninja to support build for various systems in the same configuration. My guess it will work for all configurations at once. (I can contribute here)

MacPorts

It's highly preferred if an application will rely on SDL from MacPorts. Thus meson build system can be very helpful

[sergiou87]

I'd made a special release for them with XM rather than resign completely from ogg format for the rest. For the rest it's a good idea to have this as an option (as a build option as well)

I don't think it's worth having multiple variants of something that should just work 😕 Adding XM support to whatever SDL2_mixer we plan to use will help other people with the same need… there are other games out there (ports or not) that might use XM files.

I still prefer to have no binary frameworks in the repo

I totally agree with that. However, I'd rather not turn this into a mess of building external libraries. I'd like to keep it as simple as reasonably possible. The first (and I'd even say only) option should be getting prebuilt dependencies from brew/macports/GitHub/whatever and use those.

As I wrote this, I'd change build system to meson/ninja to support build for various systems in the same configuration

Would that work with the other platforms I mentioned (3DS, PSP, PS3…) or would it be specific to macOS?

Meanwhile, in case it's helpful, it's possible to quickly "hack" support for Apple silicon by updating the SDL2 and SDL2_mixer frameworks from https://github.com/libsdl-org/SDL/releases and https://github.com/libsdl-org/SDL_mixer/releases respectively, since the latest version of both of them are universal and support both x86_64 and arm64 achitectures:

$/Volumes/SDL2/SDL2.framework/Versions/A ➭ file ./SDL2
./SDL2: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64
- Mach-O 64-bit dynamically linked shared library x86_64] [arm64]
./SDL2 (for architecture x86_64):   Mach-O 64-bit dynamically linked shared library x86_64
./SDL2 (for architecture arm64):    Mach-O 64-bit dynamically linked shared library arm64

$/Volumes/SDL2_mixer/SDL2_mixer.framework/Versions/A ➭ file ./SDL2_mixer
./SDL2_mixer: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64
- Mach-O 64-bit dynamically linked shared library x86_64] [arm64:Mach-O 64-bit dynamically linked shared library arm64
- Mach-O 64-bit dynamically linked shared library arm64]
./SDL2_mixer (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
./SDL2_mixer (for architecture arm64):  Mach-O 64-bit dynamically linked shared library arm64

[eirnym]

I see, I think, all this can be done in a single build system including suport for low and high quality music and graphics. At the moment i think, docker would be required to build for several platforms.

It's totally fine that different platforms require different files to build, if build system is organised good and robust enough

Is it possible to communicate with you in other way than github do discuss further and plan the work?