Miscellaneous Questions

[Baker]

1. In the engine, you have "refdef" and in, say, the Quake II source you have "ref_gl" and maybe it is "ref_sw".

What does the "ref" stand for?

2. gl_triplebuffer

Is this actually useful in modern times? In a test, I got higher frames per second with it off.

And if it is actually applicable to modern times, what is it doing? Updating the sbar?

3. Probably more of a QuakeC question, but in the engine cl.intermission = 3 is a cut-scene. Is this used in a mod anywhere, like Hipnotic or Rogue or maybe Zerstorer? I ask because it is in the WinQuake source but not the GL source in screen.c.

(JoeQuake crashes on the final level of Zerstorer which is maybe all "cut-scene". Not that this has anything to do with this -- or maybe it does?)

[revelator]

1: reference i think ?.

2: hmm beats me.

3: not sure.

4: zerstoerer used cutscenes rather heavily, only a few gl engines had that (mhquake for one). other engines would go boom whenever there was a cutscene.

[r00k]

hmm

#2.> what seems like an opengl command at 1st glance basically only deals with rendering the sbar in Quake. I'd assume its a workaround for a flashing hud.

[Spike]

ref... I have no idea.
I always assumed refdef was 'point of reference definition' or something. Well, it fits anyway.
ref_gl stuff is a bastardisation on the theme as they take a refdef_t as a parameter and draw everything from that, from what I remember.

tripplebufer...
OpenGL states that your gl context is double buffered.
However, tripplebuffering means that you don't have to wait in order to redraw the screen.
This means that some GL drivers do not comply with the OpenGL spec and instead are tripplebuffered instead of doublebuffered. GL not supporting this has no way to query it.
Saying that its tripplebuffered makes the hud redraw differently to avoid it flickering.
Basically if your stats change, then it forces an sbar redraw for 2+gl_tripplebuffer frames, which makes sure it takes effect in all 2 or 3 buffers, thus killing the flickering.
So the cvar will make it render slightly slower, but enabling tripplebuffering in your drivers (outside of quake because gl does not let you specify it anywhere) will give you higher fps, regardless of the cvar - you just get flickering if its 0.

[Baker]

Thanks Spike! Valuable technical information on gl_triplebuffer.

So I stumped all 3 of you on the "ref" thing? Hehe. I figured it stood for reference, but Quake's use refdef and the Quake 2 ref_gl vs. ref_sw or what not seems a little confusing.

No one knows about intermission 3, eh?

Well I suppose I'll have to do some looking in Zerstorer source [and the q1 progs] and then maybe check and see why Zerstorer kills JoeQuake GL (at least 0.14 maybe 0.15 ... it's been a while).

The lack of cl.intermission 3 is in gl_screen.c and I'm trying to make my source more like FTEQW where cl_screen.c is (mostly) renderer neutral and splitting out the other stuff. I hate maintaining both gl_screen.c and r_screen.c when I make a change in the 2D.

(@Reckless ... maybe there is no need for your cut-scene detection codes if cl.intermission 3 is actually used?)

[mh]

"ref" is "refresh", obviously.

Software refresh (ref_sw), OpenGL refresh (ref_gl) and refresh definition (refdef).

Also see various comments and other hints in the source:

these are the only functions outside the refresh allowed to touch the vid buffer

cvar_t r_norefresh = {"r_norefresh", "0"};

only the refresh window will be updated unless these variables are flagged

Etc.

You can emulate triplebuffering using FBOs if you really want control over it yourself I guess, but that's probably an incredibly daft way of doing something that the driver will do automatically for you anyway. Just a pity that there isn't a glGet to detect if you're running triple buffered. (Bonus marks for D3D here which gives you control, but - of course - explodes in your face if you try to do anything unsupported).

Ta for the explanation of the gl_triplebuffer cvar; that one always had me stumped.

I'd be willing to bet that the JoeQuake crash is occurring in the sbar code, and if you comment out the call to Sbar_Draw it won't happen. I've seen this before, and I can't remember the exact cause, but there is a pointer being referenced in the sbar code that is invalid during Zerstorer cutscenes. It doesn't happen with the classic sbar, but converting it to a HUD-type display takes it down in flames.