BSP2

[Baker]

How do I do the minimum to implement it?

I've seriously considered porting all the RMQ BSP2 tools except the file format modifications to the old BSP tools. Then I decided against that, forking things is stupid.

I've done several Googles and I'm not able to find information I'm sure I used to know how to find.

[Spike]

minimum:
go through all the dfoo_t structs in bspfile.h
change all the shorts to ints.
change BSPVERSION to something like *(int*)"BSP2"

disclaimer:
the minimum will break all compatibility with everything else and won't actually support higher limits due to truncation.

not-so-bare-minimum:
go through all your mfoo_t structs too (matching the dfoo_t ones) and change the shorts to ints there too.
go through your gl_model.c file or whatever and change all the LittleShorts to LittleLongs.
Notice that any possible bigmap-hack things checking for invalid <0 values and switching them to unsigned or whatever are now somewhat redundant - those checks should be changed to 32bit versions or just stripped (especially if they are in recursiveworldnode or somewhere - 32bit memory structures removes the need for weird checks).

disclaimer:
still breaks compatibility with the vanilla bsp29 format.

more-sane-implementation:
dupe all the dfoo_t structs to be dlfoo_t and fsfoo_t. in the dlfoo_t version, change the shorts to ints.
for each function in gl_model.c that now fails to compile, have two versions of each function (an if statement in the right places like fte, or just a copy of each function) and have each use a different d?foo_t struct, along with the matching LittleFoo function calls.
Call the set of functions that match the format, based on value in the 'version' field in the header.
In FTE, I went for if statements in the load functions, as its a bit more maintainable that way, and I'm the sort of person where that actually matters.
You still need to fix up the mfoo_t structs too.
So the renderer is always fed the same structs, just with a few ints instead of shorts.

disclaimer:
DP's version of bsp2 is different (supposedly better). the differences are subtle.
the dleaf_t and dnode_t structs in the original RMQ version still have shorts for their minmax sizes. This is an oversight tbh, and the DP version has ints there instead.
Additionally, the original rmq version's version tag is actually "2PSB" instead of the more sane "BSP2" of DP.
Supposedly, RMQ is supposed to be switching over to the DP version some time, though I'm not aware that they've done so yet. I'll get FTE to support the newer (dp) version when they do so. Both variants can be directly supported, but better to force a single version upon everyone.


To clarify, the format itself is identical. The only difference is the fact that the shorts were changed to ints, and the header naturally got a new version number.

[Spirit]

http://svn.icculus.org/remakequake/engi ... iew=markup

[r00k]

[Spike]

'need', no.
bsp2 allows for _more detailed_ maps. not just maps with extremities more distant than the regular protocol can deal with.

if you don't have support for maps larger than 4096qu in any direction, then you'll find a large portion of bsp2 maps doing weird things. but not all of them.
take urre's old 'mygodthemapisthesizeoftheplanet' map. that was bsp29 (although admittedly does need the engine to ignore the node sizes, but thats the same limit as the preliminary version of bsp2 at +/- 32k).
more detailed maps often imply larger maps, however, so it helps, yet still not always required.

there's also the problem of people using the bsp2 tools because they're too lazy to switch between bsp2 and bsp29 tools as they need. in which case the map itself could be just a small simple box and you'd be unable to load it without bsp2 support.


support for protocol 666 helps. but note that you don't have to have the server using it all the time. fte generally uses vanilla protocols by default too.
you can enable it on a per-map basis if you wish to do so.

[mh]

I'd generally recommend porting big map support from something like FitzQuake first. Big map support is not needed (BSP2 invalidates the need for it) but it does give something of a baseline to work from, and will make things easier than having to go back and retrospectively add big map support after the fact (say you want to be able to run WarpSpasm). It also means that the world.c stuff can be common to both versions (watch out for clipnodes - it's not immediately obvious that they can cause trouble, but they need to be expanded to an mclipnode_t struct containing ints instead of shorts even for standard big map support) (Bengt Jardrup's engine has some hacks that avoid this need, but they're quite evil, nowhere near as clean).

I toyed with the idea of expanding leaf and node min/max to int or float, but decided to leave it at short and recalculate them from the contained surface data in the engine instead (I think the Fitz baseline code already does this anyway). Either way it's not that big a deal.

Not sure how the "2PSB" version snuck in - I blame a late-night coding session for that one. In one way it's good that it's there as it provides a clear differentiator between the original version and LordHavoc's tidied up version. Code to support both versions should therefore be utterly minimal, although Spike is right about forcing a single version.

For DirectQ's implementation I just templated most of the loading functions which worked quite well. Not an option for C of course, but yayyy C++.

[Spike]

mmm, forgot about the using-dclipnode_t thing. sorry.

mh, your brain is just big-endian.

[Baker]

[taniwha]

So, the only real difference between BSP and BSP2 is short->int? Easy enough (especially following the above tips).

[mh]

Yeah, that's it. It was deliberately designed to be minimally invasive like that. Sure, it could have picked up other features (including RGB lightmaps was one obvious example) but that would create an additional dependency on engines needing to support those features - I know, for example, that ProQuake doesn't support (or at least didn't at the time) coloured light, and software engines would have also had some trouble.

So from a technical/idealistic perspective it could be much improved, for sure, but from a practical perspective a new format that's easy to universally pick up stands a better chance of becoming something of a standard, and not forking off into a billion different variants.

[goldenboy]

In retrospect, BSP2 probably aimed too low - like most compromises.

But then again, that's why compromises work in the first place. BSP2 works.

[taniwha]

Seems reasonable. Sure, compromising winds up aiming low, but it does solve the most pressing issues (especially with many engines doing external textures).

One extension I'd like to see is map specific qc code. Maybe separate client (visual effects) and server (physics etc) blocks.

[mh]

Server-side physics in QC sucks. One of the major bottlenecks in RMQ (which is hugely disheartening) is the use of Gyro for all entities, dragging framerates down to maybe a quarter or less of what they would be otherwise. Anything intensive in QC really needs a strong set of optimized engine built-ins to back it up, otherwise the net effect will be similar.

[goldenboy]

If there was a better way to do what Gyro does, I would absolutely have used it.

A lot of the stuff Gyro does is just awesome, such as water resistance, buoyancy and so on. You know, trying to emulate forces.
It's not used well in RMQ atm, mostly because we never carried out our ideas for new underwater enemies and mechanics. A main show stopper was that the traditional Quake crowd expects their weapons to work like normal underwater. It's the old "we hate change".

Gyro can do so much cool stuff, like stopping projectiles in midair, or stuff like gravity wells, we haven't scratched the surface of - we never got around to implementing the projectile shield for certain monsters for instance, and the e1m8 remake wasn't far along enough to make good use of gravity/vacuum gadgets. Not many people are interested in the use of physics for gameplay. There was no enthusiasm for it. Gyro is seen as a gimmick, unfortunately.

Maybe they will remove it now

[Spike]

mh, I blame the qcc and the instruction set.
qc was designed around being a state-based language. set your properties, have the engine do the complex logic.
the stack management is a not insignificant expense with qc.
function calls are actually really quite expensive. gyro would really benefit from function inlining, for instance, more so than other mods.
the pointcontents thing *should* be possible to cache some how. but with the different waterlevel/watertype behaviour for different movetypes, I guess it takes the paranoid plug-in-compatible aproach. water volumes as a qc-hack is another complication of that.

xonotic has similar performance issues due to heavy qc use.

I wish I had a decent viable solution to it. I'm fed up of maverick solutions.