[HTML5 - canvas/webgl - Lime 5.6.0 - OpenFl 6.2.0] Animations not working in iOS

Help
#1

Hi,
I am experiencing a very big problem when running our apps on iOS: in the past all the animations were working correctly, but in these days we have noticed that the animations of some (not all) big spritesheets aren’t visible anymore. The apps run correctly, I can’t see any error or crash, but those animations are simply invisible.
On Android all animations are ok.

I ipotized it was because of browsers (both Chrome and Safari) image size limitations, so I tried to reduce the spritesheet size to <= 16.7MP, and the animations started to be visible. Do they really lowered the image size limits instead of increasing them?!
But…! The problem does not show up in all the apps: some app uses (much) bigger spritesheets and the animations work ok. All apps run on the same engine, so they are basically the same program that handles the spritesheets the same way.

So, what kind of problem can this be? I also tried to run the browsers on the previous iOS, the 10, but nothing changed. Could Openfl/Lime have changed lately in a way that can create this kind of problems? We don’t know what to do to restore the missing animations: we should try to reduce the size of all the spritesheets, but I’d be happy to understand why other (bigger) ss work ok.

#2

Perhaps they made the browser use a total memory limit, so once it’s passed it no longer loads any additional textures?

Does -Dcanvas work differently?

#3

Canvas and WebGL work the same way.
The big question is: why all the games were ok a few months ago? I wonder what is causing the problem now.

Tiles hierarchy
#4

Maybe there’s a “magic number” in the implementation, and something just nudged it over

#5

As I said here , I tried to convert Spritesheets by using my Tilesheet library, but I had to give up. I think that by using Tilemaps a lot of initialization problems (slowdowns, freeze etc) would disappear, as Tilesheets don’t need a heavy initialization like Spritesheets. Maybe some game bomb because of the new copyPixel routines?

#6

Oh, you mean spritesheet, like the spritesheet haxelib library?

It would be great to get that one updated to use Tilemap sometime

#7

My Tilesheet library is specular to Spritesheet lib, it is pretty easy to switch from one to the other.

EDIT: …but it still needs tweaks.

#8

I fixed (bypassed) the problem by splitting the spritesheets into different smaller atlases: in the loading phase the game automatically searches for these parts, parses them and then merges the results into a single spritesheet resource.

It works and it looks pretty (and introduces some advantages, like the possibility to apply different compression levels to the same atlas), but don’t forget it is a workaround.

Josh, do you think it is possible to understand why iOS doesn’t bear (some) big spritesheets anymore? Maybe copyPixel has become far more slow (and unpredictable) than before and iOS applies some timeouts that prevent some spritesheets from working?

#9

Is it a max texture size, or max memory limit?

#10

Sometimes the problem arises with 2000x2000 spritesheets, sometimes with 19000x3000, sometimes the overall size of the resources of a game is big, sometimes is regular, I can’t recognize a pattern to predict the problem :tired_face:

Do you remember when I told you that the time for parsing the spritesheets was varying a lot between different files, even if the size was similar? You told me it was because of the new copyPixel, and then you made a change to… align the behavior with different kind of images? Something similar, I didn’t ask for details. I am pretty sure that the behavior of copyPixel has changed a lot, this is why I suspect of it, but I’m just guessing.