Hello,
What is the best approach to handle 100000+ small sprites in a PC game?
Its an isometric view game.
Im having around 500-1000 sprites per character (frame-by-frame animation of character moving in 8 possible directions, attacking in 8 possible directions, dying in 8 possible directions, etc.)
Sprites are quite small (some just 16x16), some bigger (64x64).
There are also a lof of buildings and other environment sprites.
The biggest issue is that each character, building and environment element can overlap each other (isometric view).
For example - some tree should be rendered on top of a building or character that is behind it, but same tree sprite should be rendered also behind that building because another tree is behind that building. Its already 3 draw calls. (Those 2 trees cannot be drawn in a batch, because context has t obe switched and draw the building in between). I cannot think of any smart way to put sprites in atlases to optimize draw calls. There is just too many of them.
Currently I have around 1500 draw calls on a simple scene with just 15 different elements (mainly because things have to overlap one another).
If I have so many drawcalls I think its better to abandon sprite atlases. If each of those 1500 draw calls is just a small sprite it might be better (faster) than to have that one sprite in an atlas tha has to be handled by GPU, right?
Do you have any advices or sources mentioning such things?
Side question - what is the biggest atlas size that we can safely use for Windows PC platform?
Regards,
And thanks in advance for any advices and links.
EDIT:
Those images are already done, so Im not considering switching to other technical approach (like splitting charater/buildings into reusable parts and animating them in spline or other technique), I want to use sprite frame-by-frame animation.
just because sprites are drawn over each other doesnt mean they cant be batched
use sprite atlas on all your sprites, 4096x4096
1 Like
Thank you for answering @flasker .
just because sprites are drawn over each other doesnt mean they cant be batched
Can you elaborate please?
I thought that only sprites that are in the same atlas can be drawn with a single batch. If I have to use a lot of atlases it might be very often that some character/building/environment was in a different atlas and multiple draw calls have to happen.
To be more precise in my previous example:
If some tree should be rendered on top of a building, but the same tree should be rendered also behind that building (knowing that tree sprite and building sprite are in different atlases). Its already 3 draw calls. (Those 2 trees cannot be drawn in a batch, because context has to be switched and draw the building from different atlas in between).
Isn’t that correct?
Even if I would use 4096x4096 atlases - it would take around 30-35 atlases. Seems reasonable, but Im afraid that switching context with big atlas requires more from a PC than swiching a conext with small single sprites.
you can just put all your folders in the atlas and it auto makes extra atlas pages if it doesnt fit
also yes, if the tree is in a diffrent page than the building it wont batch together but theres no way to batch them together unless you put them on the same atlas page anyway
for your 100000 characters sprites it doesnt make much difference since only 1 sprite is displayed during the animation, unless you have 10000 characters onscreen which would be hard to batch anyway
the 4096x4096 is very easy to handle, theres no problem to use
Thank you again @flasker for answering
Exactly. That is why I was thinking that it might be not the best idea to use atlases. Why to make GPU handle a big 4096x4096 page of an atlas to draw a 16x16 sprite and then change the context (again big 4096x4096 page to handle) again and again.
Im thinking what is better:
A) to not put sprites in atlases - so only sprites that has to be rendered are handled by GPU (more draw calls, but less texture space to handle by GPU)
B) put sprites in atlases and hope that it will reduce draw calls (being lucky - it might be the case that a few things could be rendered in a batch from the same page of the atlas, but it is not guaranteed) - Im afraid that having 4096x4096 textures to be handled by GPU would be worse performance-wise than handling small sprites - I can’t find a source about that directly.
C) or maybe there is something else that I didn’t think of?
How did they handle so many sprites 20+ years ago?
as far as i know the gpu doesnt work extra just from the sprite atlas, the large image is loaded into memory and takes up ram, unless you unloaded it keeps it in memory for access on demand. What will tax your gpu is like you said drawcalls, rendering and processing stuff, in other words having many sprites on screen unbatched at the same time like you said.
Back then what they did was extremely complex tricks but lots of restrictions, they just didnt allow many different sprites on screen at the same time, for example in mario there was limit of entities on screen if you were on the limit enemies stop spawning which ppl now use to perform many glitches, small screen frame, low resolution 320x160, very small sprites 8x8 or 16x16, few colors, very few frames in each animation(walking only 2 frames), and very few animations(only walk and jump, only one direction and for the other just flip), pallete color swaps for tricks and taking less space and many other things that nowadays are not needed because of powerful hardware
1 Like