iOS A simple Presentation style app crashing on iPad Air

[LosTNeuroN]

Hello,
I have been trying to make a simple Presentation style app for iOS, targeted at iPad Air. It contains several 2048 x 1536 sized PNGs, for the lack of time.
I have made one room, containing a couple of objects, one as the relevant image as sprite, and a couple more as buttons for navigation.
The app, in total, contains about 60 rooms, with just as many images and objects (1 set per room each)

My problem is the App crashes, seemingly iPad Air can't seem to handle too much memory load. But iPad 2 seems to be fine running it, naturally.

How do I reduce the memory and RAM load for making apps for iOS ?
1. Is it because I made too many rooms ? Should I have only 1 room instead and create / destroy objects as an illusion of navigation ?
2. Is it because too many objects ? Should I keep only single room and single object and put all images as "Included Files" and load them from there ?

I absolutely can't have lower resolution images, as it will destroy quality.
Can someone point me the right way of design for iOS for minimal RAM usage ?

Any help is greatly appreciated. As I am really hard pressed for time.

 

[Nocturne]

I'd say it's a memory issue... Look at using the prefetch and flush functions to manage VRAM use:

https://docs2.yoyogames.com/index.h.../4_gml_reference/sprites/sprite_prefetch.html
https://docs2.yoyogames.com/index.h...ing/4_gml_reference/sprites/sprite_flush.html

 

[LosTNeuroN]

I'd say it's a memory issue... Look at using the prefetch and flush functions to manage VRAM use:

https://docs2.yoyogames.com/index.html?page=source/_build/3_scripting/4_gml_reference/sprites/sprite_prefetch.html
https://docs2.yoyogames.com/index.html?page=source/_build/3_scripting/4_gml_reference/sprites/sprite_flush.html

Hey Nocturne ! It's been a while. (I'm the same guy who made the SONAR Submarine Game a few years ago..)
However, I have returned to GMS after a LONG LONG time, and it seems that many things have changed.

So, how exactly do I use it ? Externalize all the images into "Included Files" and load them via sprite_add() at the start of the room?

And what about the multiple rooms ? Should I remove all rooms, keep only one and swap out sprites ? prefetching and flushing them as navigation goes ?

 

[Nocturne]

Hello! Good to see you back on the forums!

So, how exactly do I use it ? Externalize all the images into "Included Files" and load them via sprite_add() at the start of the room?

So, if you want to do this, then I think it's a good solution, as you'll be using up internal memory for the app, but only the VRAM required for a single image, and you wouldn't need those functions I linked.Just use sprite_add and sprite_delete to control things. The only issue with this that I can see is that it might cause a flicker as sprites are added or deleted (since this is now asynchronous in GMS2... You could resolve this however by simply having two rooms, and when you are in room one, add sprite 2, then when you go to room 2, add sprite 3, then when you go back to room 1, add sprite 4, etc... that way you'd only ever have two images max in VRAM.

And what about the multiple rooms ? Should I remove all rooms, keep only one and swap out sprites ? prefetching and flushing them as navigation goes ?

When using the functions I mention above, to start with you'd want each sprite to have it's own texture page, and then in a controller object you'd call the prefetch function when you want to change to a new sprite, and at the same time flush the current sprite from memory (you should also call sprite flush immediately on start to ensure that nothing is in VRAM). Tbh, you might be better doing this with two rooms, as I mention above, and just switch between them and prefetch-flush as required, as while the prefetch/flush system is almost instant, you may still get a flicker between changing sprites.

Personally, I'd experiment with both methods and see which one works. I'm pretty sure that the external files > add > delete will have no issues, but I can't say the same for the prefetch/flush option as it's not something I've really had to use much...

 

[LosTNeuroN]

Just to clarify, how does GMS load room, placed objects and sprites into the memory.
I have followed this pattern -

1 room contains 1 object which has 1 sprite (assigned) and sprites are loaded into resource tree
swipe left on the object and you go to next room which is similar -
room 2, containing object 2, having sprite 2 (assigned)
swiping right goes back to room 1 and swiping left goes to room 3

So, does GMS load everything into VRAM ? Or just the current room is loaded ?
And if so, why it isn't documented anywhere ?

And yes, there are about 60 rooms like those..
How the heck should I save VRAM here ?

Also, Can I chop the image into 4 quarters, and load them separately ? Would that actually reduce the texture page size and VRAM usage ?

 

[Ricardo]

If you're putting all your 60 images in the resource tree, they'll eat some RAM no matter what, as the data needs to be loaded by the runner. In mobile Apple devices (and most Android devices), the system memory is unified, meaning the RAM is also used as "VRAM". This doesn't mean all the 60 images will be pre-loaded (decoded) into VRAM, though, and you still can benefit from sprite_flush, draw_texture_flush etc when changing rooms.
Also, take into consideration that GMS2 uses RGBA format for images, meaning w*h*4 bytes per texture page. If you have 60 2048x1536 images, each one will likely need a 2048x2048 texture page, meaning (2048x2048*4)*60 = 1006632960 bytes (1 GB) for all the images. Which may be too much for a mobile device.
I'd say you already know that having 60 rooms (and 60 big images in the resource tree) is not the correct way of doing this. Ideally you should use sprite_add and sprite_delete to load/unload the images on demand (having them as included files), and of course all of that can be managed using a single room.
If you don't have time to rewrite this app, add a "Room Start" event into the object that you use to show the images and put a draw_texture_flush() there. It'll help you keep VRAM usage as low as possible when swapping rooms. Also, make sure you don't have an unnecessary persistent object/room.
If the app is crashing right away when launching, though, I have bad new for you: you'll need to rewrite it (or reduce the number of images).