This thread is supposed to be a spin-off of Korval’s so as to not drift the topic.
There was discussion on migration for programmers and difficulties for people who are new to OpenGL. I think this could be easily resolved by providing the right documentation and other resources on OpenGL.org. My concern is more with end-users.
Probably most people here make games or apps for dedicated hardware or specialists. We on the other hand do a lot of stuff for end-users that are not gamers and these tend to have the drivers that shipped with their fairly old systems.
With OGL 1.1+ it is possible to design an app using extensions and having fall-backs so that it is compatible all the way back to a software win95b ogl implementation. I really like the idea of OGL 3 but such a radical change in the API means anyone not having recent enough drivers won’t be able to run ogl 3 applications at all.
Am I the only one concerned with this issue? Is no one considering strategies to lessen the problem?
I think the moment OpenGL 3.0 tries to additionally be backwards-compatible, we can forget the whole thing. Then we could just stick to GL 1.1 + Extensions.
Wait a minute. Isn’t the proposed OpenGL 3.0 an addition to – as opposed to a replacement for – OpenGL 2.0? Can’t the two exist side by side, or is it an either/or proposition?
But you have the same problem when you want to use features of OpenGL 2.0 (or any other version above 1.1). You always either have to code a fallback in your code, or force the user to upgrade the driver.
In the case of a radically changed API, it’s just a bit harder to write a fallback implementation.
In any case, it boils down to three alternative:
don’t use the new stuff
force people to update
write two code paths
I see no difference to the current situation with OpenGL versions or even with extensions. Take for example GLSL. If I want to use it, I either have to force the user to update the driver (or even the hardware), or I have to write a fallback path.
force people to upgrade, yes, but when it’s possible to them… For example, I won’t buy a Geforce 6 just because I don’t have vertex shaders texture units (or so) available on my FX
I really guess that we really have time to think about it. I only have GL 2 since few months, not more. And I gradually move up to 2.0 for my programs, but would like to stay at least 1.5 backward compatible (so almost gl.2 )
The GL-future proposal includes backward compatibility, which may be layered on the lean-and-mean core. The only issue with running on older hardware is ensuring you don’t use new APIs which are unavailable on older cards.
One possible solution for developers who wish to support older cards is to provide a development environment which exposes only the older APIs. I wouldn’t want to build this into the driver; rather, it could be provided as a shim like GLee or GLEW.
Originally posted by Jan: I think the moment OpenGL 3.0 tries to additionally be backwards-compatible, we can forget the whole thing. Then we could just stick to GL 1.1 + Extensions.
Oh no, I’m suggesting no such thing. I guess it was unclear but what I would perhaps like to see is something in place that might encourage end-users to keep their drivers up-to-date so that the problem is at least more limited. The sooner it is done the better. Then again, it might be. I’ve heard of an update manager for ATI drivers. There’s also and installshield(?) update manager, does that or could that encourage graphics driver updates?
Originally posted by Overmind:
[b] In the case of a radically changed API, it’s just a bit harder to write a fallback implementation.
In any case, it boils down to three alternative:
don’t use the new stuff
force people to update
write two code paths
[/b]
Well, 1 doesn’t exactly seem like a solution and 2 isn’t always an option (our clients wouldn’t accept it). I’ve actually already opted for 3 as it’s obviously the only real solution but I would like to in some not-too-distant day drop support for ogl 1.1 by expecting sufficient users to be ogl 3 ready (perhaps to justify forcing the others to upgrade).
Maintaing two drastically different implementations is not nice and will also impact the size of binaries which for us is actually also a concern.
May i ask what kind of software you are developing that demands
usage of high-end hardware if available
compatibility even with very old hardware and software (OS)
small BINARY size (how should it be possible to make use of high-end stuff, if you are already memory-limited??? I mean, you do use textures, don’t you?)
and also compatibility to old drivers, if the customer is too lazy to upgrade
Sorry, i don’t want to offend, but your customers must be a pain in the butt.
Well, we do a lot of different stuff with different requirements but one thing we get commissions for is architectural reconstructions of small environments or parts of environments. The context being cultural heritage and the delivery being browser integrated, you can expect a lot of end-users who barely know how to use their computer.
Using high-end hardware is never a bad thing. Regardless of what you are doing you can always use some good visual effects. Our clients like stunning graphics but also require that there are no special HW requirements, hence advanced stuff has fall-backs or is dropped in the case of poor hardware support.
Perhaps you’d be surprised how well textures and geometry can be compressed, parametrised and at least partially generated. You can fit some very detailed scenes in very little space and the binaries represent a constant overhead. When you put a lot of effort into compression it is naturally also a concern. Obviously, the concern here is distribution size (think browser integration, yes our end users are likely using dial-up) and not memory usage.
I don’t think we actually expect our users to be running win95 but it sounds good to our clients that they could be.
My customers often are a pain in the butt :). In more ways than are evident here.
)