Client rewrite β-testing

[jordancoles]

I'd love it if we could minimize the markers box, the world map is huge with it included

[loftar]

DebugGL2.log

Thanks for that dump. It's really strange, though, because the command dump indicates that the default (zero) framebuffer is bound right prior to the glDrawBuffer call, and if the default framebuffer is bound, then I can't see how glDrawBuffer(GL_BACK) could possibly fail. Looking at the glprof-gldrawbuffer-state.txt file you attached, it actually seems to indicate that a different framebuffer is bound at the time of that call (it says framebuffer 2 is bound), and that would explain why glDrawBuffer itself fails, but that's also really weird, since, again, the call just prior to the call to glDrawBuffer is the command to bind the default framebuffer. I'm almost left wondering if it's some kind of driver bug. I'm not immediately sure what to make of that.

Logging in with laptop, has some integrated GPU I think. Mesa DRI Intel(R) UHD Graphics (Whiskey Lake 3x8 GT2)

I'm aware of that error, but it happens so exceedingly rarely for me that it's virtually impossible to debug. Are you saying that it happens reliably to you, or was it just something that happened once?

Can we add UI changes into the client rewrite?

Any UI changes are completely independent of the rewrite, and could be done equally well (probably even with the exact same code) in both the old and the new client, so it's totally unrelated to this thread.

[loftar]

DebugGL2.log

I'm not immediately sure what to make of that.

As kind of a long shot, could you try changing GL.GL_BACK to GL2.GL_BACK_LEFT in src/haven/render/gl/FboState.java? There should be two occurrences of it to replace, and you'll have to import javax.media.opengl.GL2. And in (the likely) case that doesn't work, try GL.GL_FRONT instead (which wouldn't really be useful, but just for testing purposes).

[ubersheva]

DebugGL2.log

I'm not immediately sure what to make of that.

As kind of a long shot, could you try changing GL.GL_BACK to GL2.GL_BACK_LEFT in src/haven/render/gl/FboState.java? There should be two occurrences of it to replace, and you'll have to import javax.media.opengl.GL2. And in (the likely) case that doesn't work, try GL.GL_FRONT instead (which wouldn't really be useful, but just for testing purposes).

Same symptoms in both cases - invalid op error, Bind/Draw commands reference same buffer #1, the only difference is Draw is called with a new buffer ID in the command list.
Will look closer at this tonight, the fact that bound buffer in the state is different from what was sent in bind at least gives a direction of investigation.

[boshaw]

I am in fact mostly testing on Java 8, I just also test on Java 11, and that's just how I know that the G1 collector is nicer (at least with the new client).

Would you say everything in the resource files at this point is Java 11 compatible now? I remember trying to go to 11 at the start of this world and running into functions from ByteBuffer that were removed after Java 9 from random resource files. As for stuff like JOGL I think newer versions of it also support java9+

[shubla]

Logging in with laptop, has some integrated GPU I think. Mesa DRI Intel(R) UHD Graphics (Whiskey Lake 3x8 GT2)

I'm aware of that error, but it happens so exceedingly rarely for me that it's virtually impossible to debug. Are you saying that it happens reliably to you, or was it just something that happened once?

Only once so far.

[loftar]

Would you say everything in the resource files at this point is Java 11 compatible now? I remember trying to go to 11 at the start of this world and running into functions from ByteBuffer that were removed after Java 9 from random resource files. As for stuff like JOGL I think newer versions of it also support java9+

I was never aware that there was anything in the client that wasn't Java-11-compatible to begin with, and I myself haven't had any issues running it with Java 11 (not that I've been doing that as much as with Java 8). It does sound weird to me that there are ByteBuffer functions that were removed in Java 9, since, in that case, they weren't even tagged as deprecated in Java 8. Are you sure this is the actual case? Can you point out what those functions were? I can't obviously find any from the JavaDoc.

[boshaw]

Would you say everything in the resource files at this point is Java 11 compatible now? I remember trying to go to 11 at the start of this world and running into functions from ByteBuffer that were removed after Java 9 from random resource files. As for stuff like JOGL I think newer versions of it also support java9+

I was never aware that there was anything in the client that wasn't Java-11-compatible to begin with, and I myself haven't had any issues running it with Java 11 (not that I've been doing that as much as with Java 8). It does sound weird to me that there are ByteBuffer functions that were removed in Java 9, since, in that case, they weren't even tagged as deprecated in Java 8. Are you sure this is the actual case? Can you point out what those functions were? I can't obviously find any from the JavaDoc.

This was quite a long time ago (late w10) when I was doing the testing so I don't have the exact output or functions anymore. I just recall it complaining about a ByteBuffer function that no longer was available after a class was dynamically loaded during gameplay. I can't seem to reproduce it anymore though so maybe something changed since then. I should have reported it back then but I also didn't care too much if I couldn't use Java 11 so I just went back to 8 at the time.

[MarcusXDead]

So, I wanted to check something, and got a wierd glitch.
After I clicked rmb with hide on the ground it disappeared, and then if I took anything else and click rmb it swaps with dissapeared item instead of being placed on the floor
If I click LMB on ground nothing drops.
And hey, I got it recorded, and did bother to cut and upload it.
https://youtu.be/cg4y1nPjqMI
After that I logged with amber and missing item was on my cursor. Placed stockpile easily. Then I logged back in re-rendered, and managed to place it as well.

[ubersheva]

didnt have much luck figuring anything out on Mac.
Tried putting everywhere calls to

Code: Select all

gl.glGetIntegerv(GL2.GL_FRAMEBUFFER_BINDING, ibuf, 0);

to see at which point they're changing, also did this in parallel on Mac and Windows. The behaviour of this get was different between Windows and Mac. On Windows it returned zero all the time before logging in, and started showing 1 or 2 after getting to char selection - in accordance with glBindFramebuffer calls.
On Mac this get returned 1 at the very initialization (that is, in GLEventListener.init()) and didnt change until first JOGLPanel.redraw() finished. And at the start of second redraw() call the get returned 2, and it didnt change after the first call to glBind. So apparently something is changing the binding between AWT events. Also by some reason the binding is different at the start.
So I can try to monitor other GL variables, if there's anything useful to watch, or conduct any other experiments. Otherwise, I have 14 more quests to complete the quarryman credo!