Optimization for a game made using pixel art

Hi,

This is surely a dumb question but I always wondered what would be the best optimized option in a pixel art context.

About, let say, a particle system for a game with sprites made in pixel art, where everything in the game is pixel perfect (one Unity unit = one pixel, and every positions are clamped to be integer values), what would be the most optimized solution:
- Instantiate hundreds of 1x1 quads (means, well hundreds of instantiated quads...)
- Create a "big" texture at runtime, and write pixels every frames (means, a lot of transparent pixels, a Get/SetPixels every frame)

Thanks for your suggestions.

 

In the context of particles, the most optimal option would probably be using Unity's built-in particle system. It works fine in 2D, and chances are you won't beat the performance of the built-in solution, at least not without significant effort.

 

Well ok it works with Unity particle system (is there a way to force particle emitted with Unity particle system to be pixel perfect? - it's maybe a question for another thread).
So in a way you suggest that hundreds of quads are better than hundreds of pixels drawn in a texture every frame ?

 

Actually I'm suggesting that a feature implemented on the engine side (i.e. C++) is very likely to run faster than the same feature implemented on the scripting side (i.e. C#). I'm assuming in this case that most of the particle system is implemented engine side.

I have no insight as to how quads vs. texture will perform in this scenario, though my hunch is quads will perform better initially, but texture will win as the number of quads increase. My point was that I personally wouldn't bother with reinventing this particular wheel since it's already done in the engine.

 

You could do it via shader, they tend to be a pretty fast solution. (depending on complexity)
As far at the particle system goes, you could pull it off that way as well. Start by making sure there is no rotation or scaling or anything that would make it not pixel perfect, then just access the particles at run time to force their positions to "snap" by rounding (or whatever) their positions. I don't know how much that would impact performance, but should be minimal if you aren't going too nuts with amount of particles.

 

Ok I think particle was not the good example to choose.
My question was more about the best choice between having hundreds of 1x1 quads displayed and a big texture written every frame.

But thanks for your interesting answers anyway

 

Typically for that type of thing, that is exactly what particles are created for. But there are always things that don't fit.

In the case of quads vs. texture, probably quads as long as they share textures. Typically geometry is much cheaper as it would be GPU, img proc would normally be CPU. I would go with the quads.