Create a new BSP level format?

[zturtleman]

Q3/RTCW/ET IBSP level format does not contain draw surface numbers for collision surfaces. Raven's RBSP format (used by sof2, jk2, and ja) does. Loading surfaceNums from BSP would allow new maps to have correct surfaceNums without enabling slow and not always correct cm_betterIbspSurfaceNums.

It's might easier to just create a new BSP format as RBSP has extra lightstyles stuff I'm not planning to support (right now anyway). Either way I'll need to modify q3map2 as it's not possible to use quake3 settings and save a RBSP.

If decide to create new format, I would call it SBSP (Spearmint BSP).

---

I prefer adding RBSP because maps already exist in the format, plus I or other people might end up trying to support games that use RBSP in the future.

I prefer adding SBSP mainly because I don't like RBSP light styles design/implantation...

So I need to decide if I'm going to support RBSP lightstyles. And if not, whether I'm going to support RBSP for sake of SOF2, JK2, JA maps but without lightstyles support...

---

RBSP / JA Light Styles. Allows light entities to blink, pulse, and whatnot (13 options defined in cgame, cannot define per-light). Allows lights to be turned off and on! It's done by generating multiple lightmaps, but the way the colors are updated it's not not possible to turn off only one light, it effects all lights using that light style.

ET has dlight entities which also have light styles. It's completely in game and cgame. Allows lights to have custom light styles or use one of 19 pre-defined styles. Can turn on and off single light, doesn't effect any others. (ET has a 16 dlight entities per-map limit though?)

I prefer ET light styles by looking at code and features, the code is way less intrusive. I haven't looked for visuals for either as of yet...

[zturtleman]

Hmm, I want to change from saving content and surface flags in bsp to saving surfaceParms strings. After issue #50, engine could convert surfaceParms to correct content and surface flags for each game/mod. Allows map to have connect content/surface flags in all games/mods.

Possible way of doing this is new surfaceParms lump (num strings, strings). Then in bsp shaders set bits for which surfaceParms. Reusing contents / surface flag variable in bsp shaders struct would give us 64 bits (64 surfaceParms per-map). Hmm, is 64 unique surfaceParms strings per-map limit reasonable?

In q3map2 (assuming I counted correct..)
Q3 has 37
ET has 56
JA has 72 (though 32 are materials, unlikely to use them all in one map?...)

Maybe make bsp shader have variable length array allowing for more unique surfaceParms?

---

WIP idea. Add two new lumps. Strings lump (just a bunch of c-strings) and surfaceParms lump (bunch of indexes in strings lump). Then have dshader_t just point to the info in the new lumps, for less duplication and allowing more surfaceParms than anyone will ever need (INT_MAX - number of shader strings).

typedef struct {
    char        string[1];
} dtext_t;

// dstring_t index array
typedef struct {
    int     numStrings; // this is overkill, having more than 256 surfaceParms on one shader seems nuts...
    int     stringIndex[1]; // indexes in strings lump
} dsurfaceparms_t;

typedef struct {
    int         nameIndex; // string number in strings lump.
    int         surfaceParmsIndex; // number in surfaceParms lump that contains list of indexes in strings lump

    // should these be offsets so their easier to get to the data without parsing the whole text/surfaceParm lumps?
} dshader_t;

dfog_t could also use index in strings lump for shader name too, ya'know to save 60 bytes * numFogs in the BSP. (dealing with loading SBSP/IBSP would be more painful though...)

[zturtleman]

TODO: look into this.

<Ensiform> really should do something about the patch grid stuff
<Ensiform> its one of the slowest parts on map load
<Ensiform> stiching
...
<Ensiform> > why cant this be done offline

[zturtleman]

RBSP support was added, 0de8aa9. No light style support, yet. New BSP format is not something I plan to do soon.