List of Different Lists and Other Stuff

Discuss programming topics for the various GPL'd game engine sources.
Post Reply
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

List of Different Lists and Other Stuff

Post by Baker »

Initially, I was going to approach engine internal variables from a fixed structure with different parts (video, opengl, console, etc.)

The only problem with this is that it will break modular design. In truth, I might want to take the console or some other piece of an engine and use it in another project that doesn't resemble Quake. I have the shell of the engine largely in one source file, which I've been splitting up a bit (mostly I had to take it apart to see what it does in detail).

Anyway, I've concluded the best way to keep modular design (i.e. console.c doesn't depend much on anything else and likewise the other pieces like video don't depend on anything else ... is to structure, say, the console to use a single structure and then pass that pointer back in the initialization, using that to hook it into the global structure.

Video Shutdown Notes .. OpenGL Vs. MH's Wrapper

Throw all the common OpenGL functions into an array and slightly rename the D3D wrapper functions and likewise throw them into an array. Create qGLfunctions and wire them up as appropriate.

MH's wrapper doesn't always immediately "wakeup", you have to kick it into action if you aren't actually binding a texture.

Video Modes

Width, height, bpp, refresh rates, aspect ratio, color depth, desktop color depth (can't do 32 bpp window if someone is using 16 bpp desktop) ... although bpp switching is a bit overrated these days. MH is dropping 16 bit support, for example. Hard to find a 16 bpp desktop. Going to let dual monitor support live in the command line as a cheaty hack. First, I don't want the headache of trying to figure out how to modify the D3D wrapper to support it. Second, with OpenGL, I don't think very many display setups really support it well.

Key Dest

Key destination in Quake is largely ... [game, menu, console, message] with the oddball state of conforcedup (console forced up because no game is going on). I'm in the headache of trying to figure out when the console being forced up is going to be temporary (in between demos in a multiple demo loop, in the period between maps particular when connected to a server) versus, say, a silent disconnect or QuakeC error. Now much of that is solved with the loading plaque, but also not quite. Plus if you allows demos to play and continue to the next one while the menu is up, it adds a bit of extra weirdness because you can't just simply assume exiting the menu will really take you back to "the game".

V_Renderview

In Quake is setup a bit stupid, at least for OpenGL. For software, it makes sense. But you have a part where it will immediately exit if the console is forced up, but calculate the view blends and then if the client isn't connected, bail. For software, I guess it is important to calculate the view blends when no map is running to reset the blends. For OpenGL, there is no reason to do that, just don't apply them.

A list of things about a map

Map bsp name: dm6
Map title: "The Dark Place"
Skill level: don't use the skill cvar, that could change. Use skill level
Maxplayers, deathmatch, coop, client state (connected, dedicated, etc) and server state (sv.active? Yes = single player or host, no = pure client)
Protocol
Entities count
Monsters (killed + total)
Secrets (killed + total)
Time in the level
Textures used (plus their names), # lightmaps, gamedir, sv_progs, world min/maxes
Models used (usually reliable), sounds used (unrelable?)
Date
Using external ents?

Other ...

Why don't any engine display the common commands when you press F1 (provided the gamedir is id1) and instead make you use the internets for that.

Frikbots

Thinking of the best and least hacky way for an engine to cause a certain number of bots to automatically connect. Maybe setting up a fake timer entity in QuakeC that fires 10 seconds into a game and counts the bots. That is actually a QuakeC solution and my QuakeC sucks, but still that is probably the least silly way. And I guess the least silly way is to use a cvar to tell the QuakeC how many bots are desired.

Gamedir changing

You can't trust cached models or sounds if the gamedir changes. They may not longer be valid. DarkPlaces actually takes that even further and essentially shuts down the engine and reads quake.rc and all that jazz. Which is the "right" way to do it. Except that is putting a lot of faith in mods being designed right and most of them really aren't. Warpspasm for example as I understand it tries to execute the config in id1 in possibly the autoexec.cfg. Sidestepping the issue that there is no standardized mod packaging ... like the foldername doesn't necessarily tell you anything about the mod. Too bad there wasn't a Spirit organizing stuff back n 1997, all that could have been avoided and standardized back then.

Depth Testing

The "keep the view model from poking into the wall" thing is an interesting piece of code. You always want the view model to show in the entirety. Part of me wonders why not clear the depth buffer there, it is the last step of 3D rendering anyways.

Still, I am wondering what the thought behind that code in that part is. It sets gldepthmax to some calculation that I'm not sure always works for all view models and gun placement settings (or maybe it does) that you might add in (gun positioning stuff, like r_viewmodelsize, to add or remove the gun placement hack or even side placement code that doesn't really fit since the projectiles don't come from there.

/Sure an unfocused post with a few different topics

The "keep the view model from poking into the wall" thing is an interesting piece of code. You always want the view model to show in the entirety. Part of me wonders why not clear the depth buffer there, it is the last step of 3D rendering anyways.

Still, I am wondering what the thought behind that code in that part is. It sets gldepthmax to some calculation that I'm not sure always works for all view models and gun placement settings (or maybe it does) that you might add in (gun positioning stuff, like r_viewmodelsize, to add or remove the gun placement hack or even side placement code that doesn't really fit since the projectiles don't come from there.

csqctest

I found myself looking at Spike's CSQC test code again since I was curious about the displaying of Quake .mdl in the HUD and the csqctest puts md3 in the hud from Open Arena.

After you play with the model drawing code a bit and viewports and such, you can pretty much draw models anywhere you want. I'm still not quite sure the "best" way to do this in a 2D setting to get the scaling right.

/Sure an unfocused post with a few different topics
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
goldenboy
Posts: 924
Joined: Fri Sep 05, 2008 11:04 pm
Location: Kiel
Contact:

Post by goldenboy »

One thing, I think an engine should never mess with QC.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Post by mh »

Still, I am wondering what the thought behind that code in that part is. It sets gldepthmax to some calculation that I'm not sure always works for all view models and gun placement settings (or maybe it does) that you might add in (gun positioning stuff, like r_viewmodelsize, to add or remove the gun placement hack or even side placement code that doesn't really fit since the projectiles don't come from there.
The calculation is done because of gl_ztrick where frames alternated between different slices of the depth buffer (one of which used an inverted range); remove gl_ztrick and you just need glDepthRange (0, 0.3) for it. Generally it works because nobody's ever made a viewmodel that breaks it.

An alternative solution is to partition the depth buffer so that ranges of 0 to 0.1 are used for the view model and ranges 0.1 to 1 used for everything else. You'll drop off some depth buffer precision this way, but it's not that big a deal anyway - on modern hardware (or anything from the last 10 years even) you've typically got 24 bits total, whereas GLQuake with the default gl_ztrick 1 used 16, 12 or 8. That will make sure that no viewmodel will ever break the depthrange though.

Clearing the depth buffer again before drawing the viewmodel will be 100% guaranteed working but will also slow things down a bit. This tradeoff is probably best left up to individual engine coders.

If you're using a vertex shader you can apply the depthrange hack after transforming the input vertex by MVP; just multiply output.z by 0.3 and it also works (and is probably going to be faster than any other method). This is what I use in DirectQ, although I use 0.15 instead because I'm a mite paranoid about mods potentially breaking the default range.

I've got a note in my own code to find out how software Quake did this but I've never gotten round to checking. It's more out of interest than anything else because software Quake had direct access to it's depth buffer data, so what applies there is likely irrelevant for hardware acceleration.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Post by Baker »

mh wrote:gl_ztrick where frames alternated between different slices of the depth buffer (one of which used an inverted range); remove gl_ztrick
What does gl_ztrick really do, btw? Make it so the status bar doesn't have to be redrawn every frame unless it changes? Maybe Carmack prefered that method as an option because software Quake only updates the status bar if it changes [amongst other things that software Quake only conditionally updated on-screen]?
and you just need glDepthRange (0, 0.3) for it. Generally it works because nobody's ever made a viewmodel that breaks it.
Is there a special significance to 0.3? (The rest of your explanation helps explain why the formula was more complex than that).
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Post by Baker »

More stuff about maps ... skybox name, fog parameters, sound track number (bsp format).
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Post by mh »

gl_ztrick was just a nasty hack to avoid clearing the depth buffer each frame. It splits the depth buffer in two, using a range of 0 to 0.5 then 1 to 0.5 on alternate frames. When using 0 to 0.5 anything with a lower Z than what's currently in the buffer is accepted, when using 1 to 0.5 anything with a higher Z than what's currently in the buffer is accepted.

On old 3DFX cards GLQuake was heavily fill-rate limited (this was one reason why many of it's other performance problems didn't manifest until later; another may have been specific optimizations in the minidriver, but that's another story for another day). Anything to save on fillrate was highly valuable, so this was important. Another important trick was not redrawing the status bar if it didn't change; also a bad idea on modern hardware.

Essential reading: http://tomsdxfaq.blogspot.com/2005_12_0 ... 8072706409

(There's also lots of other useful and/or important stuff on that site so be sure to bookmark it!)

(And remember that "modern" in this context is anything less that 10 or so years old.)

(Not clearing the color buffer is still useful performance-wise by the way and you don't need to clear it anyway as you'll just be overwriting the full thing all the time.)
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Post by Spike »

using each frame to 'clear' the depth buffer by inverting the direction of the depth buffer. halves the effective precision.
by inverting the depth range, the previous frame will have left data which, while originally considered near, will be considered further than the max depth distance, thus will not block depth despite not being cleared.
you need to fiddle with the depth range and the depth testing for it to work.

more recent gpus have faster depth clears, and have better performance when you don't invert the depth range, anything that supports gl2 properly will favour ztrick disabled. if you're using rtlights or anything fancy like that, you probably want it disabled for code simplicity
Post Reply