Code for legacy openGL but still compatible with new openGL

Started by
17 comments, last by 21st Century Moose 8 years, 6 months ago

I thought your goal was to have your program run on an older system, not that you want to have someone using an outdated tutorial to more easily modify it?

Using the glBegin style is a bad idea and completely incompatible with modern OpenGL. OpenGL 1.1 (which is the ancient version supported by the MS software renderer) already included support for client side Vertex Arrays, so you have no need for inefficient code doing 2 or 3 function calls per vertex.

Anyone who did not forget to install a graphics driver will have programs run in some better version of OpenGL.

Advertisement

Hodgman means that you would write your own Begin function that sets up some lists or arrays to collect vertexes etc., Vertex functions that add to those, and an End function that actually draws those primitives using modern OpenGL. So it would be your very own implementation of "legacy OpenGL" using modern OpenGL.

I understand now, that could be an approach.

Is the program actually required to run on machines with very old GPU and drivers that only support GL1.x, no shaders etc. or is it just that you want to supply a legacy OpenGL style API for users of the program?

It is the very old GPU / drivers, not the API style it self.

I thought your goal was to have your program run on an older system, not that you want to have someone using an outdated tutorial to more easily modify it?

Using the glBegin style is a bad idea and completely incompatible with modern OpenGL. OpenGL 1.1 (which is the ancient version supported by the MS software renderer) already included support for client side Vertex Arrays, so you have no need for inefficient code doing 2 or 3 function calls per vertex.

Anyone who did not forget to install a graphics driver will have programs run in some better version of OpenGL.

That can be another possibility, using vertex arrays. I will learn about it.

Thanks all.

That clears it up.

You can get quite nice results with assuming a very low version like GL1.1 and checking for extensions, with the downside that the more extensions you use, your code can become quite complex and ugly from the supported / not supported codepaths, and you'll be using functionality which is deprecated from the point of view of newer GL (3.0+) versions, so you may learn bad habits.

The old GPUs (except historically Nvidia) can come with poor GL drivers, so you may encounter bugs where the driver tells you that some extension is supported, then you go ahead and use it, and crash. Though if you mostly just render textured triangles to the backbuffer, maybe using (simple) shaders, there's not much extensions needed and not much that can go wrong.

The Second Life open source client code (LGPL) can be quite illuminating in how they only require a low OpenGL base version and then check for supported features to enable e.g. VBOs (if no VBO support, they use vertex arrays instead) and GLSL shaders. There's also quite some driver bug workarounds in there. Or at least it used to be like that, haven't checked in a few years to see if they rewrote everything to be more modern :)

You should find out exactly which version with which extensions you have available, not just assume the oldest.

You could try the extensions viewer at http://www.realtech-vr.com/glview/ which should show you everything, the OpenGL version and all extensions your computer supports.

Then use the least old version that runs after updating your graphics drivers.

Thanks again for the suggestions, I believe I come with a solution that will work for me.

First to clarify, from a point of view of the old support, I just need that old materials (ambient color, specular color) with triangles(normals, color per vertex) with that simple gouraud shading. So that is something supported since the very beginning of openGL I believe. No extensions are planned. Visuals and speed are not a concern.

With the help of your suggestions I come with the idea to use Vertex Arrays (glDrawArrays or the interleaved ) so it will be the same vertex structure for the two modes, then, I must design some "engine" using OOP that will abstract (and simplify) the use and display of models (material + mesh) and then implement it specific for the two modes.

I must create some abstraction for camera position, load of the models, display (based in some position / scale / transformation) etc..

Let me know if you know about some libraries that implement something similar.

Thanks.

It is the very old GPU / drivers, not the API style it self.

This is something that comes up a couple of times a year.

I'd caution you to be absolutely certain that the hardware you're targetting is still actually in use before imposing this limitation on yourself. Have you researched your target audience or are you working from gut feeling/personal preference here? Because nowadays "very old hardware" can have multiple meanings and they may be surprising.

First of all there's the really really old first-generation consumer-level OpenGL accelerators, dating to 1996/1997, and you almost certainly don't want to target these. These support OpenGL 1.0 with extensions, best case OpenGL 1.1, have limited support for blend modes, may not even support the old lighting models, typically use a minidriver which only implements a subset of OpenGL anyway, and the drivers are just not going to work on any modern (or even 10-year-old) OS.

Secondly there's the first batch of actually good hardware from the likes of NVIDIA or ATI, dating to 1999 or thereabouts. Typically OpenGL 1.3 to 1.5 with a fully-featured driver, but once again having a driver that actually works on an OS that the typical end-user has may be difficult.

Thirdly there's the first generation of shader-capable hardware worth taking seriously, dating from 2004/2005 or so. OpenGL 2.0 but you'll find some weirdness or limitations (for example non-power-of-two textures dropping to software emulation).

The third class of "very old hardware" is the one I'd make a case for being your minimum baseline. It's 10-year-old hardware, you're realistically just not going to encounter anything older in the wild, outside of specialist/enthusiast audiences, so it's perfectly reasonable to say "below this level I will not go".

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

It is the very old GPU / drivers, not the API style it self.

This is something that comes up a couple of times a year.

I'd caution you to be absolutely certain that the hardware you're targetting is still actually in use before imposing this limitation on yourself. Have you researched your target audience or are you working from gut feeling/personal preference here? Because nowadays "very old hardware" can have multiple meanings and they may be surprising.

Hi mhagain,

This evaluation will be for an opensource EDA CAD tool (Kicad) for the 3D visualization mode. That is a type of tool that can be used in schools and universities.

We have a report that in a high school in Italy (Europe), they still have for example 50% 15 year old Pentium IV in their labs.

We have also reports from users that are using the application in machines with cards:
Ati Radeon 9550 128 mb (2004 - 11 yrs old)

Nvidia 5200 128mb (2003 - 12 yrs old)

GeForce 9500GT (2008 - 7 yrs old)

Intel GM945 (2006 - 9 yrs old)

In this cases (special in the schools), we cannot assume that they are running updated drivers or the vendor drivers. So the idea to support the very basic openGL is to provide always some kind of 'safe mode' for this cases.

I guess these are just "interested" people, not actual current users? Its likely they forget about it and never use it.

Have you thought about how long it would take you to complete the program? When its finally done most of these older computers that currently exist will have been thrown away.

If these people then are really interested in your program they have to go to the effort of installing the necessary drivers. You probably don't want to put months of extra work into supporting people too lazy to do that?

we cannot assume that they are running updated drivers or the vendor drivers


In this case, using OpenGL itself is a mistake. OEM drivers, particularly for older Intel GPUs (such as the GM945 you mention), may not even come with OpenGL support at all. I strongly urge you to reconsider at least one of your goals, because right now your objectives are fighting each other and it will all end in tears.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

This topic is closed to new replies.

Advertisement