This is a description of BSPX, a file format providing a way to extend Quake 1 maps to include goodies such as colored lightmaps without breaking compatibility with existing Quake engines.

The format is designed to be simple and easily extensible. A BSPX file is just like a normal Q1 .bsp but with some extra data added at the end, structured into "lumps", each having a human-readable name. For example, "RGBLIGHTING", "24BITTEXTURES", "TEXTUREALPHA".

Engines that don't know how to use some of the lumps can safely ignore them. Engines that don't understand BSPX at all will see a plain Q1 .bsp file and load it just fine.

A compliant engine, when loading a Q1 BSP file, should find the end of all standard lumps by going through the lump table and finding the maximum value for (fileofs + filelen). This is where 8 bytes should be read from the file to see if the BSPX identifier is present.


As of May 2011, ezQuake implements one extension, 'RGBLIGHTING'. It's a colored lightmap like a .lit, but the data is included right in the bsp, relieving us of all the logistical headaches of supplying the lits to the user and making sure the correct lit is loaded, which may be complicated with maps like start.bsp which many mods try to make a custom version of.

Possible future extensions include 24-bit textures and transparent textures.

— ctl6beta5.bsp — a 4x4 map by Muff1n, currently in development.
— ctl5.bsp — another nice map by Muff1n, colored by me
— dm3-rgb.bsp — sample map with RGB lightmap built in.
— darkplaces-glx — DarkPlaces for Linux x86 with BSPX + RGBLIGHTING support. Built on 2 June 2011 (svn r11175).
— model_brush.c.patch — patch against DarkPlaces svn r11175, adding BSPX + RGBLIGHTING support to DarkPlaces.
— ezQuake gl_model.c and diff.
— addlit.c — source for tool to integrate lits into bsps.

sounds like frikac's maps-as-paks thing, except less generic, and with added special cases.

Any links to frikac's maps-as-paks thing?

It was described only on quakesrc forums as far as I'm aware, which are now dead and lost.

Basically after the lumps in the BSP, there's a pak header. Exactly the same as a pak file, but with the starting header offset placed at the end of the bsp's header.
The advantages of merging file system with bsp extension features is that the engine doesn't need lots of special cases to check to see if its fred.lit or RGLIGHTNING, qc doesn't have to check for fred.way or WAYPOINTS, etc. The engine still runs progs.dat - but it could come from the bsp itself. You surely get the idea.
One down side is that while you can potentially do map-specific replacements, such replacements can end up cached without the engine realising, though this only applies to direct replacements (which would not be directly possible with your bspx anyway).
The other down side is that the contents of the bsp depend upon the file name of the bsp, in the case of lit or way files. I don't see this as too major myself though.

Personally I favour downloading the pak/pk3 that contains the bsp, rather than the bsp itself (with the exception of certain known paks).

Okay, including a full-blown pak file in a bsp is sure an interesting approach, but I like my bsps to be compiled maps and not a collection of random things. If bsps start to have progs built right into them, you may end up spending lots of time scratching your head trying to figure out where your progs is loaded from, which is already complicated enough with progs, qwprogs, spprogs and qvms and several directories and paks in search path.

Q1 bsps are mostly fine as they are, but a few things have happened in computing since 1995 and it would be cool to reflect that.

Another issue with pak files is that you have to dive into the vfs layer which is implemented differently in every engine and you may well end up with engine-specific quirks. And if you ask me,
is easier than adding special case handling for "maps/lits/mymap.lit" if you don't want colored lighting to break as soon as you rename the bsp.

The BSPX code I have right now is just a couple of screenfuls (the typedefs, one function to load and rigorously check everyhing, another one to access the lumps), all sitting compactly in gl_model.c and easily portable to other engines.

Wouldn't you allow the loading .lit files as you do with external textures, by first trying to load the .lit, if failed then load the lighting within the .bsp?

*Ack! "// all done, but we let them override it with a .lit", nevermind...

wondering if this link helps recovering lost stuff


http://web.archive.org/web/20031019183603/http://quakesrc.org/?Page=forumindex

Some time has passed, whats the status?

It's implemented as per the spec above in ezQuake builds starting from mid-September 2010.

It should load the dm3-rgb.bsp linked above just fine.

Ouch, my website is down though

Hehe yeah I noticed it was down . How about some actual support for other stuff, or ideas? Improvements thought of? Or is the rest left out to the mappers out there?

Why are you asking about this, dimman?

Well I started not long ago with C programming and also some Quake dev. Cokeman lured me into learning more about .bsp's. I recently wrote a small program that extract textures from bsp's to .png. Just out of curiousity mostly I think

Now I have no where near, not even remotely, as much knowledge as Spike about this stuff, but i don't think the idea about pak-files instead sounds like a realistic option compared to this. I think i just wanted to bring back attention to the discussion and subject

Good, so maybe you could help me spread the word and eventually convince some mapper to make a release of a new map with colored lighting built in rather than distributed separately in a lit.

I really like the BSPX format, looks like it solves a lot of issues in a sensible manner. However it sounds as though we need a confirmed list of tags for extensions otherwise different engines are going to break compatibility for maps.

RGBLIGHTING sounds like a good one for coloured lighting, might I suggest that texture extensions should include a file type in their tag? TGATEXTURES, PNGTEXTURES etc.

Would you also want Shader definitions (I'm meaning Q3 style not OpenGL style) and sounds included as well?

When there's a disagreement among engine coders (the few on the scene today) about a particular extension, prefixes like DP_, FTE_, ZQ_ can be used, as currently done with QuakeC extensions. But in case of consensus it makes sense to use a shorter name. The first and only extension I have implemented so far, RGBLIGHTING, is a no-brainer in this sense, you can't possibly want it implemented differently, it's just raw lighting data.

I'm not much of a renderer/mapper guy so I don't have any clear proposals for more extensions right now; I just want the bsp extension framework to get off the ground and see what people can come up with.

Personally I'm rather conservative with regard to types of data I want to see in a bsp (which is why I'm not a big fan of the existing EBSP format which is basically a pak inside a bsp and lets a map override anything in your game directory). Lightmaps clearly belong in a bsp, but do sounds? They tend to be reused across several maps, so it makes sense to keep them as separate files IMHO.

Shader extensions sound cool, but my expertise is limited here so I would rather let LordHavoc or Spike decide. Maybe it makes sense to just use q3bsp when you want shaders (both DarkPlaces and FTE support q3bsp).

While I certainly agree with you about limiting the types of information stored in a BSP, I was suggesting sound as an accompaniment to Shaders. That way a level designer could create a shader or material file and define both the texture and associated sound files with each material. A metal wall would 'ting' when bullets were fired at it while a brick one would make a suitably solid sounding noise.

With regard to the reuse of items across levels this concerned me also. I was thinking more of textures than sounds however. Many textures are going to get reused if an author creates a level pack (something that is unfortunately far rarer these days), and this would mean many duplicate texture sets per level.

I know that Zip files use the DEFLATE algorithm by default (and so do compressed PK3's, seeing as they're just Zips anyway), which does string de-duplication, but I don't know if that affects strings repeated across multiple files. If so then by employing compressed PK3 support we're instantly away from the problem. This is something that would need further consideration.

If we can use q3bsp then you can just implement colored light data when u make the map. All engines must support this though, especially ezquake