Look into platform port options

[Eblo]

With this custom executable, our options for porting have expanded. Mac and Linux are already supported. Other possibilities:

• Nintendo Switch: Devkitpro is an unofficial option as a proof of concept. We'd need a devkit to actually publish
  • https://github.com/switchbrew/switch-examples/tree/master/graphics/sdl2
  • GPL blah blah blah we can't actually port this code base to Switch. Any console port options would necessitate a brand new implementation.
• Android
  • https://github.com/thehatkid/mkxpz-android/
• iOS

[Eblo]

With the adoption of custom shaders, we cannot presume that Mac is supported. It will have to be investigated as a separate option.

Linux has been compiled and booted in Linux, but that brings its own share of headaches. To name a few:

• This may more be a GL version issue, but existing shaders mostly require tweaks to be compatible. See this ticket in the game's repo.
• The game seems to require sudo to run for unknown reasons. Otherwise it throws an AL_SOFT error.
• On a VirtualBox Ubuntu 18 VM, the game could build seamlessly. It would, however, fail at boot due to Error creating context: Could not create GL context: BadValue (integer parameter out of range for operation)
• On a VMWare Ubuntu 22 VM, the game fails to build at the OpenAL stage due to aligned_alloc not appearing to be a member of std. This seems like a C++ version incompatibility, as aligned_alloc was not always part of std in C++. The binary built on the above VM can be used in this VM, but it requires libruby.so to be in the same directory. That was not the case in the other VM. Running make ruby in the project and copying that file to the game directory does allow the game to boot to the title screen. Numerous issues prevent things from progressing past the save file load; the RTP path and shaders are known issues. Text seems to be arbitrarily missing on some windows in this build.

So far, Linux efforts have been attempted on VMs. We will want to try it on real hardware as well. Gotta claim that Steam Deck verification. Ubuntu and SteamOS are prime targets for running the game. Alpine could be useful purely for building.

[Eblo]

Movie playback seems fine when run natively on Windows. Some combination of Linux and the nature of a virtual machine causes it to choke badly. The video playback reaches the final frame long before the audio finishes. I'm not sure if the audio is slowed or what. Hardware acceleration could be helpful here. But really, the two streams SHOULD be synced.

[Eblo]

Upon closer inspection, the video file is 8 FPS, but the game appears to be displaying at 10 FPS. This happens on Windows as well. fa2ec07 seems to be the culprit; playing video before that will result in proper syncing (albeit without the letter boxing, and the video will freeze on the last frame and loop the audio).

[Eblo]

The movie playback bug was fixed in 993e9ea, but it was not related to Linux or VMs. Furthermore, I don't think the 8 FPS sample video we have comes close to bottlenecking. If I force the frame rate to 60, it zips through without incident.

For the time being, I am able to build on Ubuntu 22 by changing a reference to std::aligned_alloc in OpenAL to just aligned_alloc. I'm not exactly sure what's wrong with the compiler there when Ubuntu 18 does not have that issue. When built and run on Ubuntu 22, neither sudo nor libruby.so seems to be required.

[Eblo]

Shader conversions are underway. First person works. Regular maps and battles work. SEs do seem to lag or sometimes not play at all. It is unclear if this is an issue with Linux, the virtual machine, or the fact that I changed a library's code to make the game compile. If it's not the latter, perhaps converting to WAV or archiving everything together would mitigate the issue.

[Eblo]

Building fails on MacOS. This seems to be the fact that custom stuff has not been XCode'd properly.

[Eblo]

The above was resolved with 5e712bf. I'm not sure how robust the Xcode fix in rb_shader.cpp is, but it works for now. Shaders and FPS work. Performance is crap, but that is likely due to the VM. Real hardware will be needed for proper testing. The SE latency in Linux does not appear on MacOS.