Ok, I'm bringing this here from the thread in the Mac OS X forum: viewtopic.php?f=65&t=36428
Basically, 104.0 is failing to create the GL context on mac OS.
Best I can tell is that the required compatibility context is not supported by mac OS, and so the function CGlobalRendering::CreateGLContext in rts/Rendering/GlobalRendering.cpp fails.
Not fully understanding the setup, I'm looking for advice from the engine devs as to the appropriate change to make. Basically, macOS supports creating a GL core context in 2.0, 2.1, 3.0, 3.1, 3.2, 3.3, 4.0 and 4.1. The only compatibility contexts it creates are 2.0 and 2.1. I'm guessing that Spring is trying to create a 3.1 compatibility context and fails.
So I would love to know the appropriate patch to apply to GlobalRendering.cpp in order to get the appropriate GL context to be created so I can play with the new version on Mac OS X.
OpenGL context and macOS
Moderator: Moderators
Re: OpenGL context and macOS
Ok, last thing… I decided to just comment out various stuff in that file which looks for the available context versions, and just forced the creation of a core 3.1 context. Discovered that when you ask for a core context, you always get the latest available (for my Mac, GL 4.1), not the one you ask for, and now I get a new error on launch:
I would be most welcoming of any ideas :)
Code: Select all
Error: [ExitSpringProcess] errorMsg="Needed OpenGL extension(s) not found:
GL_ARB_texture_env_combine
Update your graphics-card drivers!
Graphics card: NVIDIA GeForce GTX 680MX OpenGL Engine
OpenGL version: 4.1 NVIDIA-10.17.5 355.10.05.45f01
" msgCaption="Spring: caught unsupported_error: " mainThread=1
Error: [Watchdog::ClearTimer(id)] Invalid thread 3 (_threadId=0x0)
Re: OpenGL context and macOS
What would you be if you were attached to another object by an inclined plane, wrapped helically around an axis?
Requesting a core context is not an option yet, but you can change the 3's to 2's on line https://github.com/spring/spring/blob/d ... ng.cpp#L31 to downgrade the requirement. Do this at your own risk, it voids any and all warranty if you encounter graphics-related glitches or crashes.
Also complain to Apple about their GL implementation, loudly.
Requesting a core context is not an option yet, but you can change the 3's to 2's on line https://github.com/spring/spring/blob/d ... ng.cpp#L31 to downgrade the requirement. Do this at your own risk, it voids any and all warranty if you encounter graphics-related glitches or crashes.
Also complain to Apple about their GL implementation, loudly.
Re: OpenGL context and macOS
Going by the names alone, shouldn't ForceCoreContext help here?
- MasterBel2
- Posts: 347
- Joined: 11 Apr 2016, 12:03
Re: OpenGL context and macOS
I'm not sure of the exact change (I know he didn't use ForceCoreContext) Belmakor forced use of OpenGL 2.1, disabled check for minimum context, and now Spring starts with this error:
Also: what would it take to get Spring working in a core context rather than a compatability context?
Code: Select all
[f=-000001] [Sound] Devices:
[f=-000001] [Sound] [Built-in Output]
[f=-000001] [CrashHandler] Error: Segmentation fault: 11 (SIGSEGV) in spring 104.0
[f=-000001] [CrashHandler] Error: Halted Stacktrace for Spring 104.0 using libunwind:
[f=-000001] [Sound] [ISound::Initialize] spawning sound-thread (100.0ms)
[f=-000001] [Sound] [ISound::Initialize] spawning sound-thread (200.4ms)
[f=-000001] [Sound] [ISound::Initialize] spawning sound-thread (300.5ms)
[f=-000001] [Sound] [ISound::Initialize] spawning sound-thread (400.6ms)
[f=-000001] [Sound] [ISound::Initialize] spawning sound-thread (500.7ms)
[f=-000001] [Sound] [ISound::Initialize] spawning sound-thread (600.8ms)
[f=-000001] [Sound] [ISound::Initialize] spawning sound-thread (700.9ms)
[f=-000001] [CrashHandler] Error: [00] CrashHandler::HaltedStacktrace(std::string const&, __siginfo*, __darwin_ucontext*) (in spring) + 94
[f=-000001] [CrashHandler] Error: [01] CrashHandler::HandleSignal(int, __siginfo*, void*) (in spring) + 323
[f=-000001] [CrashHandler] Error: [02] 2 libsystem_platform.dylib 0x00007fffc3499b3a _sigtramp + 26
[f=-000001] [CrashHandler] Error: [03] CSound::GetMaxMonoSources(ALCdevice_struct*, int) (in spring) + 100
[f=-000001] [CrashHandler] Error: [04] CSound::InitThread(int) (in spring) + 1097
[f=-000001] [CrashHandler] Error: [05] CSound::UpdateThread(int) (in spring) + 143
[f=-000001] [CrashHandler] Error: [06] Threading::ThreadStart(std::function<void ()>, std::shared_ptr<Threading::ThreadControls>*, Threading::ThreadControls*) (in spring) + 145
[f=-000001] [CrashHandler] Error: [07] std::thread::_Impl<std::_Bind_simple<std::_Bind<void (* (std::function<void ()>, std::shared_ptr<Threading::ThreadControls>*, Threading::ThreadControls*))(std::function<void ()>, std::shared_ptr<Threading::ThreadControls>*, Threading::ThreadControls*)> ()> >::_M_run() (in spring) + 48
[f=-000001] [CrashHandler] Error: [08] 0x0001cdab (in libstdc++.6.dylib) + 48
[f=-000001] [CrashHandler] Error: [09] 9 libsystem_pthread.dylib 0x00007fffc34a393b _pthread_body + 180
[f=-000001] [CrashHandler] Error: [10] 10 libsystem_pthread.dylib 0x00007fffc34a3887 _pthread_body + 0
[f=-000001] [WatchDog::DeregisterThread] deregistering controls for thread [audio]
[f=-000001] Error: [ExitSpringProcess] errorMsg="Spring has crashed:
Segmentation fault: 11 (SIGSEGV).
Re: OpenGL context and macOS
A whole lot of work that is at least one major engine release away from being done.
Trace points to an OpenAL initialisation failure of some kind, no idea about the specifics.
Trace points to an OpenAL initialisation failure of some kind, no idea about the specifics.
Re: OpenGL context and macOS
Any pointers? I'm guessing that trying to force 2.1 on the macOS version of the Spring Engine is a fool's errand, anyway - surely there is a reason why 3.1 was made the minimum, because the engine is using 3.1-only features?Kloot wrote:A whole lot of work that is at least one major engine release away from being done.
I've since found this quote on the Khronos website here: https://www.khronos.org/opengl/wiki/OpenGL_Context
Does Spring rely on the Fixed Function Pipeline (whatever that is) at all?Platform Issue (MacOSX): When MacOSX 10.7 introduced support for OpenGL beyond 2.1, they also introduced the core/compatibility dichotomy. However, they did not introduce support for the compatibility profile itself. Instead, MacOSX gives you a choice: core profile for versions 3.2 or higher, or just version 2.1. There is no way to get access to features after 2.1 and still access the Fixed Function Pipeline.
Is it possible to roll back the requirement for 3.1?
Is it theoretically possible (given time/resources) to write a completely new rendering pipeline (e.g. based on Apple's Metal API) for Spring optimised for macOS and still be able to play the existing mods like BA, etc? Or is too much of the content tied to GL for this to be possible?
Alas, I haven't had time to follow this one up yet. Any other macOS people tried to get 104 working at all?Trace points to an OpenAL initialisation failure of some kind, no idea about the specifics.
Re: OpenGL context and macOS
It does, as well as on GL3+ features. This is what makes Apple's decision to forego compatibility profiles problematic.Does Spring rely on the Fixed Function Pipeline (whatever that is) at all?
Theoretically you can simulate every particle in the universe, but I'm more concerned with what can be achieved under realistic real-world bounds. The fact that we still do not even have a *compiling* (let alone maintained) MacOS autobuild should give you a pretty clear idea as to the answer here: someone with the right combination of skills, motivation, and free time *could* write a Metal backend (after fixing all other errors first), it is just extremely unlikely to ever happen. Until 105 arrives, your best option would be to step outside Apple's little walled garden and dual-boot to Linux.Is it theoretically possible (given time/resources) to write a completely new rendering pipeline (e.g. based on Apple's Metal API) for Spring optimised for macOS and still be able to play the existing mods like BA, etc?
Re: OpenGL context and macOS
Kloot, what exactly will change between 104 and 105 that will allow the OSX version to be compilable again - and why?
Re: OpenGL context and macOS
Fixed Function Pipeline code will be removed, so compatibility mode won't be necessary. With core context, at least graphics should pose less of a problem.