* 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...
* Objects!
* Gone is the arcane, difficult-to-remember list of random flags. Say hello to MF_DONTENCOREMAP!
* Alternatively, if the object has a skincolour applied to it, it isn't encoremapped either. (Useful for ghosts, for example.)
* Sectors!
* The autodetecting of sneaker and spring panels is now much more intelligent, and only avoids remapping the plane(s) the effect is availible upon.
* Sector special group 2 no. 15 is now "Invert Encore Remap". It inverts the above detection.
* Linedefs!
* The "Transfer Line" linedef flag can now also be used to deny Encore remappings on linedef textures.
* Right now it applies to every pixel drawn specifically belonging to that linedef, but if people decide it needs changing, we CAN make it apply to midtextures only (like linedef types 900-910).
* Palette remaps.
* Branding.
TODO:
* Doesn't work in GL. (Mostly.) I have SOME ideas on how to tackle this, but...
* Transmaps are broken in Encore for some reason.
* I tried to make in-level colormaps shimmy over, but it didn't quite work, so I commented it out and only semi-fixed it.
* Remove FUNCMATH from all void-returning functions, given GCC80 specifically complains about this case.
* Extend the length of all extant buffers to the safety threshold recommended by the compiler.
* Add void casts to WS_getaddrinfo's setting to prevent complaints about incompatible typecasts.
* Extend the charsel, face, and superface buffer sizes and writes to include the null terminator. (I didn't really want to do this because it's not even particularily NEEDED, but there was literally zero way to get around the request that I could find with multiple online searches. I tried.)
--------
Driftboost formula changed to:
49 + player->kartspeed*2;
(No longer factors weight from previous version)
Collision code now factors character weight for players.
Collision code now only plays the collision sound once, rather than per player.
Weight now factors into drifting's base value. A heavier character will drift more straight with no input and have less control.
Added a cheat check in SetPlayerSkinByNum(), to force speed and weight within the boundaries of 1 and 9.
Nerfed orange turbo to 50 frames, down from 60.
(various large invisible blocks used in the level cause rain to make splashes high above the main level, high enough to make ghostly rain splash sprite artifacts appear sometimes in nearby areas)
I'm convinced there's going to be some stupid side effects from doing this, but it's the quickest way I can fix the polyobj planes not all appearing anyway
Fix R_AddSingleSpriteDef's I_Error messages
Whoops, seems I forgot about this little branch. Basically this fixes how for a character's sprites, a full sprite lump name is displayed instead of just its sprite prefix in the "R_AddSingleSpriteDef: No patches found for [sprite prefix] frame [frame character]" message (unlike when it occurs for non-character sprites), resulting in something like "R_AddSingleSpriteDef: No patches found for PLAYC2C8 frame \^" which does NOT help custom character authors at all as it just confuses them instead. (for the record, the problem would actually with the ^ frame and not the ones displayed after "PLAY")
Oh, and the same problem is also fixed for this similar message: "R_AddSingleSpriteDef: Sprite [sprite prefix] frame [frame character] is missing rotations"
See merge request !95
* NAMEcL refers to a frame which is seen for the entirety of an object's left side.
* NAMEcR refers to a name which is seen for the entirety of an object's right side.
* NAMEcLcR does both sides.
* Having just a NAMEcL requires you to fill in the opposite side either with NAMEcn where n is 1 and 5 to 8 OR fill in with a NAMEcR
* Switches down the centerline of the object instead of at the ANGLE_202h interval for normal sprites.
* Characters were selected for 1) ease of use and 2) not getting in the way of adding support for zdoom's totally bananas 16-way sprite system at a later date if we so choose
Note: polyobj_t's "translucency" is apparently a SIGNED integer, so in theory it's possible to get polyobj flats to use the "spanfunc = splatfunc" line using negative values. If this is not meant to happen, this should probably be fixed asap
Conflicts:
src/f_wipe.c
more detailed description: vissprites now store dispoffset in a separate variable from (y)scale, and uses it to influence order between sprites without it affecting the actual drawing of the sprites themselves
Compiling errors fixed in this commit:
* Various cases of mixed declaration and statement code
* Implicit declaration of slope functions (read: you forgot to put "include "p_slopes.h" in MORE than a few places)
* an odd case of a bad fixed_t to float typecase, cause by using P_GetZAt directly inside FIXED_TO_FLOAT
* a few minor cases of bad unsigned-signed comparisons
* no prototypes for some of the new slope functions. For goodness sake Red, this is basic stuff!
