My RPG-like game has random battles. When the player enters a random battle, it is necessary for my game to load the textures used within that battle (animated monsters, animations, etc). The textures are quite a lot, and rather big (the battles are very graphical intensive).
Such process consumes significant time. And while it is loading, the whole screen freezes.
The game's map freezes, and the wait time is significant - I personally find it annoying.
I can't afford to preload the textures because, after doing some math, I realized:
If I preload all the textures at the beginning of the game, the application will definitely crash.
If I preload the textures that are used in a specific map when the player enters the map, the application is very likely to crash as well.
I can only afford to load the textures when I need them, and dispose of them as soon as the battle ends.
I'd prefer to not use a "loading screen" image because it affects my game's design and concept. I want to avoid this approach.
If I could do some kind of animation while loading the textures, it would be great, which leads to my question: is that possible? What kind of animation, you ask? Well, how about... you remember when Final Fantasy used to distort the screen while apparently loading the textures? Something like that. But well, distorting is quite a time-consuming process as well, so maybe just a cool frame-by-frame animation or something.
While writing this, I realized that I could make small pauses between textures (there are multiple textures), and during such pauses, I update the screen to represent the animation's state. However, this is very unlikely to happen, because each texture is 2048x2048, so the animation would be refreshed at a rather laggy (and annoying) rate. I'd prefer to avoid this as well.
In a similar bind, i chose to
Convert all my animation textures to gzipped PVR. The load time (depending on the device) is improved by a factor of 2 to 4. Any artefacts caused by a conversion to PVR are not noticeable in motion.
I preload the idle animations (almost always on, except during a skill use or when hurt. I do this during the battle scene's fade-in. I control the fade-in myself on a tick rate of 50 ms, and at every frame i fire-up a preload of one of the idles ( there are a maximum of 8 of them, they take 20 or so ms.).
I have an 'engagement' class which computes the entire fight ahead of time. When an animation becomes un-needed, i unload it. Also, during a 'hurt' animation, i prefetch the next skill animation.
loads of fun. Best of luck with your game.
ps. Dont trust the simulator for actual response times. Go to devices rapidly to determine if you really have a performance issue.
pps. About point 1, that caused a significant size reduction for my app.
Since the battles are supposed to be at random, would it be possible to preload the textures for the next battle before that battle happens? Then the battle can start whenever the loading has completed.
Game decides battle should happen soon
Generate random encounter (monsters/background/etc?)
Load textures for the encounter
Start the encounter after the textures have loaded
The battles are still random, it's just that the encounter has been determined a bit before the user is aware a battle is about to happen.
You could load lower-resolution textures first, and in a background thread (NSOperation I think) kick off the load for the bigger textures, and 'swap' them when done.
As for animation, a lot of games start by loading the small textures when the player is far away, and as they get closer, the higher-res textures will 'fade' in
Related
I want to make a pool game where the user can pinch the pool table to zoom so he can
precisely shoot the pocket.
So, this means I need a large pool table graphic.
What is the best way to handle such a situation in cocos2d?
How do I load the graphic? What is the limitation on graphic size?
I have a lot of doubts because Im not sure which path to take.
Regards
Mirza
For something as simple as a pool table it might be better to render it all using vector graphics. This means you will need less graphics (perhaps only a few for textures) and you get infinite zooming without all the graphic image overhead.
For my game I am working on a 2 player mode where the player can swipe left to see what the other player is doing. Effectively 2 iPhone screens.
My question is, are any sprites, particles outside the screen (I.e. for player 2) being rendered and processed as if they are on screen? If so, is there a way to get cocos2d to handle these differently so that they do not slow down the overall game performance? (fps)
The only way i know to lower overhead is to make the sprite.visible property NO, in which case the draw wont be computed at all. Off-screen sprites will be drawn if they are set as visible. Also, before making any 'FPS' related decision, make certain you verify what you get on real devices. You will find that the simulator falls very short, performance wise.
If you set the visible property to NO, it will indeed reduce overhead. If a sprite is outside the screen, it will still draw itself (so yes, you can set it to NO to reduce some overhead). But in any case, regardless of the visible property value, all sprites will still consume some memory and such.
If they have animations, they will keep on playing. You can unschedule those sprites and free some more processing.
A question I made regarding this visible property may help you: Does the .visible property affect performance?
I have a game with a number of animated "monsters". The animation is made with ~20 png images for each monster. So I use UIImageView with setted animationImages:.
The problem is that sometimes there can be a lot of monsters on the screen (up to 110 in total and up to 10 different). So when all of them are on the screen at the same time - I see animation problems (very low fps).
Please, can you give me some advice - how can I solve this problem?
You can use CoreAnimation as described in this tutorial. It explains pretty well all the techniques you can use to increase the performance from where you are now (first of all it doesn't use UIViews and the standard animationImages, second it makes use of sprites (also called texture atlases) which will not only increase performance but also will make your life a lot more easier when it comes to managing the image resources).
Also you can use CADisplayLink to create a game loop in which you can make all the updates. There are several questions/answers here on SO that describe just that.
I'm developing an iPhone Cocos2D game and reading about optimization. some say use spritesheet whenever possible. others say use atlassprite whenever possible and others say sprite is fine.
I don't get the "whenever possible", when each one can and can't be used?
Also what is the best case for each type?
My game will typically use 100 sprites in a grid, with about 5 types of sprites and some other single sprites. What is the best setup for that? guidelines for deciding for general cases will help too.
Here's what you need to know about spritesheets vs. sprites, generally.
A spritesheet is just a bunch of images put together onto one big image, and then there will be a separate file for image location data (i.e. image 1 starts at coordinate 0,0 with a size of 100,100, image 2 starts at coordinate 100,0, etc).
The advantage here is that loading textures (sprites) is a pretty I/O and memory-alloc intensive operation. If you're trying to do this continually in your game, you may get lags.
The second advantage is memory optimization. If you're using transparent PNGs for your images, there may be a lot of blank pixels -- and you can remove those and "pack" your texture sizes way down than if you used individual images. Good for both space & memory concerns. (TexturePacker is the tool I use for the latter).
So, generally, I'd say it's always a good idea to use a sprite sheet, unless you have non-transparent sprites.
I have a game that's moving fewer than 10 small animated UIImageViews at once, maximum. I'm driving their animation with a CADisplay timer running at 60fps. Here is an example of how I move the views in my update method:
// for each insect in insectArray
insectView.center = insect.hitCenter // I pull a position from my model object
The graphics are 32 x 32 pixels with up to 5 animation frames each, if that helps. They have an alpha channel for transparency. I've profiled and eliminated any in-game calculations as a bottleneck. I've also made the opacity property = YES, for a very small speedup. Having the animated frames playing or not makes no difference.
The frame rates are mostly great, except on older devices like the iPhone 1G and 3G. There I get intermittent stuttering.
Before switching to OpenGL, is there any way to get a bit more performance?
I experienced the same kind of bottleneck with CoreAnimation; it is very limited in terms of system complexity that you can display with decent performance. From what I have read and discussed with others, there is no silver bullet for you (or me) there, sorry!
My usage was actually quite close to yours (no animated frames, though), and using OpenGL ES made it go from painfully sluggish to perfectly snappy, so there's hope for you!
CoreAnimation isn't designed for frame-by-frame animation, you tell it a few keyframes and times, and it will do the rest for you. Why not switch to OpenGL? You can't support the old devices forever...
I agree with FX that there is no silver bullet, but if you provided a little more code, we could make some specific suggestions. Here are a few general ones:
Don't round corners using -setCornerRadius on the UIImageView's layer. You'd never believe how much this can degrade performance
If you're using drop shadows behind your view, make sure you specify a shadow path on the layer as well.
Try turning -shouldRasterize on on the UIImageView layer: [[insectView layer] setShouldRasterize:YES];
Hate to say it, but after this, as others have said, OpenGL is the only other choice.