A decent number of people suffer from being colorblind and as a result a lot of games are considerably harder or even impossible to play unless the devs specifically go out of their way to include colorblind modes.
My suggestion is to have toggles in the editor that lets the developer see what their game looks like if they had deuteranomaly, protanomaly, or tritanomly. It'll help the devs who want to create color blind modes by letting them see what those users would see.
I have no idea how this just submitted while I was still typing the freaking title.
Okay, fixed. I think.
Related to #15944.
I think someone just watched the last GMTK video ;)
I don't know if it is necessary as part of the engine, but it may be a great plugin for the library!
Probably a rectangle with preconfigured shaders?
The shaders to simulate these isn't at all complex (making the burden of maintaining them very small), but I definitely think it should be included by default to encourage devs to consider colorblind users and how their game looks to them.
And yes, Mark Brown was definitely the inspiration!
I remember Juan saying he didn't want to bloat the editor. But I do agree with you, it is a major concern. Would it be considered as bloating? I don't know...
Anyway, either a plugin or an integrated option, here is the algorithm used by many tools online that I have encountered. 6 years ago I might have been able to understand everything but I haven't practiced mathematics since 2012 ;)
I leave the link here if someone wants to tackle with this issue: http://vision.psychol.cam.ac.uk/jdmollon/papers/colourmaps.pdf
Alright, I have studied more deeply the algorithms (it is not that hard actually).
The link (a.) (links below) I have provided in my earlier post is correct, but only treats Protanopia and Deuteranopia. I would have to make more calculus for the Tritanopia. It is not impossible, but tricky. As mentioned here (b.), some algorithms that can be found online are wrong due to the misuse of initial hypothesis from (a.). I will not explain everything here, because (b.) does it better than me.
So, I think it is good to use the algorithm from (b.)
I will summarize it here, but I suggest you visit the link (b.), which is really interesting.
For each pixel of color [R, G, B] (R, G and B in the interval [0,1]), we want to calculate the colorblind equivalent depending on the pathology :
Calculate the filtered color depending on the color blindness type :
Reapply the gamma correction to get the final value [Rp,Gp,Bp] :
Sources:
(a.) http://vision.psychol.cam.ac.uk/jdmollon/papers/colourmaps.pdf
(b.) https://ixora.io/projects/colorblindness/color-blindness-simulation-research/
Just leaving a note here, that there is the scribus.net opensource program that implements it, maybe ppl can take a look how they implement the shader.
Anyways, if possible, I wold like to have this godot.
I guess @paulloz was inspired by the same source: https://github.com/paulloz/godot-colorblindness
Ha ha! This is going so fast!
@paulloz , I think you forgot to remove the gamma correction. You are working with the RGB profile instead of the sRGB profile.
Haha yeah, I wanted to make something like this for a long time as I often struggle with some color choices in games I play. Mark's video was some kind of a reminder: now that I somehow know how to write a shader, I could finally do that.
I looked for other assets in the library doing this kind of thing and didn't find any. But I didn't think of looking at issues down here. I'm glad other persons think this is important.
I'm currently implementing achromatopsia and will probably add some kind of strength parameter to be able to simulate more common types of colorblindness (e.g. deuteranomaly).
@MattUV IINW I approximate linear space here. I'll have a look at your calculation and see if there's any major difference between the two. Thanks!
Cheers all 鉂わ笍.
Edit (an hour later): @MattUV indeed your formula for gamma correction handles dark tones a little better. Beware though, one of your values for RGB -> sRGB is off by a factor of ten :V
I see you're hardcoding the gamme corrections. Is there currently no way to change the gamma value in the engine?
Looking towards the future, I think it would be best to change the gamma computation here so that it works with different gammas.
Is there currently no way to change the gamma value in the engine?
As far as I know, no. It's possible to perform some adjustments and color correction in 3D using a WorldEnvironment node, but it only affects 3D rendering.
@Calinou environment in Canvas mode makes effects to affect 2D too (including tonemap, glow, color adjustment).
I think that the issue of contributing bloat is offset by how small colorblind shaders can be as well as the benefit of making developing for the disabled easier in Godot.
Even if we ignore all the current issues with the asset library, having this as a plugin greatly diminishes the usefulness of it simply because it's something most people don't consider. Having it in editor and easily discoverable will make it much, much more likely that devs will use the tool and develop for the colorblind.
Trust me, it's (sadly) not something most people will consider whether this is part of the engine or not. It's often not considered even if I'm right in front of the developers in a convention saying that their colour choices aren't right.
This issue will only be dealt with through educational content, whether tools are available within the engine or as external resources.
@paulloz - I wouldn't say so. @Two-Tone is right that having it in the engine increases discoverability and thus, raises awareness that this issue even exists. I would argue that many game developers do not even think about something like color blindness. Having an option for a color blindness might be enough to get somebody to look into it. So I would strongly suggest putting it in the engine, even if its just to have feature parity with the Unreal Engine.
Ported this over to https://github.com/godotengine/godot-proposals/issues/473, closing here.
Most helpful comment
I think that the issue of contributing bloat is offset by how small colorblind shaders can be as well as the benefit of making developing for the disabled easier in Godot.
Even if we ignore all the current issues with the asset library, having this as a plugin greatly diminishes the usefulness of it simply because it's something most people don't consider. Having it in editor and easily discoverable will make it much, much more likely that devs will use the tool and develop for the colorblind.