Can you post one of these demos anywhere? 

The demo is of gb testing my map. I can email you the map if you like :) 

I probably used an earlier build to record them. A matter of figuring out the revision and building that I guess. 

four exes and none play it, so bleh here yer go :P

Map:
http://www.zealousquakefan.com/junk/zqfarrival_test.zip

Demos:
http://www.quaketastic.com/upload/files/demos/gbzqfdemos.zip

If you've got a build dated feb 16th that might help. I've tried dec 23rd, jan 25th, feb 1st and feb 21st :E 

Oh yeah requires Quoth. I always forget to mention that guh :p 

I have an idea about the grapple. Maybe it could be used to pull certain power ups towards you? 

With pushable objects, and currently attaches you to monsters.

The behaviour against monsters isn't very clear just yet - it does no damage and they're always assumed to be heavier since most of them are.

Powerups would be weird since they're mystical things. Maybe for ammo or health though, that makes sense. 

To see if mh took a look at those demos :E 

cvar scr_crosshairscale is broken

also for some reason it crashes trying to load rubicon2 maps 

I think, metslime's 2nd one. Not sure why. 

The engine isn't intended as a general purpose Quake engine. It's purpose is to run RMQ content and to act as a sample implementation of engine changes needed for RMQ content. The longer term intention is that the RMQ engine will become obsolete.

With that in mind, issues relating to general purpose usage of the engine (especially with other maps and mods) are quite low priority, and the recommended solution is normally going to be something like "use another engine".

All the same though, I'll check it out and see why it's crashing as it may be relevant for RMQ. 

I just tend to use it to play everything to get the decent FPS.

Fastvis is now good enough - even not vising doesn't take that much of a hit performance wise. 

i struggle to use anything else now. it's essentially quakespasm with coloured dynamic lights, contrast slider, better performance and higher limits. just the contrast alone made it hard switching back to QS for rubicon2 (it was metl's first map that crashed for me)

another map crashed it the other day too, forgot what it was though. 

Something to do with particles, apparently. I'm looking at the diff and I don't understand it, though... 

Careful with this - I know most people these days have multicore cpus and geforce 8 bajillions, but crucially, not everybody does. Quake's beauty is that it still runs well on "that old POS collecting dust in the closet." 

Well the key point here is that high-end hardware is not actually a requirement. The renderer has been completely restructured to allow for more efficient geometry processing (look up GPU batching on Google sometime). In fact in some cases fast vis may even be faster than full vis as the BSP tree can be simpler (traversing it can be a huge CPU bottleneck).

This can be a bit counter-intuitive because you have to throw out everything you know about how the Quake engine works and what it's good or bad at. wpoly counts become more or less irrelevant, wide open and complex scenes are no longer a problem, heavy dynamic lighting comes almost free of charge, and so on. 

I run my maps on a non-gaming laptop that overheats pretty quickly with even fitzquake due to the C/GPU usage.

Most of the original Quake architecture is based on you having a crappy PC, or is just completely outdated in terms of software (as Mh says).

Its why a monster pc that doesn't have any problems with, say, Crysis, has problems with some of the bigger Q1 custom maps even though you're looking at a fraction of the poly counts, texture quantities and texture sizes. 

It doesn't matter if you have a good or bad system to run the engine on - it'll still be incredibly slick. 

Gotta also remember that Quake's original software design was based around a software renderer running on an MS_DOS machine with a p60 and 8 MB of RAM. That was then crudely ported to run on $25,000 OpenGL workstation cards, and then crudely ported again to run on first generation 3DFX cards through a Glide wrapper.

So a lot of the design decisions made back then either don't work well (immediate mode), don't work at all (gl_ztrick) or are just plain dangerous (writing to the front buffer) on more modern GPUs (and by that I mean any consumer-level hardware from about 1999 or so that has a full native OpenGL driver). 

I would argue though that not fullvising a map is very unprofessional. 

 

and watch how many polygons are rendered on a flat surface for no reason at all except that the map compilers were meant for DOSQuake and WinQuake and cut up surfaces into a billion pieces. 

and cut up surfaces into a billion pieces.

i've been wondering if it's possible to make this any better... you spend ages doing your trisouping and then qbsp doesn't seem to actually care and cuts it up worse than if you had just carved everything out of a cube. :( 

That nowadays you should be able to bypass bsp altogether. Put all level geometry into VBOs and render those in one go. Just look at the triangle throughput that modern GFX cards have. It's so high that you can easily just render your entire Quake map and still be fast. And if that doesn't work, you could implement some simple culling, but you wouldn't need a BSP anymore I think. 

You still need the BSP tree for stuff other than rendering. The server uses it for clipping, movement, tracelines, positioning entities in the world, and so on. Really though only nodes and leafs (and clipnodes) are needed for that, and the surfaces can be easily omitted.

I believe that Half Life 2 stores the original map brushes in it's BSP and uses those for rendering, so it can avoid all of the ultra-heavy tesselation that QBSP does. This would be a great feature for any hypothetical extended BSP format.