No CLS = Eeeeuw!!!

Monkey Forums/Monkey Bug Reports/No CLS = Eeeeuw!!!

ElectricBoogaloo(Posted 2013) [#1]
This bug appeared in an earlier game, but nobody played that so nobody noticed it!
Unfortunately, it's popped up again, and this time my game appears to be doing the rounds, so the bug's getting noticed.

Also, apologies if this has already been looked into and fixed, I'm currently using v71, or something.. (how can I quickly look up my version number?!)

Anyway, the problem is as follows.
My game uses the age old "feedback" technique of not clearing the screen, then overlaying it with a semi-transparent black rectangle, thus allowing part of the previous frame to bleed through, and giving a nice simple "blur" to the game.
This works well on all targets, and although there are marginally different results due to how each target processes alphas and things, it's pretty much a similar experience.

.. except for Android.
*sigh* There's always one..
On a >Nexus 7< it works great, and as expected.

On >Nexus 10< it doesn't do a thing, as the Nexus 10 appears to be completely clearing the buffer..

And then there's the >Nexus 4<..
I can't even begin to contemplate what on earth that's trying to do, but it's not doing it well!!
It appears to be cutting the buffer up into chunks, then inexplicably plopping them down in the wrong place!
..
What is THAT about!?

I KNOW that's not ME doing that! And I doubt Mark's got some crazy code working away just to baffle me, so if anyone has any ideas on how to solve this one, let me know.
Thanks.


muddy_shoes(Posted 2013) [#2]
None of the targets guarantee that previous buffer contents will remain untouched if you don't explicitly clear the screen. The behaviour won't just vary between targets, it will vary between OpenGL implementations on the same target.


Markus(Posted 2013) [#3]
i heard some android versions did not clear the buffer and some
allocate the memory for paint buffer again without null it.
in other words at some devices you must paint the whole screen each frame.


ElectricBoogaloo(Posted 2013) [#4]
So, no quick and easy way to fix this, then?
tut.. that's a shame.
Annoyingly, there's also no way to quickly and easily disable it, either, since android's so mind-numbingly fragmented.
grrr!

.. I suppose I could do a self-test upon boot.. that could work.. maybe? hmm..

Stupid Android.. I HATE you, Andoid!!!!! You make everything harder than it should be!!!


Gerry Quinn(Posted 2013) [#5]
Might be hard to do a full self test. You would probably have to ask the user to select the mode which works best, which you could then save.


Raph(Posted 2013) [#6]
On my Nexus 7, this same trick doesn't work. :)

I resorted to grabbing the entire buffer and redrawing it. On some targets, this is fast enough. On others, not.


Goodlookinguy(Posted 2013) [#7]
I'm just gonna leave this here: http://www.monkeycoder.co.nz/Community/post.php?topic=1579&post=14727