I have a suggestion. First I was wondering how OGL will affect all the present extensions, are they going to be re-implemented? especially the object model is going to change…?
My suggestion is either keep on the legacy API features and advance the shader model + extensions instead of missing around with the object and taking out many of the great functionalities of GL that have been making it a distinction API.
erm, this is a joke right?
Most of the important extensions are already going to be in GL3 in some form or another; what’s being dropped from GL3 is the legacy things which take you off the fast path for rendering.
If you still want them then fine, go and use GL2.x, but don’t expect them in GL3.
The extensions you’ll see shipping with GL 3.0 will probably be things like S3TC texture formats (which will be a standard extension, but shouldn’t be something an implementation is absolutely required to provide) and so forth. Those things that have always remained EXT extensions despite multiple ARB revisions simply because they don’t belong in the base API. Everybody supports them, but you still have to ask.
ok one question and i will sharrup.
i have maya installed. with next coming gl 3 and the new drivers…how can i run maya which i beleive depends on the legacy api calls which gonna disappear from the new drivers? even if i stick with the old drivers, what if i upgrade my card? heh…now do they have to provide 2 versions of the gl drivers? 2 and 3? which is more more work to do…?
how can i run maya which i beleive depends on the legacy api calls which gonna disappear from the new drivers?
You run Maya.
The GL 2.1 API isn’t going to magically disappear once they start shipping drivers with GL 3.0 implementations. Remember: there’s no such thing as an OpenGL driver to begin with; there is simply a graphics driver which installs (among other things) an OpenGL implementation. When 3.0 starts getting support, they will simply install a second implementation.
The APIs are separate anyway; you initialize GL 3.0 with different commands.
What would be nice would be a better way to test for extensions.
Instead of just getting a huge string that has to be searched from end-to-end looking for the extensions we want, why not have a query call in which we pass the name of the extension we want and get back a true/false boolean.
This should be implimented in the driver as a balanced binary-tree search as a simple string search would be slower than doing it yourself.
Alternativly, instead of a simple boolean result we could ask for the name without a suffix and get back a set (bitmask) that indicates if its available as an ARB, EXT or Vendor extension.
Originally posted by Simon Arbon:
Instead of just getting a huge string that has to be searched from end-to-end looking for the extensions we want, why not have a query call in which we pass the name of the extension we want and get back a true/false boolean.
Yep, will be nice to ADD that, but not to replace the current “give me all the extension strings” approach because in case you need to list ALL the extension will be a problem to have only the “test extension name” mechanism.
Also i’m curious… gonna LP replace the current obsolete OpenGL 1.1 Microsoft DLLs using a separate OpenGL3.dll so we could not depend on Microsoft binaries nevermore and to load it manually with LoadLibrary and then call the glGetProcAddres or…??
Originally posted by Simon Arbon:
Instead of just getting a huge string that has to be searched from end-to-end looking for the extensions we want, why not have a query call in which we pass the name of the extension we want and get back a true/false boolean.
This should be implimented in the driver as a balanced binary-tree search as a simple string search would be slower than doing it yourself.
Yea, this is really killing my FPS.
Seriously, there are very few extensions a modern application would need. Most features are core GL 2.1
Also i’m curious… gonna LP replace the current obsolete OpenGL 1.1 Microsoft DLLs using a separate OpenGL3.dll so we could not depend on Microsoft binaries nevermore and to load it manually with LoadLibrary and then call the glGetProcAddres or…??
It was said it’s an opportunity to replace it but I’m sure the ARB hasn’t decided.
Even with a new dll, there would be extensions to load and you end up calling newglGetProcAddress anyway.
The long string of all extensions approach may not be the prettiest solution, but it shouldn’t be a big problem. However, many apps for some stupid reason copy the extension string into a fixed sized buffer, like char str[256], and that’s prone to crashing if you support a lot of extensions, and then drivers are forced to app-detect and cut down the extension string just to keep some apps from crashing.
Anyway, the best approach would probably be some kind of extension enumeration where you get one extension at a time. That would be pretty failsafe and prettier than current approach.
I think the best way would be returning an array of pointers to extension names. This would be expresive and will make search simpler.
@Simon: performance of extension string search is absolutely irrelevant.
@Humus: it’s true, I have to think about games that cannot detect the string “2.0” correctly 
Total incompetence… and thenit’s called “OpenGL cannot run my game”.
Zengar:
performance of extension string search is absolutely irrelevant.
Ah, but if your going to do something and there’s a slow way and a fast way then why NOT do it the fast way.
Some of us like our app’s to initialise and open a window faster than a user can blink.
Granted, a simple string search is still going to be much faster than the several seconds ChoosePixelFormat seems to take, but really the main point i was trying to make is that everybody ends up writing the same routine to transform the extension string into something useful such as a series of flags that control the flow of the program logic.
Clearly the information is not being provided in the format that people need.
You do want a way for people to see a list of available extensions, but a program will normally completely ignore most of them and just needs a flag to say if at can use a particular feature or not.
Originally posted by Simon Arbon:
Ah, but if your going to do something and there’s a slow way and a fast way then why NOT do it the fast way.
Because the slow way has fully sufficient speed and it is easier to implement.
BTW: If you really wish to have the best theoreticall speed. With the string containing all extensions you can use Aho-Corasick algorithm (or something simpler operating on the finite state machine principe) to detect presence of all extensions interesting to your program in single linear walk over the string.
Clearly the information is not being provided in the format that people need.
Each application has a finite list of extensions it is interested in, and this list is not going to change. So it is easy to make a single flag for each interesting extension.
But in general, there is no limit to the extensions an implementation could provide, so it would be quite hard to provide the data in this form directly from the OpenGL API. On the API side it always has to be something string based, because it has to be easily extensible in the future.
I’m sure there are other representations that would be easier to work with from the application side, but in the end every application is going to convert the string based form into some kind of flags. So does it really matter what the source representation is, if there is going to be a conversion at startup anyway?
Originally posted by Zengar:
@Humus: it’s true, I have to think about games that cannot detect the string “2.0” correctlyTotal incompetence… and thenit’s called “OpenGL cannot run my game”.
Yeah, this exact thing happened to a high profile common benchmark game. I found it somewhat amazing that a developer that is clearly able to produce a great game with awesome graphics still somehow failed to parse three bytes of the OpenGL version string.
I’m not sure what’s more amazing, that developers make that mistake in a commercial release, or that IHV’s actually cover their mistake.
Sounds like as good a reason as any for a game patch. Though I can see the readme now…
New in version 1.01:
- Fixed stupidly parsed OpenGL version string.
…
I’ve probably done something like that before, but not publicly, as far as anyone knows 
Komat:
If you really wish to have the best theoreticall speed. With the string containing all extensions you can use Aho-Corasick algorithm (or something simpler operating on the finite state machine principe)
Currently i do a kind of state-machine b-tree search where i read a few character positions of each name out-of-order to reject 99% of the ones i dont want with 1 or 2 compares, then search for the next space and repeat.
Zengar:
I think the best way would be returning an array of pointers to extension names. This would be expresive and will make search simpler.
Yes, a pointer to an array of pointers to each name, this could still use the current huge string for existing apps, but let us jump to the start of each name without all that silly searching for spaces.
Or an array of length bytes would do if the names are consecutive in memory.
Zengar:
@Humus: it’s true, I have to think about games that cannot detect the string “2.0” correctly Total incompetence… and thenit’s called “OpenGL cannot run my game”.
And how many would fail if we ever got to version 10.0, because they expect the decimal point to always be the second character.
Originally posted by modus:
[b] I’m not sure what’s more amazing, that developers make that mistake in a commercial release, or that IHV’s actually cover their mistake.
Sounds like as good a reason as any for a game patch.
[/b]
One problem with the patch is that the chance of developer releasing the patch often rapidly diminishes with each month since game release. So if such breaking change happens several months after the release, the patch is unlikely.
The second problem is than when new driver appears and some badly written application stops working, you are likely to see “hey, the driver is bad, it breaks XYZ game, stupid IHV, do not install it” on gaming sites. Users which play that game will need to stay with the older driver version for possibly long time until the game patch is released (if ever) and they might have problems with newer games with expect that problems from that driver were fixed.
I would recommend to read following blog . It has many articles explaining how far can Microsoft go to cover application mistakes including broken version checking , bad error checking or bad drivers and reasons why they do it.
Yes, a pointer to an array of pointers to each name, this could still use the current huge string for existing apps, but let us jump to the start of each name without all that silly searching for spaces.
If you honestly can’t write a functioning string tokenizer (or just download and use any one of the billions online), I wouldn’t trust you with a C-style array either.
Hehe… yes, komat, I see their predicament, but I really have to laugh just the same.
If you honestly can’t write a functioning string tokenizer (or just download and use any one of the billions online), I wouldn’t trust you with a C-style array either.
I’m just trying to make it easier for people learning OpenGL, especially students that dont have much programming experience.
As for downloading a string tokenizer, some of the ones i have seen are dreadfull, copying the original PCHAR to a local string and then copying each name into an array of strings before doing an m*n string compare, when they should just scan the original PCHAR directly.