Thanks for the information!
The documentation of SDL_SetGammaRamp says it returns -1 when programmable gamma correction is not supported and -1 evaluates to 'true'.
I didn't even know that (-1 = true). Should have, considering I am writing quite a bit of php.
Pity about the gamma curve, but nothing that can be helped. I've looked at the unmodified Mac source released in 2000 when MS took over Bungie, but that one doesn't help much. They're using Quickdraw and 'valkyrie acceleration' instructions do do the flashes in 16 and 32 bit. Must have been very fast since that game ran great on a 66MHz PPC machine already using higher colour modes.
You could implement your own color lookup as part of the scaler routine: map a 16-bit color value to another 16-bit color value. It would cost some performance, but you could do it only for non-default colors (have two separate routines or some macro tricks), so most of the time this step would be skipped.
I've thought about that, but currently it's way, WAY beyond my capabilities. Actually I'm still surprised I came so far
. I've read about this method on google. Perhaps in a few months if I actually get the hang of this C++ thing. Performance will be important though. This game uses long fades, but also does overlays using the gamma function for when underwater. You spend a lot of time underwater in some levels...
As for the scaling speedups, the AVERAGE equal check was there in the example for retaining quality. Since the whole main game window is double-pixeled (that's what the game does in 'lo-res' mode, the Mac didn't support anything lower than 640x480) I thought it might be speedier to leave it in. Actually I didn't change much except for the bitmask above to take away 3 pixels instead of 2. I'll try taking it out, see what it does.
With that and capturing/writing two pixels in one go as you suggested it might match the speed of the 'drop 3 pixels' downscaler Pickle used. That'd be quite awesome indeed!
Even though I thought this was the last update I could do (who am I kidding, been there before with v0), I've already found out some other things. I've verified 256 color mode working fine without any 16 bit conversion afterwards (SDL does this internally it appears, 8 bit is not supported on the hardware for sure). I do need to trace down a few more menu and image color table change calls to get those displayed right, but otherwise the game runs fine - albeit ugly and I'd still have to write some source 8 to 16, scale to temp with box scaler, convert to 8 and move to destination, blit with correct color table thing to keep the terminals which require this to be even remotely readable... well, readable. Perhaps the 16 bit to something else mapping like you suggested isn't such a bad idea after all.
I've also managed to hook something to the overhead map code, so I've reassigned L and R to 'zoom in/out' when the map is active on the screen. They'll revert back to whatever they're assigned to when not viewing the map. That means all vital game buttons are mapped and mapped correctly now