Quake1 Bsp2 Format

[goldenboy]

The thing is, since BSP2 allows for humungous maps, you'll probably indeed have to support higher limits in the protocol as well. Like, use floats for coords (to get across the 4096 unit barrier) and there was something else that needed to be done at 8192 units (I have maps that break that as well).

There was also something done to avoid bmodels flickering when inside too many vis leafs (physically LARGE environments will introduce problems like this). I recommend just looking at the RMQE source.

RMQ engine used "protocol 999" for this. Not sure what protocol FTE uses when running these physically large maps.

---------------------

About hmap2 (LH version): It really needs to be more lenient with non-critical compiler warnings/errors (right now it errors out hysterically at the tiniest anomaly, such as "leaf portal saw into leaf"), it needs to be more compatible with AguirRe's tools (command line switches, workarounds for delay 4 lights), and it should allow us to force BSP2 format even for smaller testmaps. It probably also needs support for func_water and so forth (extras r4 / RMQ). It also pointlessly tried to grab more memory than I physically have, so I had to create a swapfile to get it running (after hacking it to bypass marginal error messages).

In large maps, it is completely normal to have a string of compiler warnings. No problem as long as nothing critical is among them. No need for a compiler to treat stuff as critical that isn't. Spit out a warning and march on. Same is true for unrecognized command line options. Print warning, move on.

[taniwha]

spike: thanks, I'll look into that.

[Spike]

regarding existing larger coord protocols, there's RMQ's 999 protocol (good choice for more vanilla NQ clients), DP5+ (lots of other changes, and is a moving target), and FTE's QW extension (the only such qw-based version).
There's likely a few others, and you can always create your own.

FTE servers can use all 3 of the above protocols, depending on what the client connects as, but it will only use them if sv_bigcoords is set - it can cope with different protocols, but not different primitive data types.
assuming you already support one fte protocol extension in your client, adding FTEPEXT_FLOATCOORDS=0x00008000 to the pext handshake will enable qw connectivity+larger coords+larger angles when the fte server is using sv_bigcoords 1, with no other protocol changes.
coords are floats, angles are boosted to 16bit.

the RMQ 999 protocol is identical to the fitz 666 protocol, except that there is a feature bitmask following the version value (MSG_ReadLong), a bitmask=0 is otherwise identical to 666.
These are the relevent values:
#define RMQPRFL_SHORTANGLE (1 << 1)
#define RMQPRFL_FLOATANGLE (1 << 2)
#define RMQPRFL_24BITCOORD (1 << 3)
#define RMQPRFL_FLOATCOORD (1 << 4)
#define RMQPRFL_EDICTSCALE (1 << 5)
#define RMQPRFL_ALPHASANITY (1 << 6)
#define RMQPRFL_INT32COORD (1 << 7)
Other values should probably report incompatibility.
the svn version of rmq currently uses (PRFL_INT32COORD|PRFL_SHORTANGLE|PRFL_EDICTSCALE).
fte servers will use (RMQFL_FLOATCOORD|RMQFL_SHORTANGLE) for network precision, if you connect using NQ protocols with sv_bigcoords 1.
I'm not going to document the full 666 protocol here though, only that there are more svc_clientdata bits, and more entity fast-update bits, and more svcs. I'm not aware of any other changes, its just those additions that need special care. Server-side support should be fairly trivial.

the DP5, DP6, DP7 protocol family all use the same fixed settings.
coords are floats, angles are boosted to 16bit.
far too many other changes.

[Tronyn]

Thanks to everyone for the replies/information. I expect to start compiling the final version in the next week or two. So as of now I'm using the RMQ tools. But am I understanding the general information properly (unlike many mappers, I've never been a programmer) to say that there is an earlier version of BSP2 which currently has wider support? If so, where can I find those compiling tools? I'd like to at least try to support more engines if I can.
Cheers guys, I should have joined this forum long ago.
Tronyn

[goldenboy]

Tronyn: When Darkplaces got BSP2 support, LH suggested some minor changes which we agreed upon in order to spread BSP2 to more engines.

These changes were due to be incorporated in the RMQ tools as well, but that was actually never done because that was the time when activity dwindled in RMQ.

As a result, the RMQ tools now use an older, incompatible version of BSP2.

hmap2 is the only compiler that ever got the required fixes.

If you use the RMQ tools, you'll have to require the RMQ engine pretty much. That's not a major problem, but if people keep using the RMQ tools, we will have two versions of BSP2 drifting around the community which is pretty stupid.

That's about it.

[taniwha]

In theory, qfbsp supports the newer BSP2 format. I haven't tested BSP2 writing yet, but the way I added BSP2 support, if reading works (which it seems to), writing should.

[taniwha]

[goldenboy]

That sounds like the issue, yeah.

[qbism]

I compiled Goldenboy's example map in hmap2 and took a stab at adding BSP2 to software Quake. I got "Bad surface extents" which usually means the map was compiled with "-darkplaces" on. This option increases extents to 1024 (I think) compared to software Quake's 256 max. Does BSP2 format require larger extents? I didn't look at hmap2 yet to see if it was triggered on there. If not, then there's something I still need to chew through in model.c. I've been using darkplaces and hmap2 source codes as a guide. Darkplaces code isn't exactly cut-and-pastable to other engines so might have missed something. I'll also look at rmq engine. I still sort of expect the software engine to blow up even if it can load the map.

[goldenboy]

I get bad surface extents in darkplaces as well (with the bsp from the zipfile I posted, compiled with hmap2). I didn't use the -darkplaces option, the map is simply quite big. It's 16,000 brushes or so. There was no leak or anything though.

[Spike]

bad surface extents generally means the surface is bigger than 18 lightmap samples (256 if its darkplaces).
This is only relevent for lightmapped surfaces. You can skip the check for sky or water, or just render it as if it had no lightmap samples (software's r_drawflat really shouldn't have any issues).
I don't really see why you can't bump the extents in software rendering so long as its bumped in enough places, though if you do you'll get mip-choice weirdness.

I didn't get that error in FTE, and I'm sure taniwha would have reported it if he'd had that issue, so I've no idea what the issue is with darkplaces.

[qbism]

I was able to confirm the DP extents error on a fresh hmap2 build of the sample map. Since DP gives same error, and it's allowing 256 lightsample width vs 16 in super8 (same as winquake), it is possible there is a bug or limit I've duplicated. Next I'll try compiling and running a smaller map, e1m2rq.map from RMQ svn.

[taniwha]

Actually, I had forgotten to test it in the sw renderer. However, I just did and it works... mostly. Too many polys get drawn, I guess as depending on which direction I face (at player start), parts of the map disappear.

[qbism]

[taniwha]

A long time ago, I had moved bspfile.[ch] out of "common" and into QF's main library (libQFutil) and made all tools and the engine use it (though while doing bsp2 support, I discovered I had forgotten to remove the endian code from the model loader... oops ). I had also done a lot of work to merge the gl and sw bsp loaders as much as possible. This is why QF can have four renderers without me losing too much hair: any time I notice code that's common (enough) between the renderers, I make it common.

I used hmap2's bspfile.[ch] as a reference (mostly the header, but I also found a bug in the header: it was saying a node's firstface/numfaces vars were still short when they're actually int. Lordhavoc fixed that ). After that, it was just a minor matter of fixing some local vars that were short (including mnode_t and asm_draw.h) but needed to be int.

The only tricky part was dealing with extended bsp-29 files (eg, conflagrant rodent (oms2.bsp)).