Omg I love this! I have been finding excuses to do little animation engine features that arent on the critical path of development for the sake of creative self-indulgence. Such features shipped was alpha channel based fading using the fundamental opengl fade parameter (under the hood its a linear interpolation of alpha values over 256, pieced together over a provided pair of timestamps).

I tell you what I'll do today on my dev time, I'll try implementing grayscale without aby research on pause and then compare notes (I'm assuming this wc code is available somewhere, which may be a bad assumption)

▲ bombcar 2 days ago | parent | next [-]

WC code is likely not (legally) available, but Wolfenstein and Doom both did similar palette tricks and are documented in the Black Books for each - https://fabiensanglard.net/three_books_update/index.html

Code for those is available.

	▲	RobRivera 2 days ago \| parent [-]
		Oh rad! Thanks for the heads up. I'll do a post-dev comparison to see what I land on and what was done here.

▲ netcoyote 2 days ago | parent | prev [-]

While I don't have the original code, it's something along the lines of this:

    // for each palette entry:
    pal.r = pal.b = pal.g = (byte) (0.299 * pal.r + 0.587 * pal.b + 0.114 * pal.b)

	▲	RobRivera a day ago \| parent \| next [-]
		So I was able to create all the bits necessary to introduce the palette change in a similar manner (3x256 changes) on the triggerz and at the moment of truth instead of grey I got a GREEN and PURPLE fadeout (I wasnt sure if you meant rbg or rgb for the ratios so i tried both). I also tried 128 across the board for grey, and it just made a dull fade which may be the best I can do with my method. I think it may simply be because rather than have palletes controlled by rgb, I load predrawn sprites using sfml's sprite and texture classes. So the default rgba is 255,255,255,255 - so I have a sidequest to figure out the RIGHT WAY of applying rgb changes to predrawn sprites. It may very well be a simple matter of "sfml does it differently" or perhaps having grey variants of all sprites and toggling. I feel there has to be a way to accomplish the fade to grey programmatically. Fun little dive tho! I'll have to post an update when I figure it out.
	▲	a_e_k a day ago \| parent \| prev \| next [-]
		From my recollection of doing fun palette stuff back in the DOS VGA days, I'm betting it was more like: `pal.r = pal.g = pal.b = (77 * pal.r + 150 * pal.g + 29 * pal.b) >> 8;` Hardware floating point was rare before the 486 DX and Pentiums. Not to mention that Integer<->FP conversion was slow. And division of any kind has always been slow. So you'd see a lot of fixed-point math approximations with power-of-two divisors so that you can shift-right.
	▲	RobRivera 2 days ago \| parent \| prev [-]
		I havent gotten behind the console, but thats like, exactly what I was gonna do, except precompute like 5 or 6 tween values for r,g,b between 255 and the target for greyscale. But rather than do that and cache them for timing triggers, I kind of like the scaling down by multiplication approach. Edit: manipulate the rgb values that is - I wouldnt have converged on those hard values on my own.