Too many datablocks?

#1 @Watermark, sadly you have reached the same path that many of have reached. The simulator is a poor place to test - it doesn't have the constraints of memory or cpu.

You need to tackle this problem in several ways:

- only load the data blocks that are needed for a level and unload any data blocks from a previous level
- convert all images to PNG16 - I use a tool called TexturePacker
- switch on force 16 bit on each image data block

This will get you some more memory. The iPad 1 is the absolute worst iDevice for memory - it has a large screen resolution but only 256Mb.

Good luck!

#2 Thank you Scott! This helps me a lot! I will go try out your suggestions and see how they go. Also I have a few more questions:

1. Can anyone point me to where in the code the level datablocks are loaded? I would also like to see what I can do there as well.

2. Do I save more memory if I combine some of my images? For example, I have two sprite datablocks "Fireballsheet" and "Iceballsheet" which makes "anim_Fireball" and "anim_Iceball" respectively. If I combine the "Fireballsheet" and "Iceballsheet" into a "Fireiceballsheet" png, would that save memory? Or would it be the same thing?

3. In the Image Builder of iTorque, what exactly do the settings "Filter Pad", "Prefer Speed", and "Preload" do to memory? My guess is that if I shut all three off and set the "Filter Mode" to NONE it would result in less memory? Am I correct?

It must be something with my code. I get mindboggled that something like say Infinity Blade runs while my mini RPG with tiny sprites doesn't? Back to the drawing board...

#3 1. the loadlevel function loads all datablocks listed in the level datablocks.
Unload is not done for you so you would need to remove them manually (this is for optimization reasons: only unload those not needed in the next level as loading and unloading takes a massive amount of time on mobiles)

2. No you don't save memory that way. the images don't change due to it and changing filtermode is only a gpu rendering setting, nothing that affects the memory usage at all. The only thing that would do that is disabling mipmaps which reduces it by 33%

To expand on the original point 2: use pvr instead of png16 thats another reduction by a factor of 4 / 8 (cutting it to 25% / 12.5% of the previous one) while at the same time also loading faster as pvr (PowerVR TC compressed) images are hardware compressed and do not need any processing to be used. png on the other side need to be read, interpreted and provided to the gpu as byte array.

#4 Thanks Marc! I'll try out PVR and see how that goes. The force16bit helped much too btw.

Besides the force16bit, I've made progress on the issue. Basically, what I did was to load only the map datablocks when entering the level, and then load all the Battle animations separately when the player does a battle for the first time. At least it doesn't crash right away with this method. For others who face the same problem, here's the code:

if($battleBlocksLoaded == false)
{
$battleBlocksLoaded = true; // set this to false when changing levels
Canvas.pushDialog(guiLoadingScreen);
%dbFileName = "data/levels/datablocks/Battle_datablocks.cs";
exec(%dbFileName);
Canvas.popDialog(guiLoadingScreen);
}

Now I have a new question. As you can see from the code above, I tried to put a "Loading Screen" in during the loading. However, it doesn't appear. I assume that is because the Torque engine orders commands in its own way? Is there an "invalidate now" command somewhere where I can force draw a gui? Currently there is still noticeable lag between levels, and the least I can do is to cover it up with a loading screen.

#5 I think you might want to skip on using a GUI for the loading screen and go to loading a scene that has minimal resources in it. You should be able to make it visible when it's time to do loading though I've not done this myself and can't give you more ideas than this.

I'm going to have to deal with this eventually as well - I'll let you know what I find but I doubt I'll get to it in the next week.

#6 Hey Joe, here's what I tried and so far it's working for me. See if it helps.

The whole idea is to put in the gui and then schedule in the heavy calculations in the next line:

<<< GUI No Show >>>
Canvas.pushDialog(guiLoadingScreen);
HeavyCalculations(%LotsAData);

<<< GUI Shows >>>
Canvas.pushDialog(guiLoadingScreen);
schedule(700, 0, "HeavyCalculations", %LotsAData);

function HeavyCalculations(%LotsAData)
{
for(%i = 1; %i <= $oneGazillion; %i++)
{
// Lines & Lines & Lines & Lines & Lines....
}
}

#7 That's an interesting approach...

I tried this in my game and after going through a few workflows (clicks through various screens) it inevitably crashes. I put in a toggle whether to use the schedule or not and try the same workflow again and it works fine without schedule. I have a feeling mine might be a problem because it's on the borders of level ending and level loading.