Client rewrite β-testing

[ubersheva]

Right, forgot about that after reverting to initial state.

Are you sure that's with the patch attached? It's calling glDrawBuffer again, which it shouldn't do with the patch.

yes, pretty sure:

Screenshot 2020-02-06 at 01.14.02.jpg

[loftar]

yes, pretty sure:

Are you sure you attached the right file, then? The previous log you submitted did correctly show glColorMask being called instead of glDrawBuffer.

[loftar]

Would really love to test this client but I used quite a bit of lanterns in my village, is there any way to turn off the cap on the maximum light sources for the client or is that a hard set thing?

There isn't really a realistic way to turn off the cap on light sources, since the shader needs to be compiled with some finite number. Either way though, the bug that blots out the sun should be fixed now.

[ubersheva]

yes, pretty sure:

Are you sure you attached the right file, then? The previous log you submitted did correctly show glColorMask being called instead of glDrawBuffer.

glDrawBuffer was called from unapply(), see attached log for exact stack trace. Also in same log output when I commented out that call - same as with GL_COLOR_ATTACHMENT0, client allowed me to log in and crashed before showing portraits.

[loftar]

glDrawBuffer was called from unapply(), see attached log for exact stack trace.

Right, of course, sorry, how stupid of me. Anyway, that seems to explain that particular problem, then; I need to design a more proper fix for it, but assuming that is "out of the way", your next error is also weird, since the new error comes from glGenVertexArrays.

According to the OpenGL specification, glGenVertexArrays shouldn't even be capable of generating an invalid operation error. Googling for it seems to yields results to indicate that it's some OSX specific problem relating to the precise OpenGL profile in use, but that's also strange, because I don't see how the GL profile would be different from the current client. The current client doesn't ever call glDrawBuffer(GL_BACK, so it's understandable that the previous error didn't happen on it vs the rewritten client, but I can't obviously find a similar explanation for this error.

Just to be sure, does the current (old) client work for you?

[ubersheva]

glDrawBuffer was called from unapply(), see attached log for exact stack trace.

Right, of course, sorry, how stupid of me. Anyway, that seems to explain that particular problem, then; I need to design a more proper fix for it, but assuming that is "out of the way", your next error is also weird, since the new error comes from glGenVertexArrays.

According to the OpenGL specification, glGenVertexArrays shouldn't even be capable of generating an invalid operation error. Googling for it seems to yields results to indicate that it's some OSX specific problem relating to the precise OpenGL profile in use, but that's also strange, because I don't see how the GL profile would be different from the current client. The current client doesn't ever call glDrawBuffer(GL_BACK, so it's understandable that the previous error didn't happen on it vs the rewritten client, but I can't obviously find a similar explanation for this error.

Just to be sure, does the current (old) client work for you?

Yes, I already started looking into why glGenVertexArray throws error, also was puzzled that this error is not mentioned in specs.

Yes, standard client works well for me, I use it every day. This is why i'm concerned that haven may become unsupported on mac after switch to the new client and trying to help.

[loftar]

Yes, standard client works well for me, I use it every day. This is why i'm concerned that haven may become unsupported on mac after switch to the new client and trying to help.

Yeah, just wanted to check so that you weren't running the standard client on another machine or something like that, since I can't think of any reason why they would behave differently in this regard. Since that isn't the case, though, one thing you could potentially check is whether the contexts that the standard vs the rewritten clients get really are the same. If you just dump the GLContext object itselt to System.err, it should present most of the interesting information about itself. The best places to do this would probably be the haven.render.gl.GLEnvironment() constructor on the new client, and the haven.GLConfig.fromgl() function on the standard client.

[ubersheva]

Yes, standard client works well for me, I use it every day. This is why i'm concerned that haven may become unsupported on mac after switch to the new client and trying to help.

Yeah, just wanted to check so that you weren't running the standard client on another machine or something like that, since I can't think of any reason why they would behave differently in this regard. Since that isn't the case, though, one thing you could potentially check is whether the contexts that the standard vs the rewritten clients get really are the same. If you just dump the GLContext object itselt to System.err, it should present most of the interesting information about itself. The best places to do this would probably be the haven.render.gl.GLEnvironment() constructor on the new client, and the haven.GLConfig.fromgl() function on the standard client.

Attached is output of GLContext and other potentially useful objects/calls from both clients.
My understanding is that on Mac when you create context you get GL2 from GLProfile.getDefault(), while on Windows you get GL4. And glGenVertexArrays is from OpenGL 3.0, according to spec. So INVALID_OPERATION is returned because the function is not supported in the GLContext.
And as for why current client works - the function never gets called there. I tried setting breakpoint in GLVertexArray.create() it is never reached. Double-checked everything, tried setting breakpoint in TexGL.create() for comparison - it is called.
Tried replacing GLProfile.getDefault() with GLProfile.getMaxProgrammable(true). Context creates fine, GL4 is supported on the system. But then gl.getGL().getGL2() throws "Not a GL2 implementation", and switching code from using GL2 to GL4 everywhere is not something that can be quickly done - some of used gl* functions are not present in GL4.

[loftar]

And as for why current client works - the function never gets called there. I tried setting breakpoint in GLVertexArray.create() it is never reached. Double-checked everything, tried setting breakpoint in TexGL.create() for comparison - it is called.

Ohh, right, the current client still contains its deprecated displaylist-based drawing mode. I didn't think it would be used unless explicitly called for, but apparently it still autodetects whether the OpenGL context supports VAOs. Well, that explains it, then, but sounds potentially a bit tricky to solve. Even if it required no other changes to the client, I wouldn't really want to hardcode it to used OpenGL 3 contexts instead, since that would instead make it unusable on configurations that don't support OpenGL 3. I'll have to examine what it would mean to be able to support either.

[ubersheva]

And as for why current client works - the function never gets called there. I tried setting breakpoint in GLVertexArray.create() it is never reached. Double-checked everything, tried setting breakpoint in TexGL.create() for comparison - it is called.

Ohh, right, the current client still contains its deprecated displaylist-based drawing mode. I didn't think it would be used unless explicitly called for, but apparently it still autodetects whether the OpenGL context supports VAOs. Well, that explains it, then, but sounds potentially a bit tricky to solve. Even if it required no other changes to the client, I wouldn't really want to hardcode it to used OpenGL 3 contexts instead, since that would instead make it unusable on configurations that don't support OpenGL 3. I'll have to examine what it would mean to be able to support either.

Is there a quick and dirty way to get this error out of the way, so that I could check if there are any new errors occuring?