I'm assuming that it is legal to call Glide2's grSstQueryHardware before calling grSstWinOpen, because the SDK states it.

But what about Glide3? When is grGetString(GR_EXTENSIONS) expected to return the proper extension string? Right after grGlideInit, or only after grSstWinOpen?

What about grGet()?
(specifically for GR_NUM_TMU, but a general answer would be cool)

I'm asking because my wrapper does not return a proper extension string until grSstWinOpen has been called, and for Gonetz's Glide64 it actually gets away with it. But I'm very unsure whether or not this is correct behaviour, and if it will work with other Glide3 stuff.

If it is correct behaviour to return errors or bogus from queries up to that point, I would very much like to extend this behaviour to all Glide3 queries.

Anyone?

no I'm afraid.not many glide programming guys around here,so unless dborca or koolsmoky drop by,your question will probably stay unanswered..

have you checked out reference docs at falconly site?

The reference docs are a little vague.
The grGetString documentation says nothing on the subject.
The grGet doc actually states that it depends on a valid Glide context, and nothing except for NUM_BOARDS may be successfully queried until grSstWinOpen. That makes my question redundant ...
But ... I don't entirely trust the docs because such rules can always be bent out of shape to accomodate quirky apps. It happens all the time. If an app misbehaves because the driver enforces all API rules, and the app is just wrong, users tend to blame the driver.

The truth would be in the driver code, but that's a complex beast with lots of globals, side effects and dependencies.

I was hoping to get an answer from someone who knows the code inside out. Oh well. Looks like I'll have to try and get the Voodoo 3 running again on XP to probe the Glide driver behaviour. I hope it works smoothly. Last time I was getting just nowhere ...
(nm helping me with that, I now know what the problem was: don't "Extend the desktop" onto the Voodoo 3)

Afaik it isn't "correct behaviour to return errors or bogus". Interesting thing on glide3 programming manual, at first it says there are two exceptions:

QuoteGlide provides several functions to initialize Glide and to detect and configure a 3Dfx Interactive graphics subsystem. Three functions, grGlideInit(), grSstSelect(), and grSstWinOpen(), initialize Glide and the hardware and must be called, in the order listed, before calling any other Glide routines (except the grGet() and grGetString() calls that detect the presence of 3Dfx Interactive graphics subsystems). Failing to do this will cause the system to operate in an undefined (and, most likely, undesirable) state.

but just some lines lower:

QuoteTheir is one exception to the rule stated above that grGlideInit()must be called before all other Glide routines. grGet(GR_NUM_BOARDS,...) may be called before grGlideInit() to determine the presence or absence of a graphics subsystem.

I guess the only ones which know the glide inside out are dborca and koolsmoky, like ps47 just said. Email them, because they rarely drop by.