Conversation
* All TrueColor code is guarded by #ifdef CRISPY_TRUECOLOR. * Extra line breaks before some subheaders no longer used to get some extra vertical space and primary to fit everything on first Crispness page.
fabiangreffrath
left a comment
There was a problem hiding this comment.
Looks good, thank you!
|
Before we'll merge this: I'm afraid we have bumped into a small misunderstanding about this switch with @rfomin. While my idea was to have just an in-game switch between paletted/truecolor views (not renderers), and that's what it do now, Roman was meaning full toggling. But as already known, full toggling is a long and different story. Aside from possible turning Another approach is to always have a TrueColor mode, but make it friendly with custom palette tints and take care about expensive translucency. In this case, only running on 16-bit and below display modes will not be possible. Really no idea which way is better. First one is an absolute full mile and have to be more correct in technical terms, second one is probably simpler and shorter. So, for now this PR doesn't do much, except adds some vertical space for Crispness menu. |
|
I think that's understood. It remains full truecolor rendering under the hood, but merely emulates paletted rendering by loading colormaps from the COLORMAP lump instead of fading RGB values to black. Translucency performance and custom palette issues still remain. |
|
Yes, absolutely. You know this better than anyone, I know this after months of working with TrueColor code. But Roman wasn't working with TrueColor previously. 🙂 Still, should be merge this PR then? And what is your recommendation for farther compatibility support, i.e. which way we should move? |
Yes, my idea was full toggling and remove the separate true color build. I think the current implementation of the toggle is not very useful. |
This adds simple ingame toggler for "TrueColor Rendering". Few remarks:
PLAYPALtinting effects.