That’s what’s happening for me. . . I decided to clean up my code and try using ATI’s extension setup code. The result was that some extensions weren’t loaded as the process stopped after ARB_multisample failed to load. For now I’ve dumped that extension to the end of the list, so that all other extensions get loaded.
Anyone else found this happening?
What do you mean “loaded”.
Extensions are there, you detect them, you don’t load them. The failure to detect one extension shouldn’t stop you detecting another.
Sorry, bad wording. I mean made available via wglGetProcAddress or whatever other method you use. The way ATI’s extension setup code works is that once it fails to setup an extension, it stops and doesn’t bother with the rest down the list. That’s not really a problem since I can move the non-working extension down the list or remove it entirely. However, if someone wanted to use that extension and it doesn’t work. . . that’s obviously a problem.
You cannot simply move these down a list to solve the problem because you cannot order extensions in this “most likely to fail” order for all cards. Extensions are for the most part functionally independent, this is very deliberate and you should load as many as you can if you intend to use them.
If that’s what their code does then throw it away or fix it. Do not abort because one function pointer is not found, that’s attrocious. It seems like an all or nothing approach that a vendor might take to ensure a piece of software is running on it’s intended platform but that’s no use for real world software that needs to fall back on less functional paths for other hardware.
[This message has been edited by dorbie (edited 02-21-2003).]
You are taking this thread -way- off topic. I don’t care what you think about ATI’s extension setup code. I am only concerned with trying to confirm as to whether others are unable to get ARB_multisample working with the Radeon 9700 and the Cat3.1 drivers.
You mean GL_ARB_multisample? I assume you mean GetProcAddress fails on glSampleCoverageARB, right?
Yes.
Dude, I’m not a frikin mind reader.
I’m on topic but I can’t divine where you imaging the thread should go without explicit details. I’ve never had such an on topic post called off topic, geeze.
Check the subject header. That’s the topic. Admittedly, my first post strayed, but my reply was talking about the extension. I even dismissed the extension setup code as a problem right away.
Anyways, back on topic. . .
Got an answer for you:
When ATI was working on the extensions, the 8500 as you probably already know doesn’t support multisample, but GL 1.3 does, so it was added in as a software extension but since the 9700 does, the entry point for SampleCoverageARB was SampleCoverage on the older drivers, and apperently they forgot to change it to SampleCoverageARB in the 3.1 cat driver release.
It’s been fixed, but in the meantime you can use glSampleCoverage on GetProcAddress, that should work (it doesn’t return null anyway).
BTW, if I’m wrong about that info, Evan Hart (or any of the other ATI guys) can correct me on it.
Edit:
Well, at least it’s SOMETHING like that… It’s late here. So my brain == no worky 
[This message has been edited by NitroGL (edited 02-21-2003).]
Don’t worry Ostol, I’m kicking myself right now for replying to your post, it won’t happen again.
Ah. . . using glSampleCoverage works. . . Thanks!