particle persistence

Started by
4 comments, last by GameEngineer_gi 14 years, 1 month ago
Hi, My question revolves around how "particles" like tank tracks, shell casings and other debris remains in a scene when there could be hundreds perhaps thousands of them. Here's a case for my point. Take RoboKill game http://www.rocksolidarcade.com/games/robokill/ Stay in a room and shoot for a long time and you'll see shell casings and wall debris particles stay on the ground, even if you leave a room and come back. How is this done and still maintain performance? Do they bake the particle image into the underlying texture before leaving the room? Do they just keep the particles positions and keep rendering them even if you reenter a room? I need to experiment but it seems to me that eventually the system performance will drop too much. Or perhaps not since the games I'm thinking of are 2D and rendering particles, especially if they are part of the same texture atlas (ie. no texture switching in the frame render), is not that expensive if batch rendered. Steve
Advertisement
Quote:Original post by smjones
Do they bake the particle image into the underlying texture before leaving the room? Do they just keep the particles positions and keep rendering them even if you reenter a room?

Hybrid. They use a bitmap to cache the particles. They store the particle positions and when you enter a room it renders to the bitmap and shows it to you as a cached bitmap. When you move rooms it's wiped and the next room's particles are rendered. In flash it works really well. Example from my site. (w,a,s,d ignore the bugs).

Actually in that game you linked there's a pause as you walk between rooms. The pause is longer for rooms with a lot of particles in them. Flash was designed to push pixels out fast though and those particles in the game are just pixels. Example (click, this is a naive implementation for Flash Player 9. It can be made so much faster).

For a map that moves around you can use another technique. One large texture atlas for regions of particles. Store all of the particles positions in a grid or hash grid spatial partitioning system. The cells in the grid have a fixed size (like 50x50). As you walk new cells are revealed and you just render the particles in those cells to the cell bitmap. Other cells behind you are removed and reused. In a 2D grid you can imagine that going right you'd add a column of cells and remove a column from the left side. You're basically wiping the ones on the left and placing them on the right with the particles in the corresponding cells. Simple concept and it can handle thousands of particles (or more really).

[Edited by - Sirisian on February 25, 2010 5:50:29 PM]
So when you say those particles are just "pixels", all graphics are just pixels. Are you saying that those particles are just single pixels (aka, dots)? I don't believe they are if that is what you are saying. If you watch a debris or shell casing particle, they scale a bit while "falling" to the ground then they come to rest. At some point the texture baking happens as you suggest.
You explanation explains or gives a possible explanation why there is no room saving in the game. The saved missions are only the fact that you completed a mission or not and all of your inventory and score is saved. But to be able to save which rooms you finished even if you leave a Mission early, they would have to write those room bitmaps to the PC also. I don't think that is happening. These room bitmaps with cached particles must be completely done in memory. Once you leave a mission all bitmaps are wiped and when you renter the original bitmaps are loaded. Something like that at least.

I am not trying to accomplish the exact same thing and frankly having all of the particles remain on reentry isn't that important to me. In most 3D games the bad guys and particles just fade out after a while anyway.

I liked your little demos by the way. The tank tracks was great. If you did those just to help answer my post, I very much appreciate you putting in the time.

Regards,
Steve
You don't have to store the actual bitmaps. You only need to store enough information that allows you to rebuild them when needed. So for each visited room, you would store the position and the texture id for each particle. It will take some time to rebuild a particle bitmap that way, but it's more memory efficient (unless you have enormous amounts of persistent particles). Having a particle bitmap overlay instead of individually drawing particles will be less efficient for small numbers of particles, performance-wise, but more efficient for large numbers. You'll have to run some tests to see what works best for your situation.
Create-ivity - a game development blog Mouseover for more information.
On a project i worked on, a lot of effort was spent on building the decal cache system. Then it turned out to be a lot more efficient to draw a ton of decal quads rather than a large collection of them with a lot of wasted space.
Thanks for the suggestion Captain P. I like the overlay idea.

Steve

This topic is closed to new replies.

Advertisement