New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Misbehavior (with fix) on iOS when using FrameBuffer #7297
Comments
Personally, I'm unblocked by my workaround. However, would be happy to provide a PR for this reported problem. Before doing so, I would however like to get some questions clarified before I would create a PR, to have less back and forth as part of the final PR: Questions:
Thank you in advance! |
Tested this on device, and it does not reproduce. Are you testing on sim here? |
Looked closer into this, and Ok this is nuts! 👁️ I think this was introduced by 0f24d72 as we have changed creation callback from waiting for the first frame, but I'm still super surprised that it hasn't been reported before you. I guess most of us are not creating framebuffers on create, (usually after some splash screen which doesn't require FBO would be my guess) Its not apparent in the test bench, since they construct their framebuffers after a first render due to structure of test suite. This has to happen in the create of the Adapater. We need to wait for the very first frame before finding the 'default' render buffer handle it seems as it returns 0 until we get that first frame. I'd rather not query something on every single interaction with framebuffers, every little helps with not putting gl commands into the buffers. Perhaps we can bring back the first frame logic, even if its for setting the default handle. |
I tested this on both a simulator with iOS 17.0 on an iPhone 15 with the following simulator version:
And using iOS 17.1.1 on my physical iPhone 13 device. Thx @Tom-Ski for all the details above 👍 Sounds more complicated that I thought. And would therefore better leave that to you, as you seem to have a lot of context around this already. But let me know in case there is anything I can help with. |
So this will be fixed? Nice. I also stumbled across this issue when using shadow light which internally uses a framebuffer. Postponing the creation until the first update call works but doesn't feel right. |
Issue details
I've been facing an issue on iOS only when using
FrameBuffer
. When I ported my game October Bro from Android/Desktop to iOS, I noticed that my game screen was just black (or just the screen-clear color I used).After longer investigation and digging into the LibGdx code, I could figure out the problem, and come up with a workaround. And my hope is that this issue report turns into a simple fix PR (either by me or by you), so that my workaround will not be needed anymore.
Reproduction steps/code
Use the following code on iOS, and toggle the
FIX
flag.The problematic code seems to come from the following section, which seems to even try to exactly this iOS specific problem according to the comment:
libgdx/gdx/src/com/badlogic/gdx/graphics/glutils/GLFrameBuffer.java
Lines 128 to 138 in 9036b80
However, while testing and debugging this, I could observe the following:
fboIdx = defaultFramebufferHandle = 0
on Desktop/Android, but usuallyfboIdx = 1
on iOSnew FrameBuffer(...)
constructor is called for the first time. I observed on my single iOS game that the very first time the constructor is called, that the stored fboIndex is first0
, and later it would be1
on iOS.defaultFramebufferHandleInitialized
the initialization of thedefaultFramebufferHandle
is only done once causes the problem that we might try to go back to the wrong index onFrameBuffer#end()
. As shown in the above code example.TL;DR Workaround
Summarizing my current workaround in a brief from above, the problem can be prevented by wrapping the
frameBuffer
begin/end function with:To kind of override the internal behavior of how
FrameBuffer#end()
does the unbind to go back to the screen.Version of libGDX and/or relevant dependencies
gdxVersion = '1.12.0'
Screenshots
With both
FIX=false
orFIX=true
, there is no problem on Android/Desktop:However, on iOS, using
FIX=false
causes a wrong result:The reason is that
FrameBuffer#end()
does not work as expected.With my fix to enforce going back to the previous frame buffer (here: the screen), it works correctly on any platform, even iOS:
Please select the affected platforms
References:
The text was updated successfully, but these errors were encountered: