Mobjs got their own thinker list after all, and disappearing thinkers are automatically purged from their lists and sent to the limbo list.
So it's safe to assume all thinkers inside the mobj list must be mobjs.
Signed-off-by: Nev3r <apophycens@gmail.com>
Set up a main thinker list and a polyobject mover list to test things up. Works so far, networking as well.
Signed-off-by: Nev3r <apophycens@gmail.com>
* 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...
