Basically in preperation of supporting colourblindness modes I implemented the following link when loading palettes.
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter24.html
This basically means I can do whatever the hell I want to the colour profile of incoming paletties, and nobody can stop me. Muahahahaha etc.
Also, I added a saturation feature to show off its full potential, converted gamma from a table to a factor of the calculation, tweaked some menus and made the default value of cvars show up on sliders. Because that's how I roll.
* Provides a helpful description for the hearing impaired, whether permanent, temporary or situational.
* Consvar "closedcaptioning", with on/off values available.
* Only works if sounds are on. This is frustrating. I will see what I can do to allow it to work with sounds off in future, but for now it's dependent in order to properly accept or decline sounds.
* Thanks to MI for making that wiki page a lot more comprehensive a few days ago.
* Weapon ring is now a seperate sfx_wepfir instead of doubling up on sfx_thok.
* Also, made V_StringWidth work with V_NOSCALESTART.
doesn't draw off of the sides, and doesn't ignore snapping or widths for reasons that don't make sense
(for instance: the green bar in MI's test script showed *above* the blue one in non-green resolutions in 2.1.17)
xorshift* PRNG
This needs testing to ensure I didn't mess anything up switching function names around.
Our PRNG sucks. This is probably obvious. I wish I had known better at the time I implemented it, but oh well.
The replacement is an xorshift* PRNG variant with period 2^32 - 1 (meaning that the PRNG state will loop after four billion calls ... that's not likely to happen), versus the old PRNG's period of about 2^22 (?). The output is also much more random and less predictable; the old PRNG would fall into a predictable loop of output after about 4000 numbers were generated, which isn't much.
The PRNG here also outputs numbers as fixed point from [0,1) (that's 0 to FRACUNIT-1, in other words) instead of single bytes at a time. This makes it much easier to calculate things for, say, P_RandomRange and P_RandomKey. A new macro, P_RandomChance(p), is now in use that returns true _p_ percent of the time, where _p_ is a fixed_t probability from 0 (0%) to FRACUNIT (100%).
This doesn't affect netgames at all; the code for seed saving and restoring is identical (aside from a check to prevent seed being set to 0, which breaks xorshift PRNGs). Demos break, but A: _duh_ and B: they're already broken by all the changes to physics to accommodate slopes.
P_Random is deprecated in Lua, as the function was renamed to P_RandomByte. Aside from that, nothing special.
See merge request !64
P_RandomChance is now a macro for something that should happen a
certain percentage of time.
P_SignedRandom was moved to a macro. Nobody cared.
# Conflicts:
# src/p_inter.c
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
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
SPR_PLAY now calls up a secondary spritedef for all animations for all players. Old character wads (including player.dta) are no longer compatible.
git-svn-id: https://code.orospakr.ca/svn/srb2/trunk@8993 6de4a73c-47e2-0310-b8c1-93d6ecd3f8cd
MD2's can be translucent again.
MD2's can use sprites instead of another random texture if they have no
texture.
Patches are drawn in the correct place on non aspect correct
resolutions.
Cropped Patches are drawn.
