Light colour

[frag.machine]

/me suggests adding support to embedding the .lit file contents into an extra, optional lump as a desirable feature in BSP2...

[mh]

Always expanding light to 3-component was considered but rejected because it would create a dependency on having coloured light support in an engine before BSP2 could be implemented. An extra optional lump is a possibility (we didn't reserve space in the header for marking this kind of thing though ) but I'm not seeing how it's much different from just having a LIT file too.

LIT files are nice. You can delete them, move them around, recompile your lighting without affecting the source BSP, keep multiple copies for experimenting with, etc. All advantages. I can see that including it in the BSP can make distribution easier, but in this case I think the case for not including outweighs.

[Spike]

there's one strong case for internal lit files, and that's with automatic downloads in various engines (quakeworld for instance) - most clients won't autodownload lit files. which means you're either attempting to download a lit file from the server every single time (probably even for vanilla maps...), or you expect to never have the lit file for custom maps.

some sort of optional lump would be quite nice...
/me points at http://www.quakeworld.nu/forum/topic/47 ... esignsucks

[ajay]

Once Spike had worked it out, it was just a matter of adding

COPY "d:\Games\idSoftware\Quake Maps\earthquake\equake.lit" "D:\Games\idSoftware\QUake\earthquake\maps"

to the batch file. I quite like that I can compare the non-coloured and coloured versions by just temporarily removing the .lit file, rather than having to re-compile the map. Which is a time saver.

[mh]

there's one strong case for internal lit files, and that's with automatic downloads in various engines (quakeworld for instance) - most clients won't autodownload lit files. which means you're either attempting to download a lit file from the server every single time (probably even for vanilla maps...), or you expect to never have the lit file for custom maps.

some sort of optional lump would be quite nice...
/me points at http://www.quakeworld.nu/forum/topic/47 ... esignsucks

Reading through that, I can see one clear-cut case for implementing coloured lighting differently. That's where you might want to extend the light data to 32 bit and make some use of the extra 8 bytes, either by storing in a 10/10/10/2 format or by encoding some HDR info into the alpha channel. Useful because there are cases where light data can be clamped (and therefore dynamic range lost) during the light.exe process. Needs both engine and tool support, of course.

That aside (and it is just an aside) another advantage of storing directly in the BSP file is that it neatly solves the old problem of "which start.lit gets loaded?" (although other solutions for that do exist - shame they're not more widely implemented).

I'd need to check the ezQuake source to confirm this, but it seems weakly specified for lighting in that it doesn't explicitly state whether light offsets in your dface_t structs are premultiplied by 3 or not, and doesn't seem to allow for dead space at the end of the BSP file (which is legal, which is generated by some tools, and which won't be found by just totting up your fileofs and filelen values).

We've already got havoc caused by multiple and/or conflicting standards for sky, fog, external textures which were a result of jumping in too quickly with implementing something before the fuller ramifications were thought through, so this is something that would need a lot of input from multiple coders, mappers, modders and players, and from both SP/MP and NQ/QW sides, to firmly nail down before I'd personally feel happy supporting it.

[Spike]

its really just internalised lit files in ezquake.
the bspx lump trails is located at a position after the standard lumps, so you will likely need to rewrite the entire bsp to add an extra lump (assuming it already has a bspx lump in there - if it doesn't then you can probably just append, so long as the offsets in the part you append are correct).
dface_t offsets are the same as they always were, giving backwards compatibility - like I say, its just an internalised lit.

[frag.machine]

LIT files are nice. You can delete them, move them around, recompile your lighting without affecting the source BSP, keep multiple copies for experimenting with, etc. All advantages.

Also, you can forget to copy it to the same map folder (I already did that a number of times, and although obvious no one here remembered to ask to ajay, which kinda shows my point ), or use/distribute a wrong/outdated .lit file, which in some engines like DP completely f*s up lightning BTW. Yeah, there is flexibility and kinda makes the mapper life easier, which is cool, but this also leaves a lot of room for mistakes during the deploy phase, turning the end user life not so easy. Maybe the best of two worlds could be the answer, first try to load an external .lit if exists, else try to load the one from the extra lump into the BSP2. I dunno, it's just an idea.