Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 30 Jul 2012
Offline Last Active Jan 31 2014 01:53 PM

Posts I've Made

In Topic: glMapBuffer slow, even after orphaning old buffer?

17 June 2013 - 08:25 AM

There is some useful information and code here:


In Topic: Which situation is more optimal for sprite batching?

29 December 2012 - 01:08 PM

If you were using GL 3+, you can utilize geometry shaders and instancing. 


But really there is no need to restrict your audience to GL 3+ (it's not yet very widely supported, especially not in the casual market). GL 2+ functionality will be more than enough for a 2D sprite batcher.


The simplest way to optimize your sprite batcher is to send as little as possible to GL. Update your uniforms (e.g. ortho 2D projection matrix) only as necessary, and only pass the attributes you really need. If you know some of your data is static, you can use multiple VBOs, otherwise you should just stick to interleaved data.


My sprite batcher uses the following attributes per vertex:


{ x, y, color, u, v }



The color is a packed float. That means 5 attributes per vertex, and 4 vertices per sprite using element indices. One-off transformations (like sprite rotation) are done in CPU before passing vetex position.


Most of the time, optimizing in 2D is more about using texture atlases, improving batch rendering, and minimizing overdraw rather than worrying about small things like whether or not to interleave your VBO data. Besides, 99% of the time a 2D game will become fill-rate bound before it becomes vertex bound.


On the subject of fill rate, you can use hexagons or some other non-rectangular primitive as an optimization (although it comes at the cost of more vertices and may be undesirable depending on you sprites). 


For more reading on my sprite batcher:




Using plain old VBOs or even vertex arrays will be plenty fast, but if you want to squeeze a bit more performance out of GL 2.0 you should look into mapped VBOs:


In Topic: Porting to OpenGL

29 December 2012 - 12:54 PM

As OpenGL version a suggest 3.3+ because almoste all modern graphic card support it and is very similar to OpenGL 4.0.
As GUI library you can use the Qt library.
As math library you can use Eigen (very fast with extensive use of Expression Template and SIMD istruction (SSE, AVX, Neon)).
But you have to learn very well GLSL language. OpenGL is a C API and is not easy to write OOP code. Take a look to (http://oglplus.org/)


GL 3.0+ is still not very widely supported. If you are targeting a casual market, you may want to stick with 2.0 as your target. In this thread it was listed that as few as 51% of Minecraft users supports GL 3.0+. It really comes down to what you need; GL 2 is a fine target for most purposes and can be used in almost the same way as the 3+ programmable pipeline (shaders, custom built-ins, etc). Many drivers will support geometry shaders, FBOs, float textures, etc. through extensions. For example, 93% of drivers support FBO EXT, and it's pretty much a staple in any driver in the last several years. 


GL 2.0 and GLSL < 150 is also more compatible with OpenGL ES, so it will prepare you for iOS/Android/WebGL graphics programming.

In Topic: Most efficient way to batch drawings

29 December 2012 - 12:49 PM

A VBO should be performant enough for the vast majority of cases. If you need better performance you can pass points and expand them to triangles in a geometry shader.


Read up here on some techniques for VBO optimization with sprite batching:



Since ultimately the performance may vary depending on the driver, the absolute "fastest" solution is to use whatever works best for the driver. For example, in the intro cutscene of your game you might benchmark a few different rendering techniques, and pick whichever runs the fastest.

In Topic: Good books for OpenGL

29 December 2012 - 12:42 PM

I'm writing a tutorial series aimed at beginners wanting to learn the programmable pipeline and GLSL shaders, check it out here: