5 May 2012 · 11 commits by 1 author · SVN
------------------------------------------------------------------------
r2643 | helixhorned | 2012-05-05 15:24:50 -0700 (Sat, 05 May 2012) | 6 lines
Factor out almost all instances of setting ...->pals.[rgbf] into P_PalFrom.
This is so that it may be intercepted in the future.
The only code that's not replaced by the function call is with the CON
interface to g_player[].ps->pals via player[].pals X and .pals_time.
Also, comment out one instance because it's overwritten by a succeeding one.
------------------------------------------------------------------------
r2642 | helixhorned | 2012-05-05 15:24:33 -0700 (Sat, 05 May 2012) | 1 line
In game code, replace remaining literal status numbers by their defines.
------------------------------------------------------------------------
r2641 | helixhorned | 2012-05-05 15:24:17 -0700 (Sat, 05 May 2012) | 1 line
Prevent an (unlikely) integer overflow in neartag with huge switch sprites.
------------------------------------------------------------------------
r2640 | helixhorned | 2012-05-05 15:24:02 -0700 (Sat, 05 May 2012) | 4 lines
Remove the 'inline' qualifier of some (not-so) short functions.
Besides being the compiler's job nowadays, they significantly inflate
the size of the debugging builds.
------------------------------------------------------------------------
r2639 | helixhorned | 2012-05-05 15:23:44 -0700 (Sat, 05 May 2012) | 4 lines
Accumulated trivia, mostly "the usual".
Among other things, comment out very seldomly (or not at all)
used sprite member macros: SV, ZV, RX, RY, CX, CY, CD, PL.
------------------------------------------------------------------------
r2638 | helixhorned | 2012-05-05 15:23:17 -0700 (Sat, 05 May 2012) | 1 line
Make the GAMMA_CALC macro use double instead of float and use it in menus.c.
------------------------------------------------------------------------
r2637 | helixhorned | 2012-05-05 15:22:59 -0700 (Sat, 05 May 2012) | 14 lines
Add bit 16 to the two main setbrightness() users, add bit 2 to one of them.
(I.e. also restore r2232 again.)
The first one is the palette restore logic in G_DisplayRest, the second
is CON setgamepalette, to which the "don't gltexinvalidateall()" bit is
added to mimic the first. Hightile invalidations aren't really useful for
anything other than reloading them after a video mode change, IMO.
These changes mean that
1) active full screen tints should (almost) always be kept with a basepal
change. The only exceptions to this are when tints really have to be
cleared, e.g. when changing the player view in co-op play.
2) there should be no performance issues with simultaneously changing
basepals while a tint is applied
------------------------------------------------------------------------
r2636 | helixhorned | 2012-05-05 15:22:34 -0700 (Sat, 05 May 2012) | 20 lines
Tweak the conditions under which setbrightness() invalidates GL textures.
Previously, we checked whether the faded palette has changed (by way of CRC)
and invalidated the textures then unless the preserve flags were set. This
however could lead to wrongly invalidating them under unfortunate circumstances,
e.g. basepal change from CON + tints at the same time before r2620 which
reverted r2232.
Now, only invalidate them if the corresponding preserve flags are clear AND
* the base palette has really changed OR
* the palette CRC changed and we were running on software gamma
The latter means that performance-killing invalidations may still happen on
GL platforms lacking HW gamma (for ATI, it's currently only disabled in 8-bit
fullscreen).
Also have a new global 'basepalreset' to fake a basepal change for
setbrightness(), currently used when changing renderers so that going from
Polymer to Polymost and back again will invalidate the Polymer textures
on the second change, potentially re-applying a basepal highpal. (Still
with me?)
------------------------------------------------------------------------
r2635 | helixhorned | 2012-05-05 15:22:19 -0700 (Sat, 05 May 2012) | 4 lines
Gray out CONTRAST and BRIGHTNESS sliders if no hardware gamma is available.
The sliders themselves still permit changing values, but are drawn with a
'disabled' shade because they're non-functional with software gamma.
------------------------------------------------------------------------
r2634 | helixhorned | 2012-05-05 15:22:05 -0700 (Sat, 05 May 2012) | 4 lines
winlayer: Remove code that worked around a (wrongly) not set have_ATI variable.
This was fixed with the preceding change; software mode will now always use
software gamma if an ATI/AMD card is detected.
------------------------------------------------------------------------
r2633 | helixhorned | 2012-05-05 15:21:49 -0700 (Sat, 05 May 2012) | 5 lines
On Windows, determine if we're running on a ATI card at startup even in classic.
Previously, I knew no way of querying for graphics adapter vendors/names from
anything other than OpenGL. Googling revealed a way to do this with the
Windows API.
------------------------------------------------------------------------
This is so that it may be intercepted in the future. The only code that's not replaced by the function call is with the CON interface to g_player[].ps->pals via player[].pals X and .pals_time. Also, comment out one instance because it's overwritten by a succeeding one.
Besides being the compiler's job nowadays, they significantly inflate the size of the debugging builds.
Among other things, comment out very seldomly (or not at all) used sprite member macros: SV, ZV, RX, RY, CX, CY, CD, PL.
(I.e. also restore r2232 again.) The first one is the palette restore logic in G_DisplayRest, the second is CON setgamepalette, to which the "don't gltexinvalidateall()" bit is added to mimic the first. Hightile invalidations aren't really useful for anything other than reloading them after a video mode change, IMO. These changes mean that 1) active full screen tints should (almost) always be kept with a basepal change. The only exceptions to this are when tints really have to be cleared, e.g. when changing the player view in co-op play. 2) there should be no performance issues with simultaneously changing basepals while a tint is applied
Previously, we checked whether the faded palette has changed (by way of CRC) and invalidated the textures then unless the preserve flags were set. This however could lead to wrongly invalidating them under unfortunate circumstances, e.g. basepal change from CON + tints at the same time before r2620 which reverted r2232. Now, only invalidate them if the corresponding preserve flags are clear AND * the base palette has really changed OR * the palette CRC changed and we were running on software gamma The latter means that performance-killing invalidations may still happen on GL platforms lacking HW gamma (for ATI, it's currently only disabled in 8-bit fullscreen). Also have a new global 'basepalreset' to fake a basepal change for setbrightness(), currently used when changing renderers so that going from Polymer to Polymost and back again will invalidate the Polymer textures on the second change, potentially re-applying a basepal highpal. (Still with me?)
The sliders themselves still permit changing values, but are drawn with a 'disabled' shade because they're non-functional with software gamma.
This was fixed with the preceding change; software mode will now always use software gamma if an ATI/AMD card is detected.
Previously, I knew no way of querying for graphics adapter vendors/names from anything other than OpenGL. Googling revealed a way to do this with the Windows API.