Too slow when too much sprites

Discuss programming topics that involve the OpenGL API.
Post Reply
daemonicky
Posts: 185
Joined: Wed Apr 13, 2011 1:34 pm

Too slow when too much sprites

Post by daemonicky »

http://www.youtube.com/watch?v=ewh3mBxW ... re=related

I am not sure for the right terminology, I guess the name is sprite. It is the texture which always faces the camera so it is like character in some 2D side scroller.

It happens in almost every game i know. If there is enough sprites it lags, otherwise it is fine.

I wonder, is there a way to make it fast :?: Like removal of unseen sprites by frustrum culling or computing which sprites would be not necessary to render (for example when there is 100 of them in a row so in the end only 1 is visible); I hope computing which are not visible would not be slower than just drawing them :-D ... do You have some experience with it?
Think, touch, movetype, solid, traceline ...
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Post by Spike »

batch them, reduce their size if they're too close to the camera.
transparent sprites can easily result in excessive overdraw, and its often that that reduces the framerate.
anything which causes 50000 movement checks each frame will also not help. :)

note that particle systems are technically sprites too.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Post by mh »

What Spike said, basically. Sprites (and particles) absolutely need to be batched. If you can do some kind of instancing or point sprites you can significantly reduce the vertex submission overhead (although point sprites have their own problems). Alpha testing can help with the fillrate/overdraw problems but it happens quite late in the pipeline so gains are a little on the marginal side. Transforms can be moved to the GPU (they have to be if you're using instancing) which helps a lot too. There's nothing much you can do about fillrate being a bottleneck, and if you set everything else up reasonably well enough, your bottleneck is going to end up being fillrate. At that point you need to stop and have a word with your content creators. ;)
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
daemonicky
Posts: 185
Joined: Wed Apr 13, 2011 1:34 pm

Post by daemonicky »

Batched ... You mean draw several sprites into one big sprite? Or sort them by distance then draw separately those with same texture?

There is also technique to pack textures into one megatexture. http://www.google.com/logos/pacman10-hp-sprite-2.png
Think, touch, movetype, solid, traceline ...
ArchAngel
Posts: 37
Joined: Fri Jun 03, 2011 7:33 pm

Post by ArchAngel »

One of the things that can really slow down sprite like effects is the billboarding part of the render. This is the bit where the texture is oriented to face the camera. One option here is to replace the sprite with a Point sprite. This basically allows you to apply a texture to an OpenGl point. This has a couple of a advantages , one the billboarding is done for free as point sprites always face the view and secondly you reduce the rendered vertices to just 1 per texture.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Post by mh »

The main trouble with point sprites is the dreaded GL_POINT_SIZE_MAX. Billboarding can be done much more efficiently in a vertex shader than on the CPU, and any modern program should use that approach.

Batching means drawing multiple primitives with a single draw call. This is absolutely critical if you're talking D3D as draw calls are expensive for the CPU. Less of an issue for OpenGL, although draw calls are still not free - they do still have a cost, it's just not as high.

In the best possible case you may be able to draw all of your particles with a single glDrawArrays or glDrawElements call. For various reasons that's not always possible, but you should still be looking to group as many as you can into a single call.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
daemonicky
Posts: 185
Joined: Wed Apr 13, 2011 1:34 pm

Post by daemonicky »

mh wrote:Batching means drawing multiple primitives with a single draw call. This is absolutely critical if you're talking D3D as draw calls are expensive for the CPU. Less of an issue for OpenGL, although draw calls are still not free - they do still have a cost, it's just not as high.
Why is it so expensive for D3D? Most games seem to be in D3D, so they get some penalty because of it, right?
Think, touch, movetype, solid, traceline ...
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Post by mh »

daemonicky wrote:
mh wrote:Batching means drawing multiple primitives with a single draw call. This is absolutely critical if you're talking D3D as draw calls are expensive for the CPU. Less of an issue for OpenGL, although draw calls are still not free - they do still have a cost, it's just not as high.
Why is it so expensive for D3D? Most games seem to be in D3D, so they get some penalty because of it, right?
Wrong.

Well-written D3D can easily eliminate the problem (DirectQ is the fastest Quake engine yet it uses D3D) but the point is that you do have to put the effort in to write your code properly. OpenGL is more tolerant of sloppiness, which is both a good thing and a bad thing. It's good because it means that you can get reasonably OK performance without as much effort. It's bad because it results in there being an awful lot of very bad OpenGL code out there (much of it in tutorials).
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
daemonicky
Posts: 185
Joined: Wed Apr 13, 2011 1:34 pm

Post by daemonicky »

Thanks all of you. :)
mh wrote:It's bad because it results in there being an awful lot of very bad OpenGL code out there (much of it in tutorials).
What are good tutorials on OpenGL? I know NEHE.
Think, touch, movetype, solid, traceline ...
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Post by revelator »

hmm only know a few but.

http://www.xmission.com/~nate/tutors.html

or http://www.3dcodingtutorial.com/

and offcourse nehe allthough most nehe tuts are c++.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Post by mh »

daemonicky wrote:Thanks all of you. :)
mh wrote:It's bad because it results in there being an awful lot of very bad OpenGL code out there (much of it in tutorials).
What are good tutorials on OpenGL? I know NEHE.
That's one of the bad ones.

It was good once upon a time - late 90s/early 2000s - but these days it's bad. And even when it was good it was still guilty of a lot of what's described here: http://www.opengl.org/wiki/Common_Mistakes (and has resulted in a lot of what's wrong about it being perpetuated in people's codebases).

This is a great resource for OpenGL these days: http://www.arcsynthesis.org/gltut/
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Post by revelator »

unfortunatly its been a lifetime of patching one engine up to todays standards so i guess most forgot the small everyday wonders they created.

this site itself also got some good pieces ;) and i appologize beforehand that many a tut from me newer quite made it (look above) i simply did to many changes to untangle my own mess :lol:

newer the less new ideas still come by from time to time and somewhere on this forum is a link to the archived section of the old quakesrc for reference.

the loss of the above + some harddrive crashes thought me to make a backup of everything hehe.

ill see if i can dig up some sites ;)
Post Reply