That's genuinely my baseline, then I ask 'why do we want to manage this dependency?'
I can appreciate the desire to close gaps on expertise deficiency and make a vendor responsible, but the whole schtick of 'outsource everything and focus on your business for advantage' always rang to me as just an excuse to give our money to vendors.
Its almost as if the whole case for vertical integration is just taken as a wash
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)
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.
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.
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.
Total self brag, one of the key foundations of my game engine is that every single instance of any object has an anchor to a timing system, and pausing can be propogated on the same cycle as the input-capture at the most granular level as desired.
I can appreciate the desire to close gaps on expertise deficiency and make a vendor responsible, but the whole schtick of 'outsource everything and focus on your business for advantage' always rang to me as just an excuse to give our money to vendors.
Its almost as if the whole case for vertical integration is just taken as a wash
reply