Questions about Shaders and 2D sprites

OpenGL Development
#1

I have a few questions about shaders and there use with a 2d game.

If I have a basic basic basic sprite batcher.
I mean it only uses vertex arrays and texture coord arrays, data in the array is used by calling glDrawArrays based on GL_QUADS,
and the draw function loads the vertex position and texture coords into the array.

drawGame function



//Clear the GL_COLOR_BUFFER_BIT and set up for the use of vertex and texture coord arrays
batcher.begin();

//Place a sprites data into the vertex and texture coord array
// By passing in : x position, y position, sprite Width, sprite Height, and the texture coords
batcher.draw(10, 10, 64, 64, 0, 0, 1, 0, 1, 1, 0, 1);

//call the render function which holds the glDrawArrays call then disable the use of  vertex and texture coord arrays
batcher.end()

What is the benefit of using a shader program or is there even any benefit if I’m only using 2D?

And honestly

What is exactly is a shader program?
What is its purpose?
Why should I care to use them?
What can I even do with it I I am to implement one?

Thanks! Also please thorough explanations would be great as I’m new to openGL / graphics programming and have no idea what any of this is :frowning:

#2

A shader program is a set of small programs that is run on the GPU for each vertex and fragment (pixel). Newer OpenGL versions also support shaders that run on each full primitive (geometry shaders). Although vertex shaders are pretty worthless for 2D, fragment shaders can be very useful. It’s for example possible to do things like lighting, use multiple textures in complex ways, etc. Since it’s fully programmable you can treat your data in any way you want. Geometry shaders are also very useful for rendering sprites. They allow you to render a single “point” (only send a single “primitive” with the data of a sprite; position, rotation, size, color, etc) and expand this point into a quad on the GPU. This cuts the CPU and memory bandwidth cost by a lot by offloading heavy math to the GPU which is many times faster than the CPU and made for exactly those kinds of calculations. However, this requires a graphics card that supports OGL3. That limits your user base a bit, and excludes most people with older computers, so they’re rarely used in practice even though they are much much faster. I also wouldn’t recommend you to dive straight into geometry shaders if you’re completely new to shaders.

I doubt that you’ll have much use for shaders right now. If all you need is texturing you can easily get by with the fixed functionality pipeline. If you however want to generate textures or lighting or so, shaders may be useful.

#3

IMHO shaders are useful even for 2D; it will help you get a better understanding of how the modern GL pipeline comes together and where you can optimize your game. It also opens the world to a lot of cool effects you might not have realized were possible for a 2D game, for example this.

For an intro to shaders, see here:

If you are using the fixed function pipeline, you can just stick to the “default” shader and work with built-in attributes, like gl_MultiTexCoord0 and gl_Color. If you start getting into 3D fixed-function features like lighting, fog, texture combiners, etc. it almost makes more sense to work with shaders, if nothing else than to have a stronger understanding of how these effects are achieved. (And IMO it’s easier.)

#4

I agree, some features (especially multitexturing) are just completely retarded when using fixed functionality. A simple 3 line shader does the trick in way less code in that case.

#5

But the code for creating the “ShaderProgram” class, which compiles, links, and checks errors for shaders is much biggern than the 5 lines you need for using the fixed functionality.

It’s the same with using VertexArrays over glBegin() / glEnd(). VertexArrays are better, and I suggest to use them and prefer them myself, but glBegin() and glEnd() are easier to a beginner.

I agree. Using a shader should be preferred over using the fixed functionality, but you just need to write the tools first. But if you finished that (or followed davedev’s tutorials), everything else is much easier.

TL;DR: Use the new functionality, not the deprecated, fixed functionality.

#6

You write the code for ShaderProgram once and use it over and over. Any decent standard library like LibGDX or Slick will have done that for you. Beginners really need not start with raw OpenGL calls.

#7

Best tuts I used to learn es 2.0:

http://www.opengl-tutorial.org/beginners-tutorials/tutorial-3-matrices/ //A lot of great tuts

http://www.opengl.org/archives/resources/faq/technical/transparency.htm

http://meatcat.info/wordpress/?p=24 //I really like the idea of the Helper.class

best regards

#8

So many questions

About shaders-

@theagentd :
Why are vertex shaders exactly useless for 2D games? Cause don’t sprites have there vertex positions always move and if I use a texture atlas cant I use the vertex shader to manipulate those point too? Or am I just not really understanding what a vertex shader is really for?

@davedes :
I looked over your tutorials and I just have few questions

Once the shaders are loaded in and you link them to the openGL context, how does openGL know when you want to use them? Once they are linked are they just automatically used on everything you draw? Or is there something else that says only use the shaders on these group of sprites?

@phibedy
Thanks for the links I will look into them for sure!

#9

Vertex shaders aren’t completely useless for 2d, no, but they are more infrequently used. Scaling and tinting can easily be done in a vertex shader though.

OpenGL knows how to use a shader program when you call glUseProgram to activate it, at which point it applies to everything you draw afterward (even immediate mode). You deactivate it by calling glUseProgram on another shader (or glUseProgram(0) to disable all shaders). It’s about as expensive as a texture bind.

#10

I didn’t say “useless”, but they have a very limited use. Sprites are usually so dynamic that you simply generate new data and upload it to the GPU every frame. Yeah, it’s possible to do some interesting effects like per-vertex distortion. You can also do things that don’t have to be done per pixel like calculating atlas texture coordinates from a tile index or something. The thing is that most of those features can be done quickly on the CPU when you generate the data.

#11

[quote=“theagentd,post:10,topic:40633”]

This is extremely interesting, but how is this possible?
Do you just give the sprite’s x and y origin along with its width and height to the vertex shader and it automatically does it?

I know you said it could be done quickly on the CPU, but is that better than just passing in all that information to a function and having it calculate it all on the fly?

#12

You messed up the quote…

Vertex shaders don’t do anything automatically, that’s the whole point of shaders. You have to do the calculation yourself. You just have to do it the exact same way you do it in Java, but code it in GLSL. Vertex shaders run for each vertex in the sprite, so the vertex shader is run once for each corner in the quad.

Concerning performance, you really won’t win anything unless you have access to geometry shaders. Since the extra data (size, rotation, etc) has to be duplicated to be accessible in the vertex shader, you actually lose performance. Sprite rendering is often RAM speed bound, which means that the CPU is waiting a big chunk of the time for data to be written to RAM and then copied to the GPU. Adding more data = less performance. Doing more arithmetic calculations = no difference since it won’t increase the memory bandwidth. With geometry shaders you can cut down on the amount of data you need to send (1 “point” with position, size, texture atlas index, color instead of 4 vertices with position, color and texture coordinates).

#13

Yup without any super cool multi-threading like theagnetd, I got close to double performance when using geometry shaders in my sprite batcher. But with a basic VA sprite batcher you will almost always be fill rate limited before hitting a cpu bottle neck.

My personal advice is to not worry about it too much right now. Maybe use one that does nothing for now just so you know how to set them up.