4

I decided recently write a 3D game in my spare time, as I was tired of my daily "corporate programming". If I expect to be done in 6 months/1 year, which version of OpenGL should I use as baseline? In other words, which version of OpenGL should I require my potential users to have?

I did some OpenGL has a student, but that was in the days of the first edition of the red book. Things have changed a lot since then.

Sebastien Diot
  • 631
  • 5
  • 12
  • Somewhat related: http://gamedev.stackexchange.com/questions/1606/is-learning-opengl-2-1-useless-today – Tetrad Aug 22 '11 at 23:08
  • BTW, I said "mid-range" not because it is graphically complex, but because I'm doing it on the JVM, and I haven't got the experience to find the optimal "graphics design". So it will require more resources then strictly necessary. – Sebastien Diot Aug 23 '11 at 10:46
  • http://store.steampowered.com/hwsurvey This is the steam hardware survey. Its not gospel but it does show general usage patterns of people willing to buy games online :D – James Aug 23 '11 at 23:29
  • Thanks James! Coupled with Christian's DX to OpenGL "mapping", it seems that about 80% have at least DX10, so OpenGL 3. OTOH, my kid's PC is still DX9, so I'll have to buy him a new PC so he can do beta-testing. LOL! – Sebastien Diot Aug 24 '11 at 11:02

2 Answers2

8

First you can always assume GL2, I think, as you won't find much pre-2.0 hardware around. Next, it is mostly a question of the major version, as these are mainly dependent on the hardware, whereas minor versions often are more of a driver question. For example a hardware supporting GL 3.1 is likely to support GL 3.2 (and 3.3), too.

Next, it depends on the features you need. For example these are IMHO the major features of the newer versions (forgive me for forgetting your favourite feature):

OpenGL 3:

  • geometry shaders
  • texture buffers
  • instanced rendering
  • integer textures and attributes
  • integer operations in shaders
  • transform feedback
  • FBOs
  • floating point textures

The first six of these are real hardware features of GL3/DX10 hardware, whereas the last two (important ones, I think) are core since 3.0, but are supported on most newer GL2 hardware by extensions (since GeForce 6, I think)

OpenGL 4:

  • tessellation shaders
  • double precision attributes and shader operations (and textures?)
  • improvements of shader managment
  • image load/store operations

In my opinion GL3 brings some really nice features, but there is nothing that prevents you from writing modern and future ready GL applications (without fixed-function) with only OpenGL 2.0/2.1, that may later be easily improved by new features of newer hardware. But maybe nowadays GL3 might also be a valid requirement, although I still sit on 2.1 hardware. But honestly, it just depends on the hardware features you need and GL 2.0/2.1 might suffice for a solid "baseline". But as you say you last time used the old and deprecated way of OpenGL you might first need to make yourself acquainted with the new and modern shader-only approach, as this is the way to do hardware accelerated real-time graphics today (and tomorrow).

Finally, if you're more familiar with DirectX (and as that seems the one people classify hardware by, nowadays), the relations GL2 ~ DX9, GL3 ~ DX10 and GL4 ~ DX11 may also guide you.

Christian Rau
  • 857
  • 7
  • 11
  • Note that the "improvements of shader management" are also exposed to lower GL versions via extensions. Unless you're talking about shader subroutines, which you should probably never use under any circumstances. – Nicol Bolas Aug 23 '11 at 03:09
  • I don't think I need those OpenGL 4 features. So OpenGL 3.X would also suffice from the feature set point of view. – Sebastien Diot Aug 23 '11 at 10:42
  • @Nicol I actually used it for separate_shaders, subroutines and program_binary together. I didn't know subroutines are evil, as I only have 2.1 experience. – Christian Rau Aug 23 '11 at 11:41
  • @Nicol Could provide some short information about why subroutines are a bad idea? bad design, low performance, buggy implementations? Would be interresting, as I haven't heard about that before (and not worked with them either). – Christian Rau Aug 24 '11 at 13:56
  • @Christian: To be totally fair, it's mostly that subroutines are just really poorly specified in terms of API. Coupled with the fact that ARB_shading_language_include gives you much of the same ability (easy to share code among programs) with less hassle, there just doesn't seem to be much point. Unless you need runtime switching of functionality; that's really the only place where subroutines beat inclusion. – Nicol Bolas Aug 24 '11 at 19:51
5

If I expect to be done in 6 months/1 year, which version of OpenGL should I use as baseline?

None. If you expect to be done in 6 months to a year, unless your game has negligible graphics (SpaceChem, Tetris, etc) directly using OpenGL is going to slow you down. If you want to make a game quickly, then you should be using something higher level than OpenGL. Ogre3D, Irrilicht, etc, there are any number of engines that don't require direct usage of OpenGL.

Taking the time factor out of it, you can think of the populations for each version like this:

2.1: People who have bought a graphics card in the last 8 years. This also covers more recent Intel hardware (though don't expect these to work well without fiddling with it).

3.3: People who have bought a graphics card in the last 5 years. Or an integrated graphics chipset (from AMD) in the last 5 years.

4.2: People who have bought a graphics card in the last 2 years. This also covers more recent AMD integrated chipsets, as well as on-die CPUs that AMD is starting to make.

Nicol Bolas
  • 26,068
  • 3
  • 76
  • 104
  • I mostly want to draw textured cubes, but lots of them; nothing too complex. Bet you can guess what I'm up to... Anyway, 5 years sound like a reasonable requirement, OpenGL 3.X then. – Sebastien Diot Aug 23 '11 at 10:40
  • @Sebastien When drawing many textured cubes (something Minecraft-like, eh?), feautures like instanced rendering, texture arrays (forgot to mention those) and maybe the geometry shader come quite handy, especially instanced rendering (maybe together with transform feedback for culling). So I think GL 3 would really be a reasonable choice. – Christian Rau Aug 23 '11 at 11:46
  • @Sebastien And for a Minecraft-like game, developing you own small specialized graphics engine might really pay, performance-wise, as long as you make good use of the above mentioned features and don't just draw glBegin/glEnd cubes. – Christian Rau Aug 23 '11 at 11:51
  • That's precisely what I had in mind. I'm aiming for a flexible engine rather than a specific game. And I'm working bottom up; first the servers, then the network, then the client, and then fast graphics. – Sebastien Diot Aug 23 '11 at 16:54
  • Any progress, @SebastienDiot (just curious)? Just to clarify, what did @Cristian Rau meant by "glBegin/glEnd cubes"? – Artfaith May 14 '22 at 04:35
  • 1
    @Faither I've long since moved away for "drawing my graphics myself". Playing with Unreal Engine these days. – Sebastien Diot May 17 '22 at 17:38