lifning

πŸ—¦ old and unimproved! πŸ—§

  • gender? 'ardly she/'er!

if you read my header image, i'm sorry


πŸ“ blog
lifning.info/
πŸ’ͺ demogroup
hell-labs.itch.io/
🌐 fediverse
snoot.tube/@lifning
πŸ•ΈοΈ website league
beam.phosphor.buzz/@lifning

bruxisma
@bruxisma

It's a shame that the Quake BSP file format hasn't ever been turned into a proper specification so all we've got are a few proprietary compilers for descendant engines or descendant descendant engines like TF|2 or whatever, and after doing some digging I've come to the realization that the glTF cannot really be used to expand upon BSP files, thus rendering them as an archaic format that will eventually be lost to time, even as stable as it was to be used for so many games for so many years even as id Software abandoned the format so they could use megatextures in Rage which itself was later ripped out and seen as unnecessary in the Doom Eternal approach of "just render a decal, bro", all of which ended up being TGA files anyways.

I collapse back into a deep slumber, unknowing what I have just stated


You must log in to comment.

in reply to @bruxisma's post:

you can't really compare tf|2 bsp and quake bsp, they share similar principles but anything descended from source is a fundamentally different format from any quake bsp and can't really be thought of as the same thing, even quake-era bsp can't even be considered one format, as it was changed several times between the quake games, and most people that forked the engine made changes anyway
fortunately there's a version field! so you can still identify what game your bsp is from using just the map file! so it's not impossible to support multiple versions of the format from just one tool
also afaik bsp was removed for doom 3, not rage

I checked and you're correct on the Doom 3 transition. However,

It's a shame ... all we've got are a few proprietary compilers for descendant engines or descendant descendant engines

The gist of this post was specifically "gee it's a shame that all we have for this type of file format is a proprietary system, which means we will can read, but not write, and thus the format will decay and bitrot because it will never be possible to recreate these formats outside of a handful of reverse engineering attempts or source leaks.

A version field only tells you what someone has modified in the lumps section, it doesn't suddenly make it possible for you to take any intermediate format and turn it into said modified BSP file.

i suppose, i think the map compilers for q1-3 are all open source though, so at the very least those are largely open formats, i believe there is also an open source goldsource map compiler (unsure if based on official sources or not) and an open source source engine compiler (probably not based on official sources)

it is unfortunate though, however for a number of these formats (though it would be cool to have them open regardless) they're super tied to the engine in question and how it works, rather than being something that could really be repurposed to other engines
for instance, any of the respawn source's bsp formats are built with super complex collision models and other systems in mind that only really work with their engine, you'd be hard-pressed to embed their maps into other engines without just, not using a number of the features they support i think (is that necessarily a bad thing? unsure)

also re:version, i meant more that the version header is useful for tooling that operates on compiled maps, so at the very least it's possible to understand what you're looking at from a compiled map, even without sources, though i think this was probably a dumb thing to include as it wasnt super relevant to what you were saying