Strange Android motion blur?

I ported my game to android, and it works well. So well, in fact, that a motion blur effect has been added on, free of charge. It looks like a basic motion blur implementation, like the game is writing to an image buffer which is then blended with the frame buffer, instead of writing directly to the frame buffer.

Does this sound familiar to anyone?

My game loop is basically just:

Code:
while (1)
{
GameLogic();
glClear(color_bits);
Render();
SDL_GL_SwapWindow(m_pWin);
}

I use double buffering and v-sync, nothing out of the ordinary.

Make sure your glClearColorf has alpha 1.0f, I know that at least Adreno forces compositing on (for no discernible reason) with it honoring your framebuffer alpha, it took extensive changes to my game
engine to make sure the framebuffer alpha is 1.0f so that it doesn’t composite wrongly.

I don’t know the cause of this - I mean I assume SDL2 is requesting an opaque window without framebuffer alpha being honored in compositing, in fact I’m not even sure why Android would be using
compositing in this case (if it could be shut off I’m sure it would be a performance gain - and we like those on mobile!).On 03/03/2014 05:01 AM, tjcbs wrote:

I ported my game to android, and it works well. So well, in fact, that a motion blur effect has been added on, free of charge. It looks like a basic motion blur implementation, like the game is
writing to an image buffer which is then blended with the frame buffer, instead of writing directly to the frame buffer.

Does this sound familiar to anyone?

My game loop is basically just:

Code:
while (1)
{
GameLogic();
glClear(color_bits);
Render();
SDL_GL_SwapWindow(m_pWin);
}

I use double buffering and v-sync, nothing out of the ordinary.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

LordHavoc wrote:

Make sure your glClearColorf has alpha 1.0f, I know that at least Adreno forces compositing on (for no discernible reason) with it honoring your framebuffer alpha, it took extensive changes to my game
engine to make sure the framebuffer alpha is 1.0f so that it doesn’t composite wrongly.

I don’t know the cause of this - I mean I assume SDL2 is requesting an opaque window without framebuffer alpha being honored in compositing, in fact I’m not even sure why Android would be using
compositing in this case (if it could be shut off I’m sure it would be a performance gain - and we like those on mobile!).

Oddly I had that problem, and I fixed it before I wrote, hoping it would fix the motion blur as well. But they are 2 seperate issues apparently.

Out of curiosity why did it take extensive changes? As long as you don’t call glBlendFuncSeperate the clear color should be the only path to getting non 1 alphas in your framebuffer, right?> On 03/03/2014 05:01 AM, tjcbs wrote:

tjcbs wrote:

Out of curiosity why did it take extensive changes? As long as you don’t call glBlendFuncSeperate the clear color should be the only path to getting non 1 alphas in your framebuffer, right?

Wait a minute, I guess actually I do have to start calling glBlendFuncSeperate…

tjcbs wrote:

Wait a minute, I guess actually I do have to start calling glBlendFuncSeperate…

That did the trick. I still don’t understand where the “memory” effect was coming from. It is as if it is blending all the back buffers together?? I do wish this could be disabled, my adreno 200 needs all the help it can get!!

That’s correct, it’s “compositing” each new backbuffer onto the system framebuffer.

The question is why, and whether SDL2 has a way to disable this unwanted behavior (preferably with a big gain in fps as a reward!).

It only seems to happen on Adreno for what it’s worth, which is also the platform where SDL2’s bad habit of doing eglWaitNative and eglWaitGL.

See this post for more about the eglWait weirdness: http://forums.libsdl.org/viewtopic.php?t=9946On 03/03/2014 12:50 PM, tjcbs wrote:

That did the trick. I still don’t understand where the “memory” effect was coming from. It is as if it is blending all the back buffers together?? I do wish this could be disabled, my adreno 200 needs
all the help it can get!!


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

2014-03-03 19:08 GMT-03:00 Forest Hale :> On 03/03/2014 12:50 PM, tjcbs wrote:

That did the trick. I still don’t understand where the “memory” effect
was coming from. It is as if it is blending all the back buffers together??
I do wish this could be disabled, my adreno 200 needs
all the help it can get!!

That’s correct, it’s “compositing” each new backbuffer onto the system
framebuffer.

The question is why, and whether SDL2 has a way to disable this unwanted
behavior (preferably with a big gain in fps as a reward!).

It only seems to happen on Adreno for what it’s worth, which is also the
platform where SDL2’s bad habit of doing eglWaitNative and eglWaitGL.

See this post for more about the eglWait weirdness:
http://forums.libsdl.org/viewtopic.php?t=9946

It doesn’t seem to be anything on the Java level (no calls to setAlpha on
the SurfaceView, and the default is 1.0 which according to the docs
disables the blending). At the EGL level, you’d have to debug into
SDL_EGL_ChooseConfig
and see what’s going on in there, it might be that even though you request
a config with no alpha you end up with one anyway (that’s my best shot in
the dark to explain this behavior).

Regarding the eglWaitNative/eglWaitGL I’ll remove those after 2.0.2 and
then let’s wait and see who complains (most likely no one!).