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.

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.

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.