Sprite performance: would you say a game with 80 sprites at 60 fps is doable?

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

Sprite performance: would you say a game with 80 sprites at 60 fps is doable?

(18 posts) (7 voices)

Started 1 year ago by gaminghorror
Latest reply from zombie

Tags:

gaminghorror
Member

I have to do a proposal for a game that requires to draw 70 sprites (size 16x160, 32bit png, all being the same image) as the level background on the screen, plus a player character and a few effects so i think it'll end up rendering 80 sprites at any one time. I intend to use a texture atlas for all ingame sprites, which aren't too many. I'm also wondering if it'll be a good idea to use a TileMap but i need to modify that on the fly, so i'm not sure if that ends up performing better than just drawing the sprites "manually".

Is 80 sprites too much for cocos2d iPhone to render this in 60 fps? I've read someone mention that 60 sprites run fine but i'm not sure if the size of the sprites matter or how much. I also recently did a test with 200 characters which ran with 40-50 fps but those were tiny (16x32 or even 8x16) 8-bit images. So i think it may be difficult to get 60 fps although probably not impossible with the right optimizations (i have an idea to use OpenGL draw calls instead of rendering textured sprites instead, eg using flat shaded polygons if that's possible on the iphone).

What do you think? And if you have some tips on what i should be aware of to keep the game running smoothly i'd appreciate that!

I'll certainly make a test next week and let you know about the results i'm getting.

Posted 1 year ago #
hactar
Member

It all depends on what you want to do...

Well the game I currently have running typically has around 70+ sprites (40x40 pixel sprites, 1 1024x1024 background, ui elements of various sizes. There is no physics engine running, I'm always amused when reading people are using physics engines for basic collision checking when a simple boundBox intersect check would suffice. I use spritesheets where ever possible, so the UI elements and sprites are on one sheet, while the background is its own sprite since its too big to fit. That means I have 2 "sprites" on my gamelayer, the background and the spritesheet itself.

My experience: the game typically does run at 60 fps (iPhone 3G and iPod touch 2G, i have no 3gs for testing) with sprites being moved and changed. Only when I move and/or scale the complete gamelayer does the frame rate dip to the 20-40 fps range. I haven't investigated yet why exactly the framerate dips there...

The key here is spritesheet usage. I initially tried doing this with sprites and quickly reached limits, spritesheets saved the day.

Posted 1 year ago #
Steve Oldmeadow
Administrator

The performance tests http://www.cocos2d-iphone.org/wiki/doku.php/perf_test:index would say it is doable. In practice there are many factors to consider e.g what kind of controls are you going to have? Rapid multi touch can really chew up processing time. What sort of AI will there be? What texture format are you going to use - if you could use PVR that would help.

The general question is what you want to do possible on the hardware. There is nothing in cocos2d to stop you using the hardware to its fullest.

As for your question about flat shaded polygons - yes you can do that. Look at the drawPrimitives or GLESRender stuff. You can even get primitive shading effects by specifying different colours for the vertices.

Posted 1 year ago #
gaminghorror
Member

Thanks in general for sharing your experiences. I think i should be able to get to 60 fps. The game doesn't have an AI, no physics (nothing that needs a physics engine anyway). It is touch-based but since i worry more about render performance and not CPU i don't think it'll make the difference performance-wise.

I don't think PVR is an option as the loss in quality is quite noticeable. It probably works best on photographs but the results for pixel art or illustrations are often terrible. However i think some sprites may lend themselves to 16 or even 8 bit color without a noticeable quality loss.

@Steve: yes that's what i had in mind, since certain sprites are basically flat filled rectangles with a color transition from one end to the other i should be able to replace them with primitives. Can you imagine that to be faster than drawing a sprite of the same dimensions?

Posted 1 year ago #
Steve Oldmeadow
Administrator

@gaminghorror - I'm not sure whether it will be faster, I think it might depend on the size of what you are rendering. I have played around with using coloured "quads" vs point sprites vs normal sprites and found the performance difference was not noticeable in many circumstances. I think batching the draw calls is the most important thing.

Posted 1 year ago #
gaminghorror
Member

Damn. I made a test tweaking the PerformanceSpriteTest from cocos2d which uses a spritesheet, so i think it does sprite batching. I replaced the grossini_sister with the image i intend to use (PNG, 32-bit, 14x160), replacing the #2 slot of the performance test. Then i tweaked the increments to go +/- 25 and the results on an iPhone 3G are:

50 sprites: 60 fps
75 sprites: ~50 fps (highly fluctuating)
100 sprites: ~42 fps (highly fluctuating)

I'd like to have 75 sprites plus a little extra for background, player sprite and UI elements running at 60 fps but from that test it doesn't seem feasible. I've seen similar games run smoothly but they simply used flat polygons and not sprites, which is why i'm thinking that draw primitives would be faster.

Or maybe i'm missing something here. It's not a representative test.

Posted 1 year ago #
gaminghorror
Member

Ok, that was stupid of me. I should have used test #10. So i replaced that with my image and tweaked it to display n times the full size of my image. These are my results:

up to 100 sprites: 60 fps
125 sprites: ~60 fps (it starts dropping below 60 frequently)
150 sprites: ~51 fps
175 sprites: hard to tell, fluctuates heavily between 30 something and 50 something
200 sprites: ~42 fps

It's weird how 175 sprites leads to such fluctuating fps, i couldn't get a good reading as the counter displayed many numbers with a leading 3, 4 and 5.

But in any case this looks better and actually doable in 60 fps! Great! :)

Posted 1 year ago #
Karl
Member

Just bear in mind that a background image takes a lot more processing power than a small sprite.

Posted 1 year ago #
gaminghorror
Member

@Karl: thanks for pointing that out. By adding a background image the fps dropped noticeably, it goes below 60 fps with 75 sprites already. And it doesn't seem to matter much whether i use a single big image or using GL_REPEAT to tile a 32x32 image.

Posted 1 year ago #
hactar
Member

My background image is a pvr, as pvrs work great for organic type background pictures...

Posted 1 year ago #
riq
Key Master

@gaminghorror: remember that the bottleneck of 2d games is the fill rate. So try to use whenever possible 16-bit textures, or, as @hactar mentioned, try to use pvr textures for the background image.

Posted 1 year ago #
mhussa
Member

If you're prepared to put in the effort It is possible to get decent image quality out of pixel art PVR's, The key is to remember the 4x4 bleed zone. The best thing I can suggest is to use the imgtec pvrtextool utility. I got better results out of the GUI than the command line though (probably missing some params).

A key feature of the pvrtextool is the "border" option, it copies 4 reflected pixels deep around each edge to the outside of the texture (imagine a piece of paper with four of its edges folding out). The reflected pixels then bleed into their original source data but don't distort the texture data (the visible portion). The border is clipped out of sight when rendering. I replicated the behaviour into my tiled images and it removed the horrible tiled edge artifacts. Fully opaque backgrounds work well with this, but transparent images still have horrible bleeding halo artifacts. 2bpp PVRTC compression was too horrible but 4bpp was actually pretty good.

http://imaginationtec.net/forum/forum_posts.asp?TID=565

It gave my little overhead racer quite a speed boost going from 16bit images to 4bit images which saves a lot of texture memory and transfer bandwidth. I went from 17MB texture memory to 10-11MB for the largest maps (100x100).

I've attached a few more screenshots to my webpage so you can see the quality. A small amount of quantising effects like in jpegs can be seen in some areas but you'd have to be looking for them while the scrolling had stopped so not really noticeable.

It takes some work but not impossible.

Posted 1 year ago #
Karl
Member

I'm curious...

Does this mean that using the "border" option will increase the size of the output texture? And if so, does that mean you have to change your texture coordinates in code to compensate?

Posted 1 year ago #
mhussa
Member

^ If you use the pvrtextool it scales the texture inwards to add the borders.

You can emulate the border option yourself using cut and paste (no need to scale it) and then use the pvrtextool to compress it.

The border pixels get "polluted" by the bleeding artifacts instead of your tile/texture which is in the centre. I've used it in a tiled map and I specify 8x8 margins. The tiled map loader chops out the tile without the artifacts. Looking at the PVR in pvrtextool you can see how the borders are bled into by each texture but they stop at the tile boundary (4x4 pixels).

I guess a picture is worth a thousand words so here goes:

The background before PVR:

The background after pvrtextool has been at it:

Notice how in the centre tile the right tile has bled into the border. Which is OK because I only want the tile graphic data inside the border.

Its quite a nifty trick to get around the quality issues AND you get to keep the graphics using a 32bit colour range but using 4bits per pixel.

Posted 1 year ago #
hactar
Member

Its very similar to the trick I use in my update for mkatlas.pl (http://code.google.com/p/cocos2d-iphone/issues/detail?id=549) which copies the edge row into the corners. I use it to fix problems with artifacts when using mipmapping, and it should have similar effects for pvr artifacts. Maybe riq would like to finally add it to the trunk? ;)

Posted 1 year ago #
gaminghorror
Member

FYI, i made an isolated performance test that was able to display 100 sprites with a PVR background at 60 fps. The background was 512x512 but i can actually go with two 256x256 backgrounds in a spritesheet as the 32-pixel borders on top and bottom are covered with other graphics anyway.

Posted 1 year ago #
riq
Key Master

@hactar: Since @zombie is the author of mkatlas.pl and I don't have test cases for it, I was waiting for @zombie to approve the patches.
Do you have some test cases for mkatlas.pl ? If so, I'll test it using the test cases, and if everything works ok, I'll approve the patches.

Posted 1 year ago #
zombie
Member

I will do that after submission next week. Quite busy right now. Sorry for the wait.

Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.