General Received a video of what happens on Pixel 6, I slowed it down 10 times to better see the blinks. https://youtu.be/WLIMkJUFIiA So, at first the blinks are just a full texture atlas stretched across the screen), and afterwards it is distorted. @FlashFix I saw you mentioned something like this in your post in October 2021. Could you please check from you the current game version and the test build made with AIR 856?
Shaun_Max General is that a texture atlas packing issue? If so, my suggestion would be to go with basic algorithm settings, if you tightly pack then this could happen on some devices.
ma Could be related to this issue we had: https://github.com/airsdk/Adobe-Runtime-Support/issues/1327 In our case setting the MAX_NUM_VERTICES to 99 was a reasonable result.
General ma Thank you! Looks like exactly the thing! Indeed, for my game (many buttons and indicators with texts on the screen) setting MAX_NUM_VERTICES to 99 will increase draw calls from 1 to 130, so I'll looks into this thread, perhaps it will be possible to make a change only to Pixel 6.
General So, as a workaround, before starting Starling I call the following: if (Capabilities.os.indexOf("Pixel 6")!=-1){ MeshBatch.MAX_NUM_VERTICES = 400; } Players who use Pixel 6 confirm that this workaround works
Shaun_Max General Can you confirm if this has fixed the issue? How did you test it on a pixel 6 device?
General Shaun_Max I asked the players who reported this issue to check the updated version and they said that now it works fine
Shaun_Max General what is the issue on pixel 6? Could please tell how the above code will work on pixel 6?
Shaun_Max 2dguy i did according to @ma the value should be 99 but @General is using 400. I clearly don't understand what's happening behind the scenes
ma We just used that value as it worked in our case for our application, our draw calls remained low with this value but others had to raise it higher to these down. Choose a value that works with your application. The idea is just to keep the usage down as there appears to be a limit on pixel devices that cause issues once hit.
ma Just check your draw calls in the stats. Check here for more info on optimisation https://manual.starling-framework.org/en/#_performance_optimization
ma Shaun_Max Should be able to just get the draw calls right on your test device using variables like the ones we have suggested above. If you want to you can send me an invite to your test channels and I'll load it up on my pixel.
UnderwaterBird 3-4 years ago we had many issues with flickering on low performance Android devices. I'd fixed that with canAddMesh check before each addMesh, that resolved most of the issues. If mesh is full ( canAddMesh() returns false ), you can add new MeshBatch instead of adding mesh to an already full one. So I would advice as an additional measure to always use canAddMesh before addMesh (if you do not use it yet).