iOS Sprite_add on iOS seems inefficient

[clee2005]

I've been dealing with this issue for the last few days and it's becoming clear that loading sprites with sprite_add on iOS is not the same as it is on Android. I removed all the BIG game images (backgrounds) for the different levels from the resource tree and put them into the Included Files to be loaded on demand. This seemed to reduce the initial memory footprint of the game as expected. On Android we don't have any complaints.

I did this for our iOS games and the emails poured in of sudden crashes in the middle of the game. I spent a bunch of time reducing the texture swaps thinking that because of the sprite_add usage and extra texture page that it creates, perhaps this was the issue. I was able to bring down the swaps from 20 to 10! (should have done that long ago) . Retesting with some users, and the problem is the same. I took all the images and put them back into the Resource Tree and gave up on the sprite_add, and it runs fine for the same users (I was not able to reproduce the problem on our 4 test devices - so had to get others to test).

Anyone have any thoughts on this? I'm only loading 3 images via sprite_add and properly deleting them when done, so it's not a memory leak. It just seems to be performance. Some users report that they can't even open the game initially. It just crashes immediately, like the footprint increased! This is odd since the sprite_add doesn't even occur on the first room where this type of crash is being reported.

I'm confused and am wondering if this is a GMS2 bug in the iOS export.

 

[clee2005]

Could be related to my post above, but in the end I rebuilt with Runtime 2.1.4.212 instead of 2.1.4.218 and the crashing stopped! This will be a hard bug to log.

 

[zbox]

Don't load resources like that, unfortunately it really is not a good way to go with GM even though it would be nice. It is indeed very inefficient but that is just the nature of it AFAIK. It will also be creating a new texturepage for each sprite you add which is not a good thing at all. You should look into this great asset which does on the fly texture page creation from external files, I forget who wrote it but I'm pretty sure it's on the marketplace

 

[clee2005]

Thanks @zbox I've seen that asset. I'd probably choose to use this : https://www.leshylabs.com/apps/sstool/ and just use draw_sprite_part from it in order to keep the texture pages down with sprite_add. Even with 3 sprite_adds, it shouldn't have been a problem as I had the texture swaps down to 10-12 which doesn't seem to crazy.

I think it's a bug in the .218 runtime and iOS 11 and iPhone 6 for some reason. Strange combination I know, but that's what all the crash data was showing, and when I rolled back I was finally able to get it to stop.

 

[zbox]

I really highly recommend it I've used it in so many projects and it's saved a lot of headaches with loading and unloading stuff (especially when it's more than just a few sprites); it does what you describe with the draw_part except in a much more efficient, easier to use and intuitive way (IE - list some filenames, and then just reference them by ID - rather than hard coding everything etc) but I guess if it's only a few sprites overall can't hurt doing it like that.

Still, don't forget, the amount of bytes each page is taking up and being swapped around each time is (number of sprites added) * (texpage w) * (texpage h) * 4