InsideQC Forums

After months of work, it's ready. Here's a link:

https://www.dropbox.com/s/7e5ved7dc0f5m0v/rrp.zip?dl=0

It's a SP pack featuring five maps (three are massive BSP2 monstrosities) by myself, MFX and Hrimfaxi.

Its based of Rubicon2 and features a grab bag of new features and enemies.

We'll be putting together a devkit over the next few days including the various source files and some documentation for those that want to pick it apart.

Keep on Quakin'

I S T H I S N E C C E S S A R Y ?

Hi, long time no see!

A N D Y E S I T I S

D I R E C T D O W N L O A D L I N K IN CASE YOU PREFER THEM LIKE ME
https://www.quaddicted.com/filebase/rrp.zip


Be aware that you must use a specific Quakespasm release for now: http://celephais.net/board/view_thread. ... 8&end=1108

So this is yet another incompatible bsp2 implementation? Or a new format? Or is darkplaces bsp2 broken?

The format is the standardised one I guess/hope but they used some QS specific features like fence textures (textures with transparent parts) that will look horrific if not supported.

Yeah these are the "final" BSP2 format (not the legacy 2PSB one).

Besides being huge, they do use fence textures (with { prefix) on both world and brush models. Normally you wouldn't want to use fence textures on world polys but they're used here for lots of free-floating walkways in telefragged.bsp. The original implementation in RMQEngine only supported them on brush models, iirc. But Fitz Mark V supports them on world polys, which is where I ripped the code from for Quakespasm. I forget but I think FTEQW supports them on world polys too.

Aside from that there's nothing weird or quakespasm-specific in here

its not really recommended to (ab)use fence textures on world polies because doing so requires the qbsp+vis to be properly aware of them, even if the engine renders them properly. submodels don't affect pvs. woo.

Well, the fence textures look good. Guess gl_nearest is being stuff-cmd for that. I noticed transparent glass on sliding doors in the start map.

All brushes fence-textured are func_wall, at least they should be.. No vis culling.
As for the trnsparent glass doors, these are actually 2 doors, one with a alpha value set and synchronized lip and speed.

Well, it seems I lost a revision since some of the world fenced polys do cause minor HOMs in a couple of places.

These are ones that I fixed, but they crept back in somehow.

The reason not to make them func_wall was the flickering entity bug, which also affects a few brushmodels still - like the causeway in the large atrium when coming from the outdoor train area.

ijed wrote:The reason not to make them func_wall was the flickering entity bug, which also affects a few brushmodels still - like the causeway in the large atrium when coming from the outdoor train area.

That's a shame. I take it this is related to the bump in MAX_ENTS_LEAFS in Quakespasm trying to solve the issue.

Baker, yeah, I doubled MAX_ENT_LEAFS in Quakespasm to help with that and other cases as well: an elevator in fort_driant-fullvis.bsp, and a grate (func_door) in jam1_ionous.bsp. There's still a rotating decoration in RRP's start.bsp - the blue pipe thing on the second floor - that is visible from something obscene like 20k leafs, so MAX_ENT_LEAFS=32 isn't much help, and IIRC you can still make it disappear if you look at it from the right spot.

Found the comprehensive discussion here: http://forums.inside3d.com/viewtopic.ph ... c&start=23 , and later I might try MH's idea there or compare with what's in the latest RMQEngine, but I didn't want to try making too many higher-risk changes in one QS release.

I understand that DarkPlaces just sends all the brush models irrespective of PVS, although I suspect that's more to do with realtime shadows (an object outside the PVS may cast shadows into the PVS) than this problem.

The code I posted in that link is fine for id1 maps but performance falls off badly as entity counts go up, as it must recalculate the leafs every frame rather than only when each entity moves. It's also totally unsuitable for servers as this must be done per-client too.

My last version of the code (which I don't believe I ever released) allocated the leafs dynamically. That needs some work on your memory subsystem of course. With the stock subsystem you could probably put them in the zone, although you'll hit trouble when you come to free memory when loading a new map. If you had support for multiple zones (or zone tags) you could give them a dedicated zone (call it a "per-map zone") and trash that in Host_ClearMemory.

If you prefer to be conservative about the memory subsystem at least you could move the zone over to something like Quake II's implementation. That all but confirms my suspicion that the Quake memory subsystem was a technical restriction imposed by DOS rather than a deliberate choice for other reasons.

The last option with this kind of entity is to makestatic it in the QC. Only valid if it doesn't need collision, of course (although you could combine makestatic with clip brushes in the world).

mh wrote:(although you could combine makestatic with clip brushes in the world).

That is an interesting idea for a non-moving entity.

Pushes the responsibility on to client and probably efrags. Client efrags are more trustworthy?