Client rewrite β-testing

[ubersheva]

Bonus: encountered an NPE in Buff.java:111. Apparently, caused by a buff without progress bar, Real buff in my case. Changed the line to this to get the client running:

Code: Select all

Double ameter = (this.ameter >= 0) ? (this.ameter / 100.0) : ameteri.get() == null ? 0 : ameteri.get();

[loftar]

https://youtu.be/cg4y1nPjqMI

That's a really weird something. Though that being said, I can't imagine it being related to the rendering system. I wonder if it could somehow happen on the current client as well...

On Mac this get returned 1 at the very initialization

That's quite weird just in itself. In order to actually draw to the screen, the default FBO (that is, FBO 0) needs to be bound, so that not being the case at the start of a new OpenGL context is strange to say the least. I can't really say what that even means, but it sure is what I would look further into. If I were you, I would particularly insert these glGets right after glBindFrameBuffer commands, to see so that the bound framebuffer properly corresponds to what the command requests.

Bonus: encountered an NPE in Buff.java:111. Apparently, caused by a buff without progress bar, Real buff in my case.

That fix isn't entirely proper, but I've made the proper fix. Fun fact, whether that bug can happen depends on what version of javac the code is compiled with. In my case, javac had compiled it such that it couldn't happen, which is why I didn't catch it myself. Just for the record, the proper fix is as follows:

Code: Select all

Double ameter = (this.ameter >= 0) ? Double.valueOf(this.ameter / 100.0) : ameteri.get();

[ubersheva]

Yes, i was checking bound FB before/after glBind (actually on every command), it was not changing anywhere on Mac, while changing after glBind on Windows.
I think I may have found something relevant: 1) https://jogamp.org/deployment/jogamp-ne ... buffer(int)
2) http://forum.jogamp.org/glReadBuffer-be ... 28039.html

Apparently, Mac implementation of jogl’s canvas uses FBOs internally, which messes up bound buffer. I’ll try using getDefaultFramebuffer() instead of GL.GL_BACK when i get home tonight.

[loftar]

Apparently, Mac implementation of jogl’s canvas uses FBOs internally, which messes up bound buffer. I’ll try using getDefaultFramebuffer() instead of GL.GL_BACK when i get home tonight.

Interesting. Seeing as how it works on the current (old?) client, I can only assume, then, that JOGL "intercepts" glBindFrameBuffer to bind that proxy buffer instead of FBO zero, but I guess, on the other hand, that it does not intercept glDrawBuffer to make it do the right thing as well. Will you see if the attached patch works for you?

[Austinh15]

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?

[ubersheva]

Apparently, Mac implementation of jogl’s canvas uses FBOs internally, which messes up bound buffer. I’ll try using getDefaultFramebuffer() instead of GL.GL_BACK when i get home tonight.

Interesting. Seeing as how it works on the current (old?) client, I can only assume, then, that JOGL "intercepts" glBindFrameBuffer to bind that proxy buffer instead of FBO zero, but I guess, on the other hand, that it does not intercept glDrawBuffer to make it do the right thing as well. Will you see if the attached patch works for you?

will look at the patch in a moment. just tried replacing all GL.GL_BACK references (3 of them) to GL.GL_COLOR_ATTACHMENT0. And it worked! At least the client started and allowed to log in successfully (as in, login process completed and login screen disappeared). Then it threw the infamous invalid_opeartion exception, this time during 3d rendering of character portraits, I assume.

[ubersheva]

Apparently, Mac implementation of jogl’s canvas uses FBOs internally, which messes up bound buffer. I’ll try using getDefaultFramebuffer() instead of GL.GL_BACK when i get home tonight.

Interesting. Seeing as how it works on the current (old?) client, I can only assume, then, that JOGL "intercepts" glBindFrameBuffer to bind that proxy buffer instead of FBO zero, but I guess, on the other hand, that it does not intercept glDrawBuffer to make it do the right thing as well. Will you see if the attached patch works for you?

Yes, in GL4bcImpl.java, glBindFramebuffer(), there is exactly proxying code.
The patch helped to the point where the client was able to draw the login screen and threw error immediately after.

[loftar]

The patch helped to the point where the client was able to draw the login screen and threw error immediately after.

Could you try again with the DebugGL thingie enabled?

[ubersheva]

The patch helped to the point where the client was able to draw the login screen and threw error immediately after.

Could you try again with the DebugGL thingie enabled?

Right, forgot about that after reverting to initial state.

[loftar]

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.