qbismSuper8 builds

[Spike]

probably not. Throwing fog into D_DrawZSpans would break fog on models, requiring fog to be calculated there too.
That said, calculating fog with a single depth value is generally unreliable if you have something transparent shown (and thus logically two depth values for a single pixel), so it might be something you want to do anyway. But it likely won't be faster.
That said, doing fog as part of the span might allow interpolating the depth value across the span, instead of recalculating for every pixel. With a planar line of pixels, depth is a little more predictable.

[mh]

I tried doing the z-buffer post-process fog trick in hardware, but it ended up being slower there and the alpha issue existed there too.

String comparisons. Here's a trick for you.

An awful lot of these come from looking up commands and cvars in their respective lists. Vanilla Quake is awful for this. If something needs to set a cvar directly (through Cmd_ExecuteString rather than through Cvar_Set) it first does a linear walk through the entire list of commands, finds that it's not there, then does a linear walk through the entire list of aliases, finds that it's not there, then does a linear walk through the entire list of cvars (and hopefully finds it). If you've added extra cvars or commands yourself it only adds to it.

When you've finished registering all cvars and adding all commands (somewhere at the end of Host_Init is good) build another list of all cvars, commands and aliases. This list should contain a struct, one member is the name, another member is a pointer to the original. Sort that list by name. When a new alias gets created or an existing one is removed destory, rebuild, resort. In Cmd_ExecuteString do a binary search instead. Retrieve the pointer to the original and push that through to the correct handling function.

Cvar_Command does two linear walks through the list - one in Cvar_FindVar and one in Cvar_Set. You can remove the second - even if you don't do the binary search thing - by making a Cvar_SetDirect that takes a pointer to a cvar_t as it's first arg instead of a string. If you do the binary search then both go away. Cvar_SetDirect is also a good replacement for anywhere else in engine code that issues a Cvar_Set.

The list for binary searching is also great to use for autocomplete partial matching, so you get a double win from this.

[mankrip]

[qbism]

[qbism]

New build with the global fog from above, MMX,SSE optimizations, and an added bonus, v_gunkick (0 = off, 1 = normal, 2 = double, etc.)


Framerate independent physics was removed. It caused problems for intentionally low cl_maxfps on fast machines. (Fast in this context is 1.6Ghz dual core) Thanks to physics fixes, should be fine without it. Now set to 72 fps. Probably there was more to be done to complete framerate independence, maybe just shut it down below X fps.

[leileilol]

fyi it fails on pentium mmx with a crash during initialization

[qbism]

[qbism]

[qbism]

Build 85, fixes to the previous build per above:

[gnounc]

http://dl.dropbox.com/u/1776436/quake00.pcx

can see through the map in e1m1 secret area near the megaheatlh in the water.

Dont know if its a known issue.

Let me know if you need more information.

[qbism]

I didn't know about the see-through area, and I wasn't able to duplicate it. Is it visible in that whole general area of the map, or just specific place or direction? Have you noticed this effect on other maps? Could you tell me your computer type/CPU/OS? And if you have the time, a demo file might help. Thanks!

[JasonX]

You guys should check this engine. It has bilinear-filtered software rendering.

[mh]

That's pretty standard when you're crossing a waterline - happens in GLQuake too, it's an old old old content bug.



If you re-vis your maps for translucent water it will go away.

It's possible to sorta-kinda fix it with some jiggery-pokery engine-side (merging visibility for two viewleafs if you detect a contents change between them) but I'm not certain how robust it is.

[Spike]

near clip planes mean you can 'reliably' see both sides of the water line despite being one specific side. The proper solution really is to do some sort of fat pvs with radius equal to the near clip plane.
sadly you'll have the same with certain tracelines/chasecam mods at certain angles/corners, and those involve empty/wall areas.
Many games will clip the viewport to be at least a specific distance from the water plane. This would also be a valid fix. might even work for chasecams too, if you can find a valid empty spot... Either way you're finding all surfaces or leafs or something within a sphere surrounding the viewpoint.
watervis is an alternative, but can potentially be quite expensive in overdraw (on older cards, anyway). it does allow transparent water surfaces too though, so you'd probably want this anyway.

the q2-esque hack where it looks above/below the viewpoint for additional nodes depending on the current water type generally works for regular water, but can fail for the underside/vertical sides of water. in the case of the underside of water, you've a worst-case bug on one frame or so before the player drops right through. in the case of vertical walls of water, generally such water is used only for waterfall type stuff, and always looks wrong anyway. either way, its generally thin (to hide weirdness at the sides) and stuck to another wall so you can't get within the middle of it anyway, so can never see the issue. Also, I don't recall any such vertical water brushes in vanilla content. Just the weird pool on start.bsp
thus the q2-esque hack works just fine for any situations that I can think of.

[mankrip]