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)

Anyone?

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.

Hi there

I, um, have some issues with the information. I don't want to be ungrateful, because I appreciate that you want to help out, but I think it's not quite the way you think it is

As I've said over on Emuxhaven, I have very good reason to believe that grRenderBuffer(GR_TEXTUREBUFFER_EXT) never does anything at all, under no circumstances. I think this is a bug in the original 3dfx drivers, i.e. they intended to implement the extension like you described, but they made a mistake, or didn't have enough time to complete the feature. On second thought, it appears to be the latter.

... because if grRenderBuffer(GR_TEXTUREBUFFER_EXT) does nothing and grTextureBufferExt only sets the dimensions and storage location, there would be no way to activate r2t. But there is. grTextureBufferExt does more than just setting params. It also, simultaneously turns on r2t. And it's the only way to turn it on (or back on, after calling e.g. grRenderBuffer(GR_BUFFER_BACKBUFFER)).

It's pretty obvious that this extension was never finished. As it stands, there is no need to reserve the GR_TEXTUREBUFFER_EXT token, but it exists. That means the 3dfx driver department had some plans to use it but didn't get it done. I'm convinced they would have wanted the feature to be exactly like you described. But as my goal is emulation of original behaviour, I feel that I must implement the extension in this unfinished and broken way.

This makes absolutely no difference to Glide64 compatibility btw.

Any further feedback is appreciated. And obviously feel free to disagree with me. If it turns out I'm wrong, I won't have a problem with that.

In any case, thanks for coming forward with the information in the first place