If you're running AdBlock, please consider whitelisting this site if you'd like to support LearnOpenGL (it helps a lot); and no worries, I won't be mad if you don't :)

1. Introduction
2. Getting started
   1. OpenGL
   2. Creating a window
   3. Hello Window
   4. Hello Triangle
   5. Shaders
   6. Textures
   7. Transformations
   8. Coordinate Systems
   9. Camera
   10. Review
3. Lighting
   1. Colors
   2. Basic Lighting
   3. Materials
   4. Lighting maps
   5. Light casters
   6. Multiple lights
   7. Review
4. Model Loading
   1. Assimp
   2. Mesh
   3. Model
5. Advanced OpenGL
   1. Depth testing
   2. Stencil testing
   3. Blending
   4. Face culling
   5. Framebuffers
   6. Cubemaps
   7. Advanced Data
   8. Advanced GLSL
   9. Geometry Shader
   10. Instancing
   11. Anti Aliasing
6. Advanced Lighting
   1. Advanced Lighting
   2. Gamma Correction
   3. Shadows
      1. Shadow Mapping
      2. Point Shadows
   4. Normal Mapping
   5. Parallax Mapping
   6. HDR
   7. Bloom
   8. Deferred Shading
   9. SSAO
7. PBR
   1. Theory
   2. Lighting
   3. IBL
      1. Diffuse irradiance
      2. Specular IBL
8. In Practice
   1. Debugging
   2. Text Rendering
   3. 2D Game
      1. Breakout
      2. Setting up
      3. Rendering Sprites
      4. Levels
      5. Collisions
         1. Ball
         2. Collision detection
         3. Collision resolution
      6. Particles
      7. Postprocessing
      8. Powerups
      9. Audio
      10. Render text
      11. Final thoughts
9. Guest Articles
   1. How to publish
   2. 2020
      1. OIT
         1. Introduction
         2. Weighted Blended
      2. Skeletal Animation
   3. 2021
      1. CSM
      2. Scene
         1. Scene Graph
         2. Frustum Culling
      3. Tessellation
         1. Height map
         2. Tessellation
      4. DSA
   4. 2022
      1. Compute Shaders
         1. Introduction
      2. Phys. Based Bloom
      3. Area Lights
10. Code repository
11. Translations
12. Privacy
13. About

Final thoughts

In-Practice/2D-Game/Final-thoughts

These last chapter gave a glimpse of what it's like to create something more than just a tech demo in OpenGL. We created a complete 2D game from scratch and learned how to abstract from certain low-level graphics concepts, use basic collision detection techniques, create particles, and we've shown a practical scenario for an orthographic projection matrix. All this using concepts we've discussed in all previous chapters. We didn't really learn new and exciting graphics techniques using OpenGL, but more as to how to combine all the knowledge so far into a larger whole.

Creating a simple game like Breakout can be accomplished in thousands of different ways, of which this approach is just one of many. The larger a game becomes, the more you start applying abstractions and design patterns. For further reading you can find a lot more on these abstractions and design patterns in the wonderful game programming patterns website.

Keep in mind that it is a difficult feat to create a game with extremely clean and well-thought out code (often close to impossible). Simply make your game in whatever way you think feels right at the time. The more you practice video-game development, the more you learn new and better approaches to solve problems. Don't let the struggle to want to create perfect code demotivate you; keep on coding!

Optimizations

The content of these chapters and the finished game code were all focused on explaining concepts as simple as possible, without delving too much in optimization details. Therefore, many performance considerations were left out of the chapters. We'll list some of the more common improvements you'll find in modern 2D OpenGL games to boost performance for when your framerate starts to drop:

• Sprite sheet / Texture atlas: instead of rendering a sprite with a single texture at a time, we combine all required textures into a single large texture (like bitmap fonts) and select the appropriate sprite texture with a targeted set of texture coordinates. Switching texture states can be expensive so a sprite sheet makes sure we rarely have to switch between textures; this also allows the GPU to more efficiently cache the texture in memory for faster lookups.
• Instanced rendering: instead of rendering a quad at a time, we could've also batched all the quads we want to render and then, with an instanced renderer, render all the batched sprites with just a single draw call. This is relatively easy to do since each sprite is composed of the same vertices, but differs in only a model matrix; something that we can easily include in an instanced array. This allows OpenGL to render a lot more sprites per frame. Instanced rendering can also be used to render particles and/or characters glyphs.
• Triangle strips: instead of rendering each quad as two triangles, we could've rendered them with OpenGL's TRIANGLE_STRIP render primitive that takes only 4 vertices instead of 6. This saves a third of the data sent to the GPU.
• Space partitioning algorithms: when checking for collisions, we compare the ball object to each of the bricks in the active level. This is a bit of a waste of CPU resources since we can easily tell that most of the bricks won't even come close to the ball within this frame. Using space partitioning algorithms like BSP, Octrees, or k-d trees, we partition the visible space into several smaller regions and first determine in which region(s) the ball is in. We then only check collisions between other bricks in whatever region(s) the ball is in, saving us a significant amount of collision checks. For a simple game like Breakout this will likely be overkill, but for more complicated games with more complicated collision detection algorithms this will significantly increase performance.
• Minimize state changes: state changes (like binding textures or switching shaders) are generally quite expensive in OpenGL, so you want to avoid doing a large amount of state changes. One approach to minimize state changes is to create your own state manager that stores the current value of an OpenGL state (like which texture is bound) and only switch if this value needs to change; this prevents unnecessary state changes. Another approach is to sort all the renderable objects by state change: first render all the objects with shader one, then all objects with shader two, and so on; this can of course be extended to blend state changes, texture binds, framebuffer switches etc.

These should give you some hints as to what kind of advanced tricks we can apply to further boost the performance of a 2D game. This also gives you a glimpse of the power of OpenGL: by doing most rendering by hand we have full control over the entire process and thus also complete power over how to optimize the process. If you're not satisfied with Breakout's performance then feel free to take any of these as an exercise.

Get creative

Now that you've seen how to create a simple game in OpenGL it is up to you to create your own rendering/game applications. Many of the techniques that we've discussed so far can be used in most 2D (and even 3D) games like sprite rendering, collision detection, postprocessing, text rendering, and particles. It is now up to you to take these techniques and combine/modify them in whichever way you think is right and develop your own handcrafted game.

HI