QuakeForge 0.5.99 Beta 4.1 Released

[taniwha]

I expect this to be the final beta before releasing 0.6. The only actual problems (known) remaining are rendering on MH's old dell and sdl sound on OpenBSD.

Details
Download
Documentation
Command and Cvar docs

[Baker]

NQ server now works on multi-homed hosts.

Ah, what does that mean?

Btw ... I tried QuakeForge maybe back in 2002. It is kind of neat to see it being revived (some Linuxy guy who at the time could kick my butt used QuakeForge for NQ and never stopped talking about it convinced me to try it back then, but some of the changelog stuff doesn't immediately click in my head (Blender export script tool? Yah, I knows what Blender is ... but my imagination is limited on what this is for ....).

But it sure is nice to see some different engine modification ideas in the pool. Different angles are important.

[What doesn't work about MH's Dell + Intel? I ask because ... well ... MH and I have explored Intel GMA adapters to death and usually running on Intel is just eliminating the Draw_Disc deal on Intel hardware because older Intels do not support back buffer/front buffery stuffs. 'Tis usually that simple ... FritzQuake 0.85 runs on Intels where FritzQuake 0.80 didn't with just that switch (I pushed and pushed for that change, heh)]

[mh]

One other problem (functional, as opposed to performance related, of which there are many) I found on Intel is relating to Vertex Attrib Arrays (glEnableVertexAttribArray, glVertexAttribPointer and friends, which I use in RMQ) - they need a glPushAttrib (0) before each draw call, followed by glPopAttrib () after each. I doubt if this has bearing on the current issue though, although the end results are somewhat similar - nothing being drawn (or something being drawn but texcoords getting all messed up). Haven't had a chance to test this beta yet (the only Intel I have regular access to these days is in work) but I'm thinking that a GL Intercept run should throw up the root cause. If I find it I'll reveal all, of course, but to be honest I'm not certain if it's a vitally important thing to fix for this engine.

[Spike]

vertex attributes can alias to built-in attributes up to and including disabling/enabling builtin attributes when the custom attribute with that slot number is disabled/enabled, and vice versa. ATI does the same, but only with VertexPointer/attrib 0. Either way I gather quakeforge does not, as yet, use shaders.

[leileilol]

My favorite part of Quakeforge is the software renderers
could use some colored lighting in em methinks

[mh]

vertex attributes can alias to built-in attributes up to and including disabling/enabling builtin attributes when the custom attribute with that slot number is disabled/enabled, and vice versa. ATI does the same, but only with VertexPointer/attrib 0. Either way I gather quakeforge does not, as yet, use shaders.

You should be able to use vertex attribs without shaders so long as you match them correctly (0 for position, 3 for colour, 8 for texcoord0, etc) - and presumably also adhere to the same formats and normalization as was used for the legacy gl*Pointer calls too, but yeah, I guess it's irrelevant for QF (one reason why I suspect you might want to do this - probably the only valid reason - is to avoid the horror that is glClientActiveTexture; why the ARB never made a glMultiTexCoordPointer I'll never know). It is another Intel bug to add to the list though, but that's a topic for another thread.

[taniwha]

I think that for this release, I won't worry overly much about Windows issues in general: we haven't had a dedicated windows developer since 0.3 was released . I think it's much more important I get an official release out, and then worry about "fringe"* operating systems.

* From my perspective (due to lack of sane access), Windows is a fringe OS . However, I have absolutely no intention of abandoning Windows, or any other OS on which people actually want to use QF.

MH: I'm looking forward to the results of your intercept run(s). However, your information about PushAttribute is interesting: not one call of it in QF's source, but with the console down, things work. I wonder if the same goes for PushMatrix/PopMatrix.

leileilol: If it's the look of the SW renderer that you like (rather than just it being SW), you might be interested to know that when I get glsl going in QF, I want to make it look like the SW renderer with (optional) extras (colored lights, transparency, fog). Otherwise, just enjoy the SW renderers. They will always continue to track non-rendering related changes in QF (model/texture formats probably fall under "rendering related"). The SW renderers are there for the purists (and my testing when Linux's GL drivers break ).

[edit]P.S. On to releasing 0.6 in time for our anniversary. And then on to glsl, server merge, client merge, CSQC, QuakePascal... (not necessarily in any particular order)