Has this bug been documented?

[bitshifter]

This bug appears in both my sources and in Id's demo release.
Using ref_soft i can get graphical artifacts in a few places.

For example: Goto demo3 and drop into the circular sewage pit.
Position yourself in between the two doors and face the switch
which will be across the walkway.
You should be standing underneath the ceiling light.
Now slowly move your feet and eyes around while looking out the door.
At certain angles a junk polygon will start to fill the doorway!

I have found a few places in each demo where things like this happen.
Right along the intersection of plane/portal areas.

I can post a screenshot if it would help...

So, has anyone heard of this bug?
Do you have a fix for it?

[knightmare]

The fix is to not use ref_soft. Almost nobody wants to do any coding on it, as it's in assembly code. Almost all modified Quake2 engines are OpenGL-only because of this.

[bitshifter]

You can use ASM or C code depending on the id386 flag.
I plan to support both ref_gl and ref_soft in my sources.
I am not using any ASM code in this project for portability.

Edit:
I have turned off texture mapping and found the brush which
the door hinge attaches to is the one causing the problem.
I think before going crazy with the code i will first decompile the
map and see how this part is actually being defined.
The code may be ok, but maybe funny mapping techniques
may lead to such a problem under certain conditions.
I think reversing such a thing for debugging purposes
would not be frowned upon as long as i destroy the map
file after i am done inspecting it.
I'll keep you posted on my results...

[Paril]

So.. why is it you're supporting ref_soft again? I don't think it has anything to do with no one wanting to code on it, it has to do with no one in their right mind wanting to run on software. It's harder on the CPU; let the GPU do the work it was designed to do and use ref_gl.

Also Knighty, it's not entirely in assembly, only portions of it was, and I believe they could be disabled at will (if not I believe AprQ2 Software is entirely in C).

-P

[bitshifter]

< So.. why is it you're supporting ref_soft again?

1) It can be faster than OpenGL.
2) It can do things OpenGL cant.
3) It can look better than OpenGL.
4) Because i like software rendering.

[Paril]

It can be faster if you're not rendering a lot I suppose, but in general, no, it's not. I doubt software mode can maintain 500 fps as well as the GL renderer can. The GPU's job is to delegate math tasks and rendering which the general purpose CPU isn't built towards doing as quickly as the GPU; perhaps if you had a GPU-accelerated software renderer using OpenCL or something, then yeah, maybe I can see this happening. Actually I'd be really interested in seeing that..

As for two, needs more explanation; is that what you're trying to achieve? I've seen people do some really wacky stuff with the software renderer, but it's not like you can't achieve it with pixel shaders.. I mean that's what they were invented for, no?

As for looks, it does have a nostalgic Quake feel to it I suppose, and does make the game feel more grungy, but besides that...

Fair enough, can't go against opinion.

Regardless I would still recommend you base any work off of a more modern engine (AprQ2 is the only one that is still being used heavily today that also supports software mode afaik) so you can get around any existing bugs and all that without reinventing the wheel.

-P