Creating OpenGL 2.0 backend on PowerPC OS X

[doctashay]

gdb-output.txt

Hello,

I am attempting to port OpenMW to PowerPC Mac OS X. So far, I have been able to successfully build OpenMW and all required dependencies on Mac OS X 10.5 Leopard using gcc14. You can see my fork and the ongoing MR here: doctashay/openmw#1

I understand that PowerPC is a niche platform, there is no official support, and it is unlikely anyone will be able to meaningfully troubleshoot my issue. I can't even be sure this is an issue with OSG specifically. I have attached gdb output related to this crash in the hopes that someone with experience building OSG can reveal any additional troubleshooting steps for me - like a specific build option or fallback that I could try to get past this problem.

OpenMW creates a window and then crashes when creating an OpenGL 2.0 context.

osg::State::disableAllVertexArrays stops at VertexArrayState:131. You can see the inline it's executing:

inline void disable(ArrayDispatch* vad, osg::State& state) { vad->disable(state); ... }

then it jumps to null. so ArrayDispatch *vad is null or corrupted. If you actually look in osg::State it's getting valid GL entry points (despite glGetString failing for some strange reason) so I'm less inclined to believe this is a GL issue (although on Leopard, GL support is VERY hit or miss.)

One thing I noticed is that MyGUIPlatform::Drawable::drawImplementation (a separate dependency working with OSG) shows state = (class State*) 0x8, so basically just junk, despite the real osg::State existing at 0xc88ca00

I suppose due to our wonky development environment that there could be an ABI mismatch - but my build script for OpenMW is explicitly building MyGUI, OSG, and OpenMW (and all dependencies) with the same build flags.

I have tried statically linking OSG into OpenMW (which it is currently), and flipping a flag to run in singlethreaded mode - neither had any impact on the backtrace - it consistently fails on disableAllVertexArrays.

I can confirm that just creating a demo triangle with OpenGL 2.0 and SDL2 works fine. At the moment, I am building OSG in debug mode with example programs included, so that I can isolate further. It takes several hours to build OSG on PowerPC so in the meantime, any advice or pointer in the right direction would be greatly appreciated. At this point, even a dirty hack or bypass to get SOMETHING drawing would be better than where I am currently.

If this is unrelated to OSG (aka I'm lost) or there is no interest in troubleshooting please feel free to close this issue out. Thanks for your time.

[ssunday]

Bizarrely, I had this issue when I was doing vcpkg work for MacOS arm OpenMW/openmw-deps-build#29 (comment) . The issue was apparently the existence of having xquartz installed when building deps (or building openmw)? What this means I don't know...

[doctashay]

I tried completely removing X11/XQuartz and forgetting the packages with pkgutil, compiled with the build flag to specifically use the Cocoa backend with OSG, and it was the same error.

I'm not using the openmw-deps repository or the patches I saw in there for macOS... it's not clear if they are relevant for OS X Leopard, given the work already done in my PPC fork.

I had to compile OSG, MyGUI, and a few other dependencies manually, but most were satisfied through MacPorts.

I was out of date with master by about two weeks - it's weird that you also ran into this crash just a week ago. I updated my branch and I'm going to try compiling again, just in case.

[AnyOldName3]

The crash log has complaints about being unable to access memory at 0x0 all the way to the top of the stack, so something's already ended up in an invalid state way earlier. I still think that if the glGetString calls right after you create an OpenGL context fail, you've 100% not got an OpenGL context that you're going to be able to do anything with. There's no point documenting that the patient is reluctant to get out of bed if they've already been declared dead.

[doctashay]

Just an update, I was able to work around this issue - now I get some broken rendering and we crash when trying to compile shaders - easy enough solution, just disable shaders.

There's no point documenting that the patient is reluctant to get out of bed if they've already been declared dead.

I think that I can get this working.

[doctashay]

The texture corruption is likely because OSG doesn't have big endian conversion when parsing DDS textures.

I get an error: Global map color LUT must be 256x1 pixels, got 8x8

All of the textures I checked are uncompressed 24 bit RGB textures. We shouldn't need to pixel swap, just the header fields. I'm making some quick changes now to hopefully address this.

Closing this issue now.