Accessibility in source ports

For Hexen, there's an obvious thing to address: the earthquake effect.

I think GZDoom already has an option to reduce its visual amplitude or even turn it completely off.

23 minutes ago, Julia Nechaevskaya said:

In fact, it's simply increases overall brightness of the level, making everything looks more clear.

implemented. there are two modes: force uniform brightness to the full map, or add some lighting to map light levels.

also, i implemented two other features:

RGB swap (i read that it may help colorbling people to distinguish colors; of course, colors will be distorted, but it is better than nothing, i guess):

and emulation of various colorblindness kinds:

i found color matrices for those modes in teh internets, hope they're at least partially right.

p.s.: also, added a configurable light level for fullbright sprites.

13 minutes ago, ketmar said:

implemented. there are two modes: force uniform brightness to the full map, or add some lighting to map light levels.

 

also, i implemented two other features:

 

RGB swap (i read that it may help colorbling people to distinguish colors; of course, colors will be distorted, but it is better than nothing, i guess):

  Reveal hidden contents

 

and emulation of various colorblindness kinds:

  Hide contents

i found color matrices for those modes in teh internets, hope they're at least partially right.

 

p.s.: also, added a configurable light level for fullbright sprites.

you should watch this video he touches in a very interesting point that many games have color blind simulations and not modes so when he plays the colors still look wrong

maybe you wanna ask for feedback from people who are colorblind but this is already a start

im really liking what this thread has done in such a short amount of time im hoping this becomes the standard in the future

53 minutes ago, printz said:

Fullbright rendering all the time has a lot more contrast than middle light. I think light levels 128-160 are a lot more relaxing.

hm… why not? ;-)

k8vavoom is quickly becoming my new favorite source port :)

15 minutes ago, omalefico32x said:

you should watch this video he touches in a very interesting point that many games have color blind simulations and not modes so when he plays the colors still look wrong

yep, the colors will look wrong when swapped, there's not much i can do with that — i cannot draw new assets for all textures out there. ;-) but it may help to distinguish them, and you can switch it on the fly. it is possible to bind it to hotkey, for example, to temporaroly swap RGB channels, so one can do it to check various color marks, for example.

17 minutes ago, omalefico32x said:

maybe you wanna ask for feedback from people who are colorblind but this is already a start

sure, if such people will come here and toss in their ideas, it will be great. not everything can be implemented, but we'll try our best.

1 hour ago, Gez said:

For Hexen, there's an obvious thing to address: the earthquake effect.

sure: ;-)

17 minutes ago, ketmar said:

yep, the colors will look wrong when swapped, there's not much i can do with that — i cannot draw new assets for all textures out there. ;-) but it may help to distinguish them, and you can switch it on the fly. it is possible to bind it to hotkey, for example, to temporaroly swap RGB channels, so one can do it to check various color marks, for example.

 

sure, if such people will come here and toss in their ideas, it will be great. not everything can be implemented, but we'll try our best.

Maybe have three options for the differences in colour blindness? 
 

1. Deuteranopia

2. Tritanopia
3. Monochromacy
 

Then let users choose depending on which they have?  I experimented with monochrome but with Pooch's low resolutions it was nigh-on unreadable.

7 minutes ago, Gibbon said:

Maybe have three options for the differences in colour blindness?

as i don't have it, i cannot judge what is better for what. that's where we need help from tech-savvy colorblind people, i believe. at least I need. they prolly have some insights, or maybe even color transformation formulas. i can apply those without problems, but i need help defining them.

10 minutes ago, ketmar said:

as i don't have it, i cannot judge what is better for what. that's where we need help from tech-savvy colorblind people, i believe. at least I need. they prolly have some insights, or maybe even color transformation formulas. i can apply those without problems, but i need help defining them.

I'll have a go at experimenting but yeah, it is likely better to have someone who can test it and provide insights.  The last two are quite rare apparently so we really only need someone who cannot see red.

Edit: I could ask on reddit for someone to play doom shareware and help us come up with a palette?  Worth a shot..

10 minutes ago, ketmar said:

as i don't have it, i cannot judge what is better for what. that's where we need help from tech-savvy colorblind people, i believe. at least I need. they prolly have some insights, or maybe even color transformation formulas. i can apply those without problems, but i need help defining them.

options to change the hud numbers to any color you want would already go a long way to helping people

3 minutes ago, omalefico32x said:

options to change the hud numbers to any color you want would already go a long way to helping people

hm. those numbers are textures, not font letters, i will need a new shader to recolor them on the fly. but i love the idea, will implement it, thank you!

On 8/1/2021 at 5:42 PM, Quasar said:

Caption support for sound effects is a higher level of support, for hearing impaired users. I think that's a great idea also, though obviously significantly more work than the stuff above and probably worth treating as its own whole project when implementing this kind of stuff. Maybe there's room here for shared BEX string mnemonics for captions or something of that sort?

i have an idea. what if we will use minecraft-like system at least for monster sounds? most monsters (even in mods) have their sounds defined like "SeeSound", "ActiveSound", etc. we can record those, and show things like:

<DoomImp, many, roaming, far
ZombieMan, some, attack, near>

etc.? not the best way, but again, at least something.

3 minutes ago, ketmar said:

i have an idea. what if we will use minecraft-like system at least for monster sounds? most monsters (even in mods) have their sounds defined like "SeeSound", "ActiveSound", etc. we can record those, and show things like:

<DoomImp, many, roaming, far
ZombieMan, some, attack, near>

etc.? not the best way, but again, at least something.

i think thats too much information on a single line remenber these need to be read quicly when in gameplay

i think having sounds on top of each other is the best way

<doomimp

<doomimp

doomimp>

zombieman>

fireball>

i feel something like this would be better in the long run

now that i think about a better way of telling distance is with arrows too

<<<=far

<<=near

<=next to you

so a far away imp would be

<<<doomimp

a close one would be

<<doomimp

and next to you

<doomimp

10 minutes ago, omalefico32x said:

i think thats too much information on a single line remenber these need to be read quicly when in gameplay

yeah, it is just a raw idea, and i tried to stuff as much info as possible there. not the best way to do it, i guess. ;-)

12 minutes ago, omalefico32x said:

i think having sounds on top of each other is the best way

yeah, but there can be ALOT of those in crowded maps. and have some info about monsters roaming far away may be useful too.

maybe there could be two such tables: one for nearby monsters, with color-coding (customizable, of course ;-) for different monster states. and one for distant sounds, in some different screen place, so the player can know what's going on around on a bigger scale.

i think i will try to implement something like this later (this time really slightly later, not with the speed of other features i did today ;-), and test in in real games, to see how it will work. if i'll do that, i will prolly make in configurable, and include it in public builds, so people may try different variants and see what's work for them best.

1 minute ago, ketmar said:

yeah, it is just a raw idea, and i tried to stuff as much info as possible there. not the best way to do it, i guess. ;-)

 

yeah, but there can be ALOT of those in crowded maps. and have some info about monsters roaming far away may be useful too.

 

maybe there could be two such tables: one for nearby monsters, with color-coding (customizable, of course ;-) for different monster states. and one for distant sounds, in some different screen place, so the player can know what's going on around on a bigger scale.

 

i think i will try to implement something like this later (this time really slightly later, not with the speed of other features i did today ;-), and test in in real games, to see how it will work. if i'll do that, i will prolly make in configurable, and include it in public builds, so people may try different variants and see what's work for them best.

yea i can totally see how in wads like sunlust this can be a huge mess

honestely you rock i dont even know how to do hello world in any language other then python seeing you doing all of this so fast is amazing

take your time : )

p.s.: k8vavoom already has "attack indicator" around the crosshair, that shows the direction and relative altitude of attacks. colors are hardcoded for now, but i will make them configurable. it is an experimental feature, and needs more polishing, but at least this is something people can try right now. ;-)

here (sorry for double-posting, i want others to be notified):

big bars are showing 2d direction. smaller bars will appear if the attacker (or attackers) are really below/above, closer to the crosshair means "below", further means "above". i am really used to it, it helps even to people without impaired hearing. ;-)

it registers several last attacks, so you can see more than one attacker there. useful when you're being attacked from the different sides.

15 hours ago, omalefico32x said:

options to change the hud numbers to any color you want would already go a long way to helping people

why not? ;-)

menu:

menu with active color picker:

FS HUD with some recolored numbers (two example colors, set in the menu above; green zero above health, and cyan secondary ammo):

I considered such issues about a year ago, and put some "features" into DoomLegacy.

- slow doors setting, which makes doors stay open longer

- can turn off screen flash on object pickup,  the status bar has a small box that blinks instead.

- has support for joystick, with many buttons, all mapped in the control menu.

- has support for xbox style controller, all buttons and joys are mapped in the control menu.

- can play without keyboard, using joystick or controller to control menus.  Cannot type savegame names, or port addresses though.

I considered adding a visual sound indication.  This would indicate sound direction visually, at the edges of the screen.

The difficulty would be sound volume and not intruding too much visual noise into the playing area.

The current visual damage indication gives only very slight directional information (player is moved by being hit, which is better directional indication than sound).

I had to write a tool that would be used by a color-blind co-worker.

Changing the colors was not necessary.  It was adequate that the colors could be distinguished in spite of not being able to distinguish red from green.

I tried several color changes, but decided on making the visual indication in two modes, using both color and symbol, so as to not degrade the other workers ability to use the tool.

Boxes were not just green or red, the green was bright, but the red was only medium brightness.

The ON box had a green dot (like a lamp), while the OFF box was empty.

I had tried another symbol, like an X for OFF, but he found that confusing.  Some toolsets of that time used an X as a check mark.

If I remember right, a red X (with wide bars) was used as an error indication.  Other symbols like a red box, were not distinctive enough for an error indication, there had to be a symbol.

Idea: visual sound directional oval

Each monster type would have a sound icon.   Words are too slow to read, you need a shape.

The shape that corresponds to a monster can be learned, just like a sound.  You know the spider-demon does not go around saying "Spider-Demon" as its sound.  It is a sound you have to learn to associate with a Spider-Demon.

This could be a stylized monster shaped icon, or it could be selectable from geometric shapes.

Common sounds would have simple common icons, the simpler the better.

A shot would be just a little bar.

The visual sound would be displayed on a directional oval, just above the status bar.

A monster to the right would have the sound icon displayed to right (the right of the oval).

A monster sound from behind, would be displayed just above the status bar (the bottom of the oval).

A monster sound from ahead, would be displayed higher, centered (the top of the oval).

Louder sounds would be displayed brighter, while faint sounds would be barely visible.

2 hours ago, wesleyjohnson said:

Words are too slow to read, you need a shape.

…and somehow force this into all existing DECORATE mods. ;-) ports with rich modding support don't have the luxury of fixed monster roster. actually, even vanilla-like ports have DeHackEd, which can change alot…

actor class name is the best approximation that doesn't need any changes to mods.

but hey, the more ways we'll try, the better! i don't mean to reject your idea, sure, go ahead. it's just hard for mod-supporting ports, and i'm not sure that shapes could be made properly distinguishable without making them too big. but i guess it's better be seen first, it's hard to judge without that.

11 minutes ago, ketmar said:

actor class name is the best approximation that doesn't need any changes to mods.

In DECORATE there's the "tag" property that has been adopted as a source of pretty names. You can see it used by mods like Target Spy. Generally the logic is something like "use tag if set, otherwise use class name". The same logic is used by editors, with the order being //$Title then Tag then class name.

10 minutes ago, Gez said:

In DECORATE there's the "tag" property that has been adopted as a source of pretty names.

sadly, it's not consistenly set too. but this basically what k8vavoom is doing to show current weapon name, yeah — tag if not empty, otherwise class name.

still, it may be useful to have a switch to use only class names. sometimes tags are too long, sometimes they contain some… strange things. but class names are short most of the time, and the player will stop reading them as words after some time anyway.

and i think we need some way to indicate at least monster size.

On 8/4/2021 at 6:26 PM, printz said:

That's the very point of the spectres, to not be seen. If they're only barely visible, they've done their job. If your sight contributes to making them harder to notice, great. They're not regular monsters. If they make you play more cautiously, great. Load a Dehacked patch that removes the fuzz effect if you want to see them.

If spectres are only meant to be barely visible, but the player's eyesight makes spectres impossible to see at all, then the effect becomes a detriment to gameplay by no fault of the player. The way to handle it would be an accessibility toggle, to either change the effect or disable it outright. We don't have to be precious about intended gameplay design here.

On the topic of accessibility for visibility, I want to point at a couple modern games with great accessibility features: The Last of Us - Part II and Ratchet & Clank - Rift Apart. (Links point to Sony detailing TLoU-P2's accessibility features, and an accessibility review of R&C:RA)

Both games feature a "High Contrast" mode, which allows for everything in the game to be given color tints based on what category of entity they are, eg: Enemies, Allies, Items, Hazards, the environment itself, etc. These colors are customizable to suit a player's preference - this also happens to aid color blindness, as color perception is subjective to the player.

Links to videos that these screenshots came from:

The Last of Us Part II: Accessibility Features - High Contrast Mode Comparison and Audio Cues

Ratchet & Clank: Rift Apart - Accessibility Review

I think this sort of visual feature would be a good fit for Doom ports. You could handle it by say, remapping color palettes for sprites and textures, or altering the way environments and lighting are displayed (eg: permanent light-visor lighting plus grayscale colors, or by disabling textures). Even a specialty-made graphics-replacement WAD could handle a good chunk of it, making it a vanilla-compatible option.

the first picture seems to have some posteffect with edge detection. but yeah, it looks doable.

not that you can simply skip texturing, tho:

;-)

but the idea is interesting. i have to think about it, thank you!

1 hour ago, ketmar said:

the first picture seems to have some posteffect with edge detection. but yeah, it looks doable. 

 

not that you can simply skip texturing, tho: 

Oh yeah like, I mean in a similar vein, rather than 1:1 identical.

And ah, well lol. Maybe with some additional tinting for floors and walls (based on facing direction, etc), or by making textures fainter somehow so environments don't become entirely featureless, oops.

it is possible to desaturate the scene, and/or lower the contrast to keep some details, yeah. it needs some experimenting, of course (and is somewhat harder for palette-based ports).

anyway, it is a good food for thought.