Optimal use of frame buffers in a 2D game.

[corey__cakes]

Greetings,

I have a question regarding how I should use frame buffers in OpenGL 3.3 for a 2D game I'm slowly making. I tried to write down all the frame buffers I think I'd need. Each framebuffer would be the dimension of the screen, so 640x480 for instance. I came up with something like this:

Use an individual frame buffer for:
- The tile-based level/map,
- NPCs, Entities, and objects
- Flat Colored Primitives (for debugging, could eventually take out)
- UI
- Light map

There are no decent tutorials on implementing 2D lighting. Every tutorial I've seen and read has either been for 3D or is conceptual stuff. I understand the concepts and all, but the only way I can think of implementing 2D lighting to support multiple lights is with each light having a frame buffer for every light, which doesn't sound right to do.

And if I later decided to implement normal mapping for my lights, would that double the amount of frame buffers I'm using? That's a lot of them.

Any help, guides, links, suggestions would be deeply appreciated. Thank you.

Can't wait for Rick and Morty season 3

[Falco Girgis]

Are you sure that what you are talking about here is not "vertex buffers" rather than "frame buffers"?

Frame buffers are the texture that the shaders are all rendering to that is the final image displayed on the screen. Most games use two of them, a back buffer and a front buffer and swap between them, so one is being rendered while the other one is being displayed. Nobody uses separate "frame buffers" for different types of objects.

Vertex buffers objects (VBOs) on the other hand are a type of datatype that is used to store all geometry, vertex attributes, and indices in the case of indirect rendering on the GPU-side. I have a feeling that's what you're referring to, right?

[corey__cakes]

Are you sure that what you are talking about here is not "vertex buffers" rather than "frame buffers"?

No, I'm actually talking about user-defined frame buffers, frame buffer objects.

Maybe this is a dumb question and I'm overthinking the problem. I understand the whole front buffer and back buffer. One is being shown on the screen while the other is being drawn to. I know vertex buffer objects store data like vertex coordinates, texture coordinates, or vertex color.

My biggest dilemma as a programmer is not knowing the syntax and concepts of C++. I've made demo projects that use concepts I've learned about. Like VBOs and a whole slew of Lua wrapping. My biggest dilemma is knowing how to implement it all together into a single package that isn't horrendous.

[dandymcgee]

This seems to me like a solution you came up with yourself. My question is: what is the problem? If you can elaborate on what problem you're running into more specifically than "my code is a mess", perhaps we can offer you some ideas.

[corey__cakes]

This seems to me like a solution you came up with yourself. My question is: what is the problem? If you can elaborate on what problem you're running into more specifically than "my code is a mess", perhaps we can offer you some ideas.

I'm having this problem with shaders and frame buffers. Let's say, for instance, I want to be able to render the background texture, then render the player texture on the background. If I try to render to only the region the player occupies using a shader, he will be drawn, but the box (the texels that are color keyed out) around him will be black or flickering.

So I can't draw something, then draw something over that with a shader. My solution to this would be to use a frame buffer. Render anything that isn't in the background to a frame buffer, then send the frame buffer's and the background's textures to a shader to sample and find which fragment should be drawn.

Does that make sense?

Do I have to send every texture I want to render and all the data to the scene to the same shader? That is a lot of data for one shader.

[dandymcgee]

You need to enable blending. This will allow you to determine for each pixel whether it should be left alone, overwritten, or blended with the new pixel.

https://learnopengl.com/#!Advanced-OpenGL/Blending

Note: This has nothing to do with frame buffers. Like Falco said, you don't need a million frame buffers, you just need two (which is generally handled for you, so really you can pretend there's one and ignore that they exist aside from the Swap call at the end of each frame).

[corey__cakes]

Thank you.

I guess I thought blending was a part of the fixed-function pipeline, and when I use shaders, any blending I wanted to occur is calculated in the shader. I guess I should study farther in some books. Thank you though.

[dandymcgee]

Thank you.

I guess I thought blending was a part of the fixed-function pipeline, and when I use shaders, any blending I wanted to occur is calculated in the shader. I guess I should study farther in some books. Thank you though.

I recommend reading through http://www.learnopengl.com from the start. I've used it extensively while learning OpenGL and it's by far the most accurate and well-written resource I've yet to find on the web.