* Store raw values per rgba in extracolormap_t (no maskcolor or fadecolor)
* Crunched some UINT16/32 into UINT8
* Calculate mask values in R_CreateLightTable
* ifdef out EXTRACOLORMAPLUMPS
* Split R_CreateColormap to R_CreateLightTable
* Replace extra_colormaps array with next/prev pointer chain
* Remove foundcolormaps; instead store lumpnum in extracolormap_t
* Add properties to extracolormap_t for portability
With that, I moved R_CreateColormap2's exclusive software colormap malloc code to R_CreateColormap, and merged the two software-only blocks of code into one. I also disabled any unneeded variables and fixed a preprocessor-related goofup
* Fix that thing where ALL transparent FOF planes were continuously fullbright unless encased in a fog which disables sprite fullbrightness, which was long-hated by many people in the community!
* For backwards compatibility, setting flag 1 in that fog field (which is probably the most common "in-the-wild" usage of this feature) will continue to make objects un-fullbright.
* For situations where you desperately want the behaviour to be enabled, you can apply fog flag 2.
* Change the fadestart and fadeend range in which colormaps are generated.
* The problem HERE was that the darkest light level reached by generated colormaps was actually slightly brighter than the darkest level reached by normal colormaps.
* The typo I fixed does have SOME basis in fact - standard colormap lumps are 34 (33 in 0-indexing) long rather than 32 (31), but whoever wrote this didn't realise that the code for generating them didn't do it DooM style, just bright-to-dark with no extras on the end...
-Colormaps, palettes and other stuff are properly loaded now. It was a bug related to the generation of the lump name with files in the root of the PK3.
Known issues:
-Map WADs' REJECT and BLOCKMAP are still not loaded.
-Folders aren't loaded as lumps anymore
-Can now load an arbitrary number of TEXTURES lumps in PK3s. Name them textures.gfz, textures.thz, ..., for example.
-Now can load map WAD files inside Maps/ directory, but they must only contain map data explicitly!
Known problems:
-There's an issue causing a crash with palettes and colormaps in PK3s.
-SS_START and SS_END don't work now. Will check later.
-Standalone lumps for maps in the Maps/ folder don't work anymore; perhaps I should keep that functionality?
Notes:
-It's now a mashup of something dumb that I wanted to do and yet piling hacks again.
-A lot of code duplicity with map lump loading functions.
This is just in case someone actually tries to dump in C_START/C_END and "add" colormaps using them, not that they would ever be used currently anyway.
-DEFLATE-compressed lumps work properly now.
-All "big" lumps are supported now with the exception of WAD maps.
Notes:
-Compiler spits out a shitload of warnings still.
-Individual lump reading clashes with folders of the same name (see TEXTURES lump, and the Textures/ folder).
Signed-off-by: Nevur <apophycens@gmail.com>
-Expanded folder recognition for PK3s. Some resources are still not loaded from them yet.
-Took a glimpse at how maps are loaded, since the flat recognition is rooted somewhere there; did nothing yet about it though.
-Working towards "generalizing" how new resources are handled. Some var and functionality redundancy is still present.
-Moved the MD5 check for added files up so it avoids unnecessary work when you mess up and re-add a file.
-Using compression enum for compressed lumps now.
-Vastly improved central directory seeking algorithm, big files are read fine now. Thanks a lot JTE!
-Improved remaining central directory navigation algorithm, we know and expect what data is coming from now on, after all.
-TX_ textures and sounds are replaced, but textures crash the game on mapload, and sounds are simply mute when replaced. Might have to do something with caching, I don't know yet.
Used instead of pLocalPalette when attempting to determine objective truths, such as "the colours of this gif without color profile modification" and "what indicies should this colormap remap to".
Also, made f_wipe.c's paldiv only get calculated once.
mazmazz