how to get 60 image animation loop to work?

[iliketomakestuff]

this isn't a code question, as much as a theory question..
I've gotten UIImageView animations to work just fine, but it only seems reasonable to small image or for a small number of "frames"

What's the best way to go about animating something that is , let's say 70 separate images.. each image being 320 x 150 or something..
Techinically, the UIImageView Anim method works, but it's SOOOO slow.. and seems to cause issues with responsiveness..

(I've also tried a timer based animation, same deal, worse on performance actually)

Any help would be greatly appreciated..
Thanks,
bob

[Abel95]

Can we have a look at your code.

[iliketomakestuff]

Originally Posted by Abel95

Can we have a look at your code.

Well, like I said, this isnt about any specific code, more if just a "best practice" question.. but here's what I'm currently using for one instance of the "problem"
It works alright, but still has performance issues

-(void)startCountdown{	countDownImageInt=0;
	countDownDisplay = [[UIImageView alloc] initWithFrame:CGRectMake(-60,40,320,140)];
	[parentView addGameUIImageView:countDownDisplay];
	countDownTimer = [NSTimer scheduledTimerWithTimeInterval:0.05
					target:self selector:@selector(showNextCountdownImage)
					userInfo:nil repeats:YES];
}
-(void)showNextCountdownImage{
	countDownImageInt++;

	if(countDownImageInt>=59){
		[countDownDisplay removeFromSuperview];
		[countDownTimer invalidate];
		countDownTimer = nil;
		[self startGame];
	}else{
		NSString *gStr;
		if(countDownImageInt<10){
			gStr = [NSString stringWithFormat:@"0%d",countDownImageInt];
		}else{
			gStr = [NSString stringWithFormat:@"%d",countDownImageInt];
		}
		NSString *fileName = [NSString stringWithFormat:@"countdown_000%@", gStr];
		countDownDisplay.image = [UIImage imageWithContentsOfFile:[[NSBundle mainBundle] pathForResource:fileName ofType:@"png"]];
	}
}

The other method I was trying was

	destroyAnim = [[UIImageView alloc] initWithFrame:CGRectMake(0,0,250,150];

	[self addSubview:destroyAnim];
	destroyAnim.animationImages = destroyImages;

//with destroyImages being an NSArray of UIImages

	destroyAnim.animationDuration = 0.4;
	destroyAnim.animationRepeatCount = 1;
	
	
	[destroyAnim startAnimating];

The big issue seems to be that the dimensions of the images used are just too big for the iPhone to handle.. of course, the simulator runs them fine..

[crabFish]

There are a number of things to take into consideration here...

1. imageWithContentsOfFile is slow - using that for animation you will have to preload all the images before starting your animation (and that will take a really long time if we're talking about 70 images @ 320 x 150)

2. imageNamed is a lot faster since it caches your images - again it will take some time with the amounts and sizes your aiming at so preloading might be a good idea in this case as well. The problem here is that the images will stick in memory and you will run out of that almost immediately, taking us to point 3...

3. You're going to crash the phone using that many images and those sizes so perhaps making your animations smaller or reusing frames or rethinking your basic concept and idea might be a way to solve it? (Just take a second to calculate the size you will reach with your images in memory - width*height*4*number of images)

4. You can always do it as a full screen video instead (depending on what you're trying to achieve - this might not be an option) as a solution. Then you can get the speed you want, any amount of images needed at any lenght since your playing a movie and not loading seperate images.

[DanSelig]

Originally Posted by crabFish

There are a number of things to take into consideration here...

3. You're going to crash the phone using that many images and those sizes so perhaps making your animations smaller or reusing frames or rethinking your basic concept and idea might be a way to solve it? (Just take a second to calculate the size you will reach with your images in memory - width*height*4*number of images)

Please sir: what is the memory limit? What is the limit for the small iPod Touch?

[iamsgtyang]

iPod Touch - Wikipedia, the free encyclopedia

Memory 1st/2nd generation: 128 MB DRAM
2nd generation (Late 2009): 256 MB DRAM

[DanSelig]

Originally Posted by iamsgtyang

iPod Touch - Wikipedia, the free encyclopedia

Memory 1st/2nd generation: 128 MB DRAM
2nd generation (Late 2009): 256 MB DRAM

Thank you Sgt Yang. I appreciate the reply but you misunderstand the question. I wrote an application (Munchum) that eats for the user. My original application had a menu of items and an animation for each. It crashed.

When I removed enough photos from one animation, no crash. I put some back and crash. I removed photos from another and no crash.

This has nothing to do with 128meg. The entire footprint of the app was much smaller and with instrumentation, I could see that my usage was under 40meg.

Perhaps it's the tool. Maybe there's a better way than [imageView startAnimation]. Just as [audioPlayer play] handles much more than AudioServicesPlaySystemSound(sound).

Do you know a better way?

[crabFish]

Originally Posted by DanSelig

Please sir: what is the memory limit? What is the limit for the small iPod Touch?

The memory limit differs depending on what applications the user has been running and how long ago the device was restarted...
Think of it as a dynamic space where going over 30MB most certinaly will kill the app (even though this has been suggested by apple to be expected available memory, it's rarely the case).
To be safe - keep it under 16 - 20MB's for the older devices... Allthough you should be aware that there might be situations where memory runs out at even lower levels than that. As I said, it's a dynamic space so it changes - your app will only get what's left and available on the device - so if the user is running Safari, Mail, AppStore, MusicStore, have had some other apps running that might have locked up memory and haven't restarted in a while - there isn't much left to play with...

Therefore you should set up you app so that it only loads what is necessary for the moment, unloading when not relevant anymore - and to respond to memory warnings making sure you dump all that can be dumped if you get those...
Working with images you get limited since they do take up quite a bit of space - also make sure your not loading with imageNamed, since this one caches your images and that cache is hard to get rid of... Use imageWithContentsOfFile instead, allthough a bit slower it enables you to clear out everything when needed...

Hope this helps...

[iamsgtyang]

If simulator run's the program fine with 60 images and not on your iPod Touch, you might want to rewrite you're code. Animating 60 png files in 3 seconds using the NSTimer, don't know if you are or not, will be pretty intensive for the device but not for the computer running simulator.

[DanSelig]

Originally Posted by iamsgtyang

If simulator run's the program fine with 60 images and not on your iPod Touch, you might want to rewrite you're code. Animating 60 png files in 3 seconds using the NSTimer, don't know if you are or not, will be pretty intensive for the device but not for the computer running simulator.

Thanks. I was trying to run between one-half and one second per image. Wasn't using NSTimer just [imageView startAnimating].

I will try using imageWithContentsOfFile and I will experiment with releasing the image view and recreating it on the fly.

Dan

[Mr Jack]

Seventy 320x150 images will come to around 13Mb, not even enough to overflow the texture memory. You shouldn't have to worry about storage space for it at all. If UIImage isn't cutting the mustard, it's time to crank up OpenGL ES. It won't have any trouble doing the heavy lifting on this.

[ZunePod]

You should start releasing some shit

[crabFish]

Originally Posted by Mr Jack

Seventy 320x150 images will come to around 13Mb, not even enough to overflow the texture memory. You shouldn't have to worry about storage space for it at all. If UIImage isn't cutting the mustard, it's time to crank up OpenGL ES. It won't have any trouble doing the heavy lifting on this.

Well, the problem might be that if these 13MB isn't the only thing taking up space in memory then it might be an issue...?
Also, 13MB for just one animation is pretty much in a limited working environment as this - and for a device to load 13MB, well... That is bound to take some time, a lot of time actually... So I think one should worry if trying to play an animation this big straight off... Maybe OpenGL ES will take care of that, I don't know. Still seems like there's an awfull lot of MB's to load and there is still a limited amount of available memory which has to show up somehow somewhere?
Or I might be wrong?

[davejas69]

I was having the same issue and I ended up creating a video file of
my animation in Quicktime Pro and just playing the video file.
It is MUCH smaller.