R U B I C O N R U M B L E P A C K

Discuss anything not covered by any of the other categories.
ijed
Posts: 64
Joined: Sat Jul 26, 2008 4:26 am
Location: Chile, SA

R U B I C O N R U M B L E P A C K

Post by ijed »

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'
leileilol
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Re: R U B I C O N R U M B L E P A C K

Post by leileilol »

I S T H I S N E C C E S S A R Y ?
i should not be here
ijed
Posts: 64
Joined: Sat Jul 26, 2008 4:26 am
Location: Chile, SA

Re: R U B I C O N R U M B L E P A C K

Post by ijed »

Hi, long time no see!

A N D Y E S I T I S
Spirit
Posts: 1065
Joined: Sat Nov 20, 2004 9:00 pm
Contact:

Re: R U B I C O N R U M B L E P A C K

Post by Spirit »

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
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Re: R U B I C O N R U M B L E P A C K

Post by qbism »

So this is yet another incompatible bsp2 implementation? Or a new format? Or is darkplaces bsp2 broken?
Spirit
Posts: 1065
Joined: Sat Nov 20, 2004 9:00 pm
Contact:

Re: R U B I C O N R U M B L E P A C K

Post by Spirit »

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.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
ericw
Posts: 92
Joined: Sat Jan 18, 2014 2:11 am

Re: R U B I C O N R U M B L E P A C K

Post by ericw »

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 :-)
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: R U B I C O N R U M B L E P A C K

Post by Spike »

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.
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Re: R U B I C O N R U M B L E P A C K

Post by qbism »

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.
mfx
Posts: 1
Joined: Sat Jan 18, 2014 1:14 am

Re: R U B I C O N R U M B L E P A C K

Post by mfx »

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.
ijed
Posts: 64
Joined: Sat Jul 26, 2008 4:26 am
Location: Chile, SA

Re: R U B I C O N R U M B L E P A C K

Post by ijed »

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.
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: R U B I C O N R U M B L E P A C K

Post by Baker »

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.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
ericw
Posts: 92
Joined: Sat Jan 18, 2014 2:11 am

Re: R U B I C O N R U M B L E P A C K

Post by ericw »

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.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: R U B I C O N R U M B L E P A C K

Post by mh »

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).
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: R U B I C O N R U M B L E P A C K

Post by Baker »

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?
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Post Reply