[Mac, Android] Textures/Bitmapdatas are disappearing or mismatched

[jgranick]

219 Issue by Hasufel,

Since version 1.4, after some little time, TileSheet textures are rendered black or mismatched with other textures randomly. Tested on several mac machines. This does not happen in previous versions (prior to nme/hxcpp merge, <1.4). Tested also from latest source of today 13/05/2014. No error is sent to log unfortunately. Tried to intercept errors in enterframe with openfl.gl.GL.getError () to no avail either.

Examples:

Correct rendering:

Background tilesheet is disappearing:

Tilsheet holding bitmap font is disappearing:

Correct rendering:

Texture is mismatched:

Thank you for your attention.

[jgranick]

Comment by Hasufel:

Issue confirmed on Android too: tested on Nvidia Shield: encountering same symptoms.

[jgranick]

Comment by halfabench:

Hi Joshua, what would make the hunt easier? Do you want me to send you my game with debug symbols or something else?

[jgranick]

Comment by jgranick:

Basically, I would like to have some way of reproducing this problem, so far, I have none :)

Ideally, I would like to reproduce on a desktop rather than mobile, as well, as that would be much easier to iterate over to find the fix

Thanks guys

[jgranick]

Comment by halfabench:

The problem is that after some beta testing on the www.frenchcows.complatform I haven't encountered this problem yet on desktop. So ok I will try to see what I can do.

2014-05-15 17:53 GMT+02:00 Joshua Granick notifications@github.com:

Basically, I would like to have some way of reproducing this problem, so far, I have none :)

Ideally, I would like to reproduce on a desktop rather than mobile, as well, as that would be much easier to iterate over to find the fix

Thanks guys

— Reply to this email directly or view it on GitHubhttps://github.com/openfl/openfl-native/issues/219#issuecomment-43227943 .

[jgranick]

Comment by halfabench:

@joshua Ok tried from BunnyMark to deactivate/activate a few thousands time in a row with/without a sleep using __setActive(bool) but I could not reproduce the bug. ( btw thx @delahee for the idea ) Tried as well from my game, but no bug encountered with this method. Both tests were done on Android. So it seems the problem is not linked with these events.

However I got the bug again this morning, with bitmaps randomly appearing / disappearing after a few plays.

@Hasufel btw are you using the tilelayer lib ?

[jgranick]

Comment by delahee:

@jgranick May it related to context losts ? symptoms are often similar to no more gpu memory...

@halfabench If you feel adventurous there is an opengl tracer in the android trace monitor. It can allow you to spy on gl calls and resultes of sub renders between frame...Maybe it can help...

Feel free to wander at Mt so that we can have a closer look together.

[jgranick]

Comment by halfabench:

@delahee ok after quite a few plays and killing/restarting the app I can get the problem every time. So bitmap appear/ disappear randomly. I get all the opengl traces from the monitor. However I don't know what i should be looking for...

[jgranick]

Comment by jgranick:

Does it occur if you switch between windowed and fullscreen on the desktop? This should destroy the GL context, I believe, but this could be more difficult because you have a lot more GPU memory on a laptop/desktop than on mobile. Is this only with the tilesheet API, BTW?

[jgranick]

Comment by halfabench:

@jgranick In fact I can't reproduce on desktop. Even on an Intel NUC with HD4000. So all my tests are done on my nexus 7. Now regarding tilesheets, I use the tilelayer lib. But I also do use bitmaps for UI components (flash.display.Bitmap). And both stuff drawTiles and bitmaps appear/disappear randomly. For instance in the last play, I had one bitmap which was still there and tiles that would not be visible. And sometimes tiles appear and a bitmap disappear. And also sometimes when I come back to the game after an activate/deactivate some things appear again. Another thing is that I use additive blending by default ( I did not try to see if disabling it would fix anything.. ) Another thing is that I can see the layout of unvisible bitmaps when some particle are moving over.

[jgranick]

Comment by halfabench:

Ok. So removing additive blending does not correct anything apart from sloooooooooowing down a lot the game.

[jgranick]

Comment by halfabench:

I don't know if it is of any interest, but I also use bitmap fonts using tilesheets with Tilesheet.TILE_SCALE | Tilesheet.TILE_ROTATION | Tilesheet.TILE_ALPHA | Tilesheet.TILE_RGB flags on and they always appear. No problem with them.

So maybe I shall investigate with flags or directly with the tilelayer lib and the flags that are used ?

[jgranick]

Comment by jgranick:

There might not be output in logcat, the real issue here is that it is so hard to reproduce, or rather, I cannot reproduce. It's going to require a reproducible case, and iterations over the C++ code to find a solution. I have a couple commits (that seem innocuous) which might have caused the problem, since I believe we were stable before them

[jgranick]

Comment by halfabench:

Seems I missed these messages: E/loader (13210): Could not find primitive lime_bitmap_data_set_flags__1 in 0x750b3370 E/loader (13210): Could not find primitive lime_jni_create_method__4 in 0x750b3370

Anyway it does not change anything. Maybe I should investigate with cleanup? Maybe things are not properly cleaned and after a while everything is messed? If so what would be the best way to clean tiles?

[jgranick]

Comment by delahee:

@halfabench ahem....If you could send a reproducible (or your app source) example to Joshua, he should be able to understand the problem ( it really seem like gpu tex mem problem or gl state not correct)...If ahem...he can't I can schedule a session with you end of may so that we can do something. :)

2014-05-19 20:25 GMT+02:00 halfabench notifications@github.com:

Seems I missed these messages: E/loader (13210): Could not find primitive lime_bitmap_data_set_flags__1 in 0x750b3370 E/loader (13210): Could not find primitive lime_jni_create_method__4 in 0x750b3370

— Reply to this email directly or view it on GitHubhttps://github.com/openfl/openfl-native/issues/219#issuecomment-43538967 .

David Elahee

[jgranick]

Comment by Hasufel:

@halfabench yes we are using a heavily stripped down version of tilelayer. Do you think it might be correlated? This might be a good lead. We don't use any fancy stuff at all. We do also use regular bitmaps/drawTiles tho, plus it always has worked with prior versions (before nme codebase sharing). As pointed out by jgranick, some stuff changed in GL code during merger for 1.4 release ( https://github.com/haxenme/nme/commits/master/project/src/opengl ), and that's exactly at the timing we saw problems appearing on our end. Those are of particular interest to us:

• https://github.com/haxenme/nme/commit/2c255538783a64162010a62d2a25850f18cfc987 (where "false" is removed, and VBOs are put into use)
• https://github.com/haxenme/nme/commit/e289cba83e4fc3def7c73708122a8977c7ce36ce
• https://github.com/haxenme/nme/commit/3ccbaf9d12578acfcd803a884f2fbc83161df671
• https://github.com/haxenme/nme/commit/3599a86876c52350bd539f41fb8e2f1510ef5323 (touches mostly the way a bitmap is handled, not manipulating memory/binding whatsoever but on SurfaceIO.cpp there might be something)

We're really looking for overall memory attribution changes, as it seems like there's a bad pointer of some sort, maybe in the vbos or something... That's our take on it/field of research for now fitting what we're seeing (usage of non wanted bitmapdatas in tilesheet rendering (mismatch) etc).

@delahee thanks for coming in! I tried the Android glprofiler yesterday, thanks to some help from Justo Delgado, got it to the point where it caught the error displayed on the device (1GB+log), but unfortunately I could not find any visual help/guide inspection of textures used/rendered in the tool (>million of frames to inspect manually in .txt format is way too much for me). I simply noticed a zillion error with the following message: 'Error applying transformations for glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_BGRA_EXT, width = 2048, height = 2048, border = 0, format = GL_BGRA_EXT, type = GL_UNSIGNED_BYTE, pixels = 0x796ac008) java.lang.RuntimeException' and some bizzarre VBO all set at 255 at some point, but that was it for this session. I then tried to focus on desktop instead to go faster, and tried to build the apitrace tool from source as it seemed better but got stuck at compilation :/ As we're seeing those errors on desktop too having a real visual feedback of the textures in memory being used would be better.

@jgranick as fullscreen/windowed got crashed in source release ( https://github.com/openfl/openfl-native/issues/220 ) it's impossible atm to switch between the two states on mac. However the bug appears without having to deal with that. Just by initiating new scenes/manipulating bitmapdatas, and within minutes the 'bug' appears both on desktop (1gb vram) and on android (way less vram).

[jgranick]

Comment by halfabench:

@Hasufel I just wonder why we seem to be alone on that matter and why the BunnyMark can run without any problem. So maybe creating / killing many TileSprites from the TileLayer lib leads to this state earlier?

@delahee I am going to see how I can manage things. if @jgranick is interested I can send the .apk. Anyway thanks for your kind offer! I hope next time we meet will be for a couple of beers instead of bug hunting ;)

[jgranick]

Comment by halfabench:

Ok so I just built everything again with openfl / openfl-native v1.3.0. The bug occurs way sooner. After just a couple of minutes. With v1.4.0 I have to play for about 5-10 minutes before it happens.

[jgranick]

Comment by Hasufel:

lime version?

[jgranick]

Comment by halfabench:

Ah. It was 0.9.7. Trying to switch to earlier lime / lime-tools.

[jgranick]

Comment by halfabench:

ok so it seems that my current setup works "flawlessly" : lime 0.9.6 | lime-tools 1.2.9 | openfl 1.2.3 | openfl-native 1.2.4

Now for the setup that brings the same bug but sooner : lime 0.9.7 | lime-tools 1.4.0 | openfl 1.3.0 | openfl-native 1.3.0

So clearly the lib version mismatch is a problem. But it may give us a hint as to where the problem is located? Or maybe it was just a bad thing to do.

Now my $100 question: while we investigate further on the issue, what would I lose using the "working" setup to release my game? Did 1.3.0 and 1.4.0 introduced massive changes for the Android target?

[jgranick]

Comment by Hasufel:

You "stabilized" with about the same version numbers that I have. You'd lose nothing using that working setup - I do the same for now. No massive changes between 1.3 and 1.4 Android wise, except for the optimized OpenAL sound libs (that you should grab): they eliminate the latency we experienced before.

[jgranick]

Comment by halfabench:

Thanks! So, I'll get the OpenAL libs and go on with this version. Meanwhile I'll try to create a "working" case so we can get rid of this nasty problem.

[jgranick]

Comment by Hasufel:

@halfabench @jgranick we're not alone: at least 5 more are encountering the same problem with the same lime downgrade to 0.9.6 solution and "bad pointer" conclusion: http://www.openfl.org/forums/#!/bugs:android-black-random-black .

[jgranick]

Comment by underscorediscovery:

probably related : https://github.com/haxenme/nme/commit/5d8c10e4a04b

please test :)

[jgranick]

Comment by Hasufel:

Tested for 20 minutes, all good! A win, considering what was corrected in the commit. Thank you so much @hughsando !

[jgranick]

Comment by halfabench:

Ok I'll test tomorrow! Anyway Bravo!