FitzQuake Mark V - Easy to compile and ...

[Baker]

[revelator]

Ah i might have a look at spikes version then thanks for the explanation.
I do have a few things i want to try and push onto this engine like the tenebrae particle system, and mh's allmost lossless bumpmapping.
I do have a feeling it would look nice in the end hehe. The particle lexer is pretty nice but not many people have experience working with flex scripts which is a bit sad as it works quite nice and the code is pretty close to the old particle code.

[Baker]

[revelator]

[Baker]

[mh]

[revelator]

its bit newer than that it was something we brainstormed back when my avatar name was reckless, it was shortly before you started work on directq and scrapped it. It uses a different take on standard normal mapping making it insanely fast, i cant remember if i was the one who got the idea but you wrote the code for it

[revelator]

https://sourceforge.net/projects/cbadva ... les/Tools/ grab the realm.zpaq file.

mhquake with pk3 support and arb water shaders.

Somewhere along the line i broke something so it crashes atleast on amd gfx cards, if you spot the bug let me know it has been driving me crazy since msvc seems to be unable to read the expression where it crashes.

[Baker]

[revelator]

peazip maybe ? i used that to create it and i can open it.

[revelator]

packed it as a normal zip file, same link. Hope that works better else i start to worry

[revelator]

Found a rather old version of realm on one of my harddrives that does not crash, but its ungodly slow on my R9 390 amd card strangely enough it runs ligthing fast on my old nvidia 560 gtx grrrr. Started moving over stuff from the newer version slowly so i can catch the code that makes it crash in the later version.

The version i uploaded uses shaders for water / slime / lava and / heathaze surfs, and initially i suspected the shader code to cause the crash but i just reimplemented it and it runs (well not fine since its slower than tenebrae on a geforce 1).

the debugger also seems to think that the bug is in the surface drawing code, render list seems to have a bad pointer somewhere but i had no luck finding it yet.

[revelator]

Found the culprit !!!! damn this was a bitch to hunt down GL_EXT_compiled_vertex_array do NOT use on newer cards it will slow them to a crawl,
on older cards it actually speeds them up Oo but it will totally fuck you over if enabled on newer gfx cards, we talk single frames here.

After removing the above it runs like a charm. It also caused some rather weird texture glitches when enabled, mostly on liquids.

[Spike]

tbh, GL_EXT_compiled_vertex_array is too poorly defined to be used by anything but quake3. everyone else should use VBOs.

[mh]

I believe that compiled vertex arrays existed purely as an optimization for software T&L cards doing multipass rendering.

The idea is that by locking the arrays you tell your driver that you're not going to be modifying them until you unlock; at that point the driver can run vertex transforms, optimize them (whatever that means), and transfer them to GPU memory (if it determines there is an advantage to doing so, which would be very implementation-dependent behaviour). From there you can run your multiple passes, and the key thing is that no matter how many passes you run, the vertex arrays are only transformed and otherwise processed once.

The CVA spec also contains a statement that "If the vertex array data is locked while the DrawElements commands are executed, then OpenGL may be able to transform each of these shared vertexes just once" - however, this is behaviour that you don't actually need CVA for any more. In fact it's just the , which happens automatically anyway.

That's a danger in relying on 1998 specs and other documents when it comes to OpenGL.