QuakeForge 0.5.99 Beta 3 Released

[taniwha]

I figured that it was about time I got the next release out the door, so here's 0.5.99 Beta 3.

Details
Download
Documentation
Command and Cvar docs (thanks to iku for pushing me to do it)

The Win64 portability issue mentioned by szo has not yet been fixed.
MH's problem with the world not rendering on an old DELL has not been fixed yet, either.

I was working on getting global fog working properly when not using multi-texturing, but ran into a nasty wall with instanced brush models (ammo boxes etc). I already have a plan for how to get it going, but I didn't want it to hold things up.

MH: I had a look at the gl_conspin code and the main renderer code: it just doesn't make sense that gl_conspin would *fix" things. When I've got fog sorted (hopefully really soon), Ill be able to concentrate on it more.

[mh]

Awesome.

I'm gonna continue beating on that Dell/Intel gfx prob and will let you know of anything I might find.

[taniwha]

Cool, thanks.

I've smashed that wall I ran into: global fog now works beautifully in non-mtex mode. Only problem is I've broken fullbright instance models in mtex mode

Once I've got that sorted, I can look at your rendering issue.

[mh]

Instanced bmodels are a total pain. Easy to see why they were removed from Q2.

[Baker]

Cool, thanks.

I've smashed that wall I ran into: global fog now works beautifully in non-mtex mode.

About a year ago, MH suggested that the idea of supporting non-mtex was unnecessary because no one has graphics cards except ones with a minimum of 2 TMU available.

And if you check out Steam's hardware survey, the number of computers with only 1 TMU is 0.0%. This was from a rather huge sample size and wasn't a biased population set (except that the population set was Steam users), it included crappy older machines and newer machines.

http://store.steampowered.com/hwsurvey

Just providing some infos. I know getting mtex pathways setup properly can be a bit more challenging than non-mtex.

[mh]

Nowadays I don't believe that there's much return on investment in supporting pre-DX9/GL2 hardware, unless you're specifically targetting a platform where you know for a fact that you don't have that capability level (most mobile devices I guess would fall into that category). A lot of code gets simpler and - if you go all the way to shaders - you get to do cool things like fixing water and sky warps properly.

[taniwha]

I agree in principle, but one of QuakeForge's aims is to be as usable as possible on ancient hardware (without holding back things for new hardware, though). We still maintain the software renderer .

That said, I was tempted to just rip out the non-mtex code, but leaving it in actually made for cleaner code in the end. Sure the fog path is a little more complex, and the brush rendering code is still big, but getting non-mtex fog working actually removed a lot of code from QF . The net result is I learned a lot, especially about instanced brush models. I might even give them dynamic lighting now that I can . I think the biggest reason I persisted in getting non-mtex fog working was because it was tried back in 2000 and failed due to nobody then understanding glFog or quake's code: not getting it working felt like leaving an old project unfinished.

However, for shaders and the like: while I will work to avoid breaking existing code, I won't worry about trying to implement stuff on hardware that doesn't support the features.

[edit]Heh, after a good night's sleep, I look at the code for less than 10 seconds and find the mtex-fullbright bug.