Framebuffers on iOS stopped working (version 1.9.x)

[orangepascal]

Issue details

Rendering on iOS (any version) worked in 1.7.x, now upgraded to 1.9.x and it fails (haven't tried 1.8.x)
Issue is related to framebuffers, without using an FBO it renders normally.

Reproduction steps/code

Small example code: https://bitbucket.org/orangepixel/tiny-puncher

with Libgdx 1.7 it runs normal on iOS and shows everything, if you upgrade it to 1.9 it will run normal but the screen stays black. (removing the rendering to a framebuffer from com.orangepixel.utils.arcadecanvas render() makes it work again)

problem seems to be in framebuffers, possible the cause of the problem:
ef0c210

Version of LibGDX and/or relevant dependencies

1.7.x works, 1.9.x doesn't

Please select the affected platforms

• Android
• iOS
• HTML/GWT
• Windows
• Linux
• MacOS

[davebaol]

Small example code: https://bitbucket.org/orangepixel/tiny-puncher

Well, not quite the small example everyone is thinking of 😸

[xoppa]

Yeah, can you be a bit more specific @orangepascal, perhaps try the FrameBufferTest or any of the other tests that use fbo. Framebuffer worked on iOS in my tests after that commit, so I doubt that Framebuffer as whole is not working on iOS because of that. Can't test at the moment though.

[orangepascal]

ok ok the basic version :)
https://bitbucket.org/snippets/orangepascal/dKnGp

my ipad is running ios 8 and this won't render on it with 1.9.x, but does with 1.7.
Disable the use of the framebuffer, and it does render

[xoppa]

Is there a particular reason you are creating the fbo in the resize method and using a TextureRegion instead of the texture directly? See #3850

[orangepascal]

normally I have a framebuffer in "low-res" pixelart, based on the size of the window for correct aspect ratio's.. so I create it in resize to make sure it scales correctly on all systems. Knew about that bug, fixed that, like I mentioned the game does run, just doesn't render.

also normally I use some lights or filters on top rendering to the main framebuffer before I then scale that framebuffer to the full screen..

basically everything I did in the project I posted before, but you wanted the bare bone problem case :)

which is what I posted now :)

[xoppa]

So not using the TextureRegion and resize method also shows the problem? As said, I can't test at the moment, so just trying to help by looking at the code.

[orangepascal]

yup, updated the snippet to just the framebuffer usage:
https://bitbucket.org/snippets/orangepascal/dKnGp

the problem really is in framebuffer :)

[orangepascal]

oh, when not using the onResize it does work (even tho onresize gives the correct width+height on ios)

[badlogic]

Hm, might mean no OpenGL context is active when onResize is called.
On Feb 20, 2016 9:35 AM, "Pascal aka Orangepixel" notifications@github.com
wrote:

oh, when not using the onResize it does work (even tho onresize gives the
correct width+height on ios)

—
Reply to this email directly or view it on GitHub
#3864 (comment).

[xoppa]

Yeah the resize issue needs to be fixed, it causes quite some problems (e.g. viewport.update won't work when the viewport isn't created yet). Unfortunately I can't verify the fix referenced in #3850, perhaps @badlogic or someone else can have a look at it.

[jodik]

I have exactly the same issue (just on iOS). FrameBuffer works in 1.7.0 and in 1.9.2 nothing is rendered once I call FrameBuffer.begin(). Is it fixed with a7e7f5c?

[orangepascal]

the problem is indeed still there.
onResize is correctly called after the onCreate, but the problem (with Framebuffer) is still there. Nothing being rendered

also, disabling the use of Framebuffers does render..

[Tom-Ski]

Can supply a simple ApplicationAdapter that reproduces your problem so we can test with a minimal setup

----- Reply message -----
From: "Pascal aka Orangepixel" notifications@github.com
To: "libgdx/libgdx" libgdx@noreply.github.com
Cc: "Tomski" tomwojciechowski@asidik.com, "State change" state_change@noreply.github.com
Subject: [libgdx/libgdx] Framebuffers on iOS stopped working (version 1.9.x) (#3864)
Date: Sun, Apr 24, 2016 14:59

the problem is indeed still there.

onResize is correctly called after the onCreate, but the problem (with Framebuffer) is still there. Nothing being rendered

—You are receiving this because you modified the open/close state.Reply to this email directly or view it on GitHub

[orangepascal]

I wrote a little bare-bones test-case, but it works in that one.
tried again in my own code and it doesn't there.

Moved the creation of my framebuffers outside the resize() call, and then it works.

Guessing my own code has a longer init (loading graphics,sounds,etc) causing the difference between that and the bare-bones test-case? possibly

still not a perfect solution, cause you normally want to recreate framebuffers after a resize().
For now I just dispose them in the resize, and they will be recreated on the next render call.. messy, but I'll take it for now.

so something goes wrong between framebuffers and ios' way of handling the resize (which does trigger 4 times during startup/application create )

[Tom-Ski]

Do you only create your FBOs in resize, or do you also create in create? Is this still happening with TinyPuncher? If so I can take a look tonight.

[orangepascal]

I tried creating both in create+resize and just in resize which failed.. creating them in the resize basically just fails.

just tested TinyPuncher version, and that does work! I did notice one difference between the cases which I can't find anything that causes it. The working cases startup with this console output:

IOSApplication: iOS version: 8.1.1
IOSApplication: Running in 32-bit mode
IOSApplication: Unscaled View: LandscapeRight 1024x768
IOSApplication: View: LandscapeRight 1024x768
IOSGraphics: 1024.0x768.0, 1.0
IOSGraphics: Display: ppi=132, density=0.825
IOSApplication: created
IOSApplication: resumed

and the code going wrong does this:

IOSApplication: iOS version: 8.1.1
IOSApplication: Running in 32-bit mode
IOSApplication: Status bar is not visible
IOSApplication: Total computed bounds are w=1024.0 h=768.0
IOSGraphics: Display: ppi=132, density=0.825
IOSApplication: created
IOSApplication: Status bar is not visible
IOSApplication: Total computed bounds are w=1024.0 h=768.0
IOSApplication: Status bar is not visible
IOSApplication: Total computed bounds are w=1024.0 h=768.0

I think it's roboVM output, but both versions use libgdx 1.9.2 and robovm 1.9.0.. so I'm not really sure where the difference comes from and if this might be the cause of it?

[arkiruthis]

I've run into exactly this same issue (Gdx 1.9.2, RoboVM 1.9.0).

In create() I glClear() a framebuffer to red. On every platform (apart from iOS) I get a red texture back. On iOS I just get black. Doesn't seem to be just a resize() issue here, I get a black texture from the framebuffer regardless of where I try to create it on iOS.

I notice the ticket has been marked as "Closed" but there didn't appear to be a solution?

[Tom-Ski]

The original issue originated as resize was being called in the wrong place. It was closed as that issue should have been resolved. There hasn't been an self contained example that has shown this to still be a problem, if you can provide one we can work from there.

[arkiruthis]

Thanks Tom-Ski, if I'm able to replicate it in a fresh minimal project I'll create a new issue.

[EDIT - sorry, turns out my error was a mistake in glReadPixels, the Framebuffer was actually working fine. Everything is fine now. ]

[Tom-Ski]

@orangepascal Looks like they are running different versions, that first console output startup is pre 1.9.2

[orangepascal]

ah gotcha.. seems the test cases were running on 1.7.1 indeed. Updating them to 1.9.2 gives us the problem.

So here's a short example of the problem:
https://bitbucket.org/orangepascal/libgdxframebuffertest

[Tom-Ski]

Your example works OK for me. Running on iOS 9.3 and latest source of LibGDX. This could be an iOS version issue. Could you try this ApplicationAdapter https://gist.github.com/Tom-Ski/33d7f8819aca782ad55626bad7e1ef45

[orangepascal]

yeah that works, it's basically the work-around I use in my game now.
I'm testing on ios 8.1.1