Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

iOS Drawing high volumes of particles

B

BlobbleGame

macrumors newbie
Original poster
Mar 4, 2011
15
0
In my last game Blobble I was drawing a few hundred point sprites at a time and noticed a significant drop in frame rate if that number was push to near one thousand.

I have a game planned that requires drawing a possible 90,000 particles at at least 30fps. Is this possible? If I could draw each pixel (extremely processor intensive I know) then it would be rather easy, but other than that how can I increase point sprite throughput?

It seems as though this game has got it sorted:
Sand Slides

I'm not completely reliant upon point sprites for this game though. The particles will be 3 pixels wide at most so literally anything drawn at this scale will look like a particle.

Any ideas?

Thanks
 
This may sound obvious but the fastest way to draw anything is to not draw it! Most likely some of your 90,000 particles will be obscuring the others. An efficient way of culling your drawing to only draw the visible ones will probably result in a good improvement in throughput...
 
Your logic is flawless, but unfortunately it won't work all of the time. At the start of each game all of the particles will be visible.

The idea is that a 300x300 grid is the playing space and at any one time there could be 300x300 = 90,000 particles filling it, each taking up maximum space (1x1) in this example.

Sand Slides Press Release:
...featuring our unlimited particle engine allowing for more particles than you can shake a stick at, in realtime!
Click to expand...

Apparently they can handle 'unlimited' particles which suggests that they can draw each pixel in realtime so the actual number of particles is irrelevant.
 
Clearly they can't handle truly unlimited particles. There will be a well defined upper bound. In your previous game how did you do your drawing? OpenGL ES?
 
I used OpenGL ES yes. It was sufficient and the frame rate holds above 30fps on every compatible device. I actually had an issue with CPU performance on older devices rather than GPU.

If you watch the YouTube video for my game you'll see that I'm changing the background gradient in real time using OpenGL ES. Surely if it is calculating the colour of the gradient at each pixel it could use that same process to lookup the colour of that pixel based upon particles?

I know there are memory access speed issues with this approach and also that the gradient is completely internal to OpenGL ES. I have yet to experiment with Shaders properly, could they be the answer?
 
Thanks for the link, but unfortunately it's nothing new. It's just drawing each particle texture individually, the same as I was doing before.
 
I was just thinking about video decoding (like the VLC app does). Surely each pixel's value must pass through the CPU at some point?

If it manages to render the full screen of pixels in realtime when playing video it must be possible to just read those values from a different location.
 
Is this a 3D game? If not have you considered using cocos2d? It has a class called CCSpriteBatch which basically allows you to use a single texture for multiple objects. At the very least it may be worth taking a look at how they implement it.
 
It's 2D.

I can't find any info about CCSpriteBatch anywhere. Wrong name maybe? What does it do exactly?
 
320 x 480 is 153,600 pixels, or 614,400 bytes at 32bpp. Using 2D bitmap code, you might be able to fill an entire bitmap that large with pixel particles, convert the bitmap to an image, and assign the resulting image to a CALayer's contents at 30 fps.
 
BlobbleGame said:
It's 2D.

I can't find any info about CCSpriteBatch anywhere. Wrong name maybe? What does it do exactly?
Click to expand...

Sorry about that its actually a CCSpriteBatchNode. http://www.cocos2d-iphone.org/api-ref/0.99.5/interface_c_c_sprite_batch_node.html

I'm somewhat new to cocos2d, but my understanding is that it stores a single texture and uses it to draw many sprites, rather than loading the texture for each sprite. So you would use it to speed up drawing multiple bullets that are all identical.
 
firewood said:
320 x 480 is 153,600 pixels, or 614,400 bytes at 32bpp. Using 2D bitmap code, you might be able to fill an entire bitmap that large with pixel particles, convert the bitmap to an image, and assign the resulting image to a CALayer's contents at 30 fps.
Click to expand...

That's more like it :)

Just trying to understand the calculations though:
320 x 480 = 153,600 pixels
32 bits per pixel * 153,600 pixels = 4,915,200 bits = 614,400 bytes = 600KB = 0.585MB.

That isn't much memory and it isn't that much to allocate. That seems reasonable and plausible on 1x resolution iPhone.

But for iPhone @ 2x we multiply that by 4:
2400KB = 2.344MB.

And iPad:
1024*768 = 786,432 pixels
32 bits per pixel * 768,432 pixels = 24,589,824 bits = 3,073,728 bytes = 3001.69KB = 2.931MB

The iPhone @ 2x and iPad would be writing to over 2MB of memory 30 times a second. (No experience with memory throughput) Is this a low amount on iDevices?

This is obviously possible (it must be if video works), but I'll be hitting the CPU and memory with a lot of other calculations too. Is this a large overhead to have?

Any pointers to actually implementing this? What level should I use to do this? CA or OpenGL ES? If there's any information on doing this online I'd be grateful if you could save me some time by pointing me to it :)
 
I decided to come back to this project yesterday and thought of an innovative way of drawing particles with trails.

Here's a video of the engine that I've written to draw "atoms". I'm releasing this simple demo as an app named "Atom Playground".

It draws up to 5000 points with 5 trailing vertices behind each (6 vertices per atom) at 60fps = 1,800,000 vertices per second.

As far as I can tell Gravilux manages 14400 individual points at around 20fps = 288,000 vertices per second.

Both tests were performed on an iPhone 4.

http://www.youtube.com/watch?v=s4Cu_zpiA8c
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back