Attempting to get 1.91 built on Mac

[phkb]

Some additional debugging has found the following:

Code: Select all

   OOGL(glClampColor(GL_CLAMP_VERTEX_COLOR, GL_FALSE));

and

Code: Select all

   OOGL(glClampColor(GL_CLAMP_FRAGMENT_COLOR, GL_FALSE));

FaIl with the error "invaliud enumerant". So I guess it's not as simple as just adding those definitions.

Everything down to the first instance of the line

Code: Select all

if (glCheckFramebufferStatus(GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE)

doesn't fail, per se, in that no error codes are being flagged.
The framebuffer failure error is 0x8CD6, which is GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT

[phkb]

I'm wondering if the issue is something to do with the initialisation settings. For clarity, this is what I've currently got:

Code: Select all

	// Pixel Format Attributes for the View-based (non-FullScreen) NSOpenGLContext
	NSOpenGLPixelFormatAttribute attrs[] =
	{
		// Specify that we want a windowed OpenGL context.
		// Must be first or we'll hit an assert in the legacy fullscreen controller.
		// NSOpenGLPFAWindow, // enabling this will force OpenGL to v2.1
		NSOpenGLPFAOpenGLProfile, NSOpenGLProfileVersion3_2Core,
		
		// We may be on a multi-display system (and each screen may be driven by a different renderer), so we need to specify which screen we want to take over.
		// For this demo, we'll specify the main screen.
		NSOpenGLPFAScreenMask, CGDisplayIDToOpenGLDisplayMask(kCGDirectMainDisplay),
		
		// Specifying "NoRecovery" gives us a context that cannot fall back to the software renderer.
		// This makes the View-based context a compatible with the fullscreen context, enabling us to use the "shareContext"
		// feature to share textures, display lists, and other OpenGL objects between the two.
		NSOpenGLPFANoRecovery,
		
		// Attributes Common to FullScreen and non-FullScreen
		// NSOpenGLPFACompliant, // enabling this will force OpenGL to v2.1
		
		NSOpenGLPFAColorSize, 32,
		NSOpenGLPFADepthSize, 32, // I've also tried 24 in this spot
		NSOpenGLPFADoubleBuffer,
		//NSOpenGLPFAAccelerated, // enabling this will force OpenGL to v2.1
#if FSAA
		// Need a preference or other sane way to activate this
		NSOpenGLPFAMultisample,
		NSOpenGLPFASampleBuffers, 1,
		NSOpenGLPFASamples,4,
#endif
		0
	};

I've also tried enabling the FSAA options. Any suggestions very welcome!

[hiran]

This does not answer a question but may make it easier for more people looking at the code in the future: Add Doxygen style comments.

These comments not only sit in the code - they also get extracted by Doxygen and placed in the easy-to-browse Oolite API Documentation.

Or, should someone have the right IDE, it would be displayed inline wherever needed.

[another_commander]

Some additional debugging has found the following:

Code: Select all

   OOGL(glClampColor(GL_CLAMP_VERTEX_COLOR, GL_FALSE));

and

Code: Select all

   OOGL(glClampColor(GL_CLAMP_FRAGMENT_COLOR, GL_FALSE));

FaIl with the error "invaliud enumerant". So I guess it's not as simple as just adding those definitions.

This should hopefully not be a problem. According to the OpenGL 4.1 core spec (see page 417 here), the targets CLAMP_VERTEX_COLOR and CLAMP_FRAGMENT_COLOR are deprecated. Hopefully we can still do the necessary unclamping with the target that remains, CLAMP_READ_COLOR, which does not result in an invalid enumerant error.

Everything down to the first instance of the line

Code: Select all

if (glCheckFramebufferStatus(GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE)

doesn't fail, per se, in that no error codes are being flagged.
The framebuffer failure error is 0x8CD6, which is GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT

Two suggestions on this and mind you, I'm shooting in the dark here and hopefully no damage will occur:
1. I've read somewhere - but can't find the source now, that the Metal interop to OpenGL works only with 8-bit buffers. To test this, try changing one framebuffer attachment setup from this: glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA16F, (GLsizei)viewSize.width, (GLsizei)viewSize.height, 0, GL_RGBA, GL_FLOAT, NULL) to this: glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, (GLsizei)viewSize.width, (GLsizei)viewSize.height, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL)
I don't expect the game to work correctly if this passes, but it would be a good indication of where we stand with the Metal interop. Change just one framebuffer and see if its error messages cease.
2. Change all occurrences of GL_DEPTH_COMPONENT32F to GL_DEPTH_COMPONENT24 (or GL_DEPTH_COMPONENT if the 24 doesn't work). Maybe Apple OpenGL doesn't have automatic fallbacks to 24 bit depth buffer like Windows and Linux have.

[Bogatyr]

So this thread is about building / running on Apple M? ARM-based CPUs?

Part of the complexity coming in to this discussion is just understanding what the current situation of what works and what doesn't. It would be helpful to have a matrix/table of MacOS version, Mac CPU, XCode version, and Oolite version, whether or not the build works and if the executable works.

[hiran]

How about you create this table on the wiki and we all try to fill the data?

[Bogatyr]

Sure thing

[Bogatyr]

Is there a repo or tag or branch with phb's changes discussed in this thread?

[hiran]

Is there a repo or tag or branch with phb's changes discussed in this thread?

If there were a repo it should be found here:
https://github.com/OoliteProject/oolite

But looking at the tags/branches I can see many, amongst them this one (which is not phkb's changes):
https://github.com/OoliteProject/oolite ... mac-builds

So I guess it was not yet published on any public repository.

[Cholmondely]

Sure thing

Do you need a wiki account?

[Bogatyr]

I presume so, since I didn't know I needed one .

So I just plan to start at the beginning, at 1.90, try to build and run and get familiar with things from there. The mac sound bug is really driving me crazy, it happens EVERY battle now so I'll probably look at that once I get things building.

About the sound bug: I recall someone mentioning that Oolite is heavily multi-threaded. What I know from experience is that most system APIs are not thread safe. Perhaps just synchronizing all sound APIs to make sure only one call is active at a time will solve it. But since it's so easy for me to reproduce, hopefully I'll be able to track it down.

At the very least, I hope to be able to produce v1.90-based bugfix binaries.

[Cholmondely]

I presume so, since I didn't know I needed one .
....
At the very least, I hope to be able to produce v1.90-based bugfix binaries.

I've sent you your new account details - you may wish to transmogrify the password into something more personal.

I've added a few tips to your Wiki User: page

If you can manage to bugfix v.1.90, I for one will be very happy.

[another_commander]

About the sound bug: I recall someone mentioning that Oolite is heavily multi-threaded.

Not heavily but yes, sound is based on OpenAL so it is indeed multi threaded.

All Mac sound problems reported in the past point to this location where an assert failure occurs:
src/Core/OOALSoundChannel.m, line 121.

You may want to start your investigation there.

[Bogatyr]

Thanks, I'll update status as I go. BTW are there any live chat platforms (I saw mention of discord on the Oolite subreddit?) in use?

[another_commander]

Yeah Discord is working, although not many people chat there. I use it for screenshots and I am frequently checking it.