Accessibility in source ports

[Gez]

From PsyDoom thread:

On lundi 26 juillet 2021 at 3:06 PM, Quasar said:

As source port devs I think we need to start taking accessibility more seriously - having an option to disable flashing light and palette effects would go a long way toward this.

 

From Pooch thread:

On jeudi 29 juillet 2021 at 12:27 PM, Gibbon said:

A separate binary was chosen for accessibility users, so that a menu item that does not appear in MBF does not have to be added for toggling on/off (to keep it historically accurate) and also, so those who cannot tolerate such effects don't have to do any configuration, the binary is safe 'as-is'.

 

And see also this mod thread on the ZDoom forums:

 

 

So this is a thread to discuss implementation of accessibility features in source ports. What can be done, how far can we go, how to solve specific issues, etc.

[Gibbon]

Love it, thats fantastic!  Would be nicer for the ZDoom devs to officially support it though.

 

For Pooch, wrapping up the lighting effects took about 5 minutes.  Removing the chaingun sprite took about 15.  I did experiment with having SDL2 render in greyscale for colourblind users but it really was not playable (low resolutions kill readability).

Edited August 1, 2021 by Gibbon

[printz]

Don't we have deaf users in the community? Even active mappers. Could see what they'd like Doom to have to accommodate them.

[Gibbon]

Also Dyslexic users too would be good to get feedback from, text colours are the easiest things to change.

[omx32x]

2 hours ago, printz said:

Don't we have deaf users in the community? Even active mappers. Could see what they'd like Doom to have to accommodate them.

it would be nice but i have been playing doom mostly without audio for a long time and you kinda get to learn to play without audio clues

i would like if a source port had something similar to minecraft captions mode where it tells you if there is a sound and if it is coming from the left or right

this would be great

 

also for any one reading this that is working in a mod carefull with the chaingun making it faster is fun but it is also a brick wall for anyone who is sensitive to flashing lights i know people who cant play wads that make it faster because of it

[Jayextee]

As someone who only recently has had any accessibility requirements, I have but one request: fully-remappable gamepad support in your sourceports please.

I injured my right hand recently and literally can't use a mouse with it, which means good old kb/m is just pain for me -- I'm using an old XBox 360 controller, and it's fine in Windows 10 in general.

GZDoom supports it nicely, but it isn't incredibly remappable. (It will do for now though, and is why GZD has become my port of choice lately)
Chocolate Doom claims to support it but seemingly won't detect it though; no idea if this is specific to this controller, but I had to make a JoyToKey profile for it. Not ideal.

[Gez]

1 hour ago, Jayextee said:

GZDoom supports it nicely, but it isn't incredibly remappable.

What keys or buttons aren't remappable?

[Quasar]

I think the bare minimum have been mentioned already, which from my point of view are:

 

• Flashing light effects toggle (disable sector light strobing, weapon fire flashes - separately or together as an implementation choice I guess)
• Palette swap/colormap disable - some people are particularly bothered by things like the bonus item flash or the invulnerability colormap
• Ability to configure text colors and background (if any) for the UI (Eternity has this already, got it from BOOM).
• Ensuring all functions can be accessed with multiple input devices and without assumptions such as "the mouse is on the right of the keyboard" or "gamepad is strictly exclusive of mouse/keyboard use" just as examples. I think most ports get this down pat already.
• Ability to disable screen shake effects such as Hexen earthquakes
• Ability to disable forced FOV changes

 

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? Perhaps a loadable strings database with standard captions? Otherwise it's likely to be "every port for itself" and the result will not likely be modding friendly.

 

I've always been curious how far you'd have to go to make Doom playable by people with significant vision impairment or even blindness but I remain skeptical that it would be practical without heavily modifying the game itself to have certain mechanics, for example an ability to detect a ledge before you fall off it, or a means to get back up before you fall off it (think Link grabbing the edge and pulling himself back up in the 3D Zelda games). A big part of it I think would be auditory feedback for materials in-game as that is one thing that led to Zelda: Ocarina of Time being beatable by a blind guy - you can hear what you're walking on, you can "sound out" walls with your sword, etc. Doom doesn't have anything like that by default but could do it with modding. This is probably just out of reach of anything other than a dedicated source port plus mod but it'd be fun to see somebody in the community take it up as a challenge.

Edited August 1, 2021 by Quasar

[Jayextee]

1 hour ago, Gez said:

What keys or buttons aren't remappable?

Literally any face buttons; although I'm using 4.5.0 (I don't keep super up-to-date with versions) so this could've changed since? But what I'm looking at here is just the stick axes and triggers remappable.

Also, what would be nice is POV hat/d-pad diagonals able to have separate remaps to the cardinals for a full weapon wheel. That would be the best.

[Biz!]

This will open a way for more people to play doom! It sounds like a good idea!

[printz]

3 hours ago, 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?

Perhaps the easiest solution for users who can't or don't want to hear sounds (i.e. any situation of not hearing sounds) is to draw the stereo sound waves, or Fourier transforms of them so they can see the frequencies. They might eventually learn to distinguish the patterns visually. It might be possible already with a third-party software or hardware anyway.

 

3 hours ago, Quasar said:

I've always been curious how far you'd have to go to make Doom playable by people with significant vision impairment or even blindness

Maybe haptics will work when you bump into a wall or sprite? It would probably need to be spatial, and I don't know how practical that is. Wolfenstein 3D had the neat effect of playing noise when rubbing against a wall or obstacle. Also the player needs to know when they're about to fall off ledges (and that isn't covered by Wolf).

 

Edited August 1, 2021 by printz

[fabian]

Some of this isn't as trivial to implement as it might seem, especially if you take demo compatiblity into account. Take for example T_LightFlash() in p_lights.c:

void T_LightFlash (lightflash_t* flash)
{
    if (--flash->count)
	return;
	
    if (flash->sector->lightlevel == flash->maxlight)
    {
	flash-> sector->lightlevel = flash->minlight;
	flash->count = (P_Random()&flash->mintime)+1;
    }
    else
    {
	flash-> sector->lightlevel = flash->maxlight;
	flash->count = (P_Random()&flash->maxtime)+1;
    }
}

This function calls P_Random() to determine how long a certain lightlevel is meant to be kept and at the same time returns if count becomes zero after decrementing, which in turn affects when the next call to P_Random() happens. Thus, we must actually change the sector's lightlevel in order to keep this sequence intact. Or am I missing something?

Edited August 3, 2021 by fabian

[Gez]

10 minutes ago, fabian said:

Thus, we must actually change the sector's lightlevel in order to keep this sequence intact. Or am I missing something?

Let's create a new function, that would look something like this:

void setAccessibleLightLevel(sector_t * sector, int level)
{
	if (!accessibility_strobe) // this is a new global option variable, when true it disables flashes
		sector->lightlevel = level;
}

Then your T_LightFlash becomes:

void T_LightFlash (lightflash_t* flash)
{
    if (--flash->count)
	return;
	
    if (flash->sector->lightlevel == flash->maxlight)
    {
	setAccessibleLightLevel(flash->sector, flash->minlight);
	flash->count = (P_Random()&flash->mintime)+1;
    }
    else
    {
	setAccessibleLightLevel(flash->sector, flash->maxlight);
	flash->count = (P_Random()&flash->maxtime)+1;
    }
}

Calls to P_Random are maintained, but actual light changes are made conditional.

[fabian]

It's not that easy, unfortunately. If you decide not to change sector->lightlevel, then the check (flash->sector->lightlevel == flash->maxlight) will return wrong results, thus the value for flash->count will become wrong, thus P_Random() will be called at the wrong tic next time.

[ketmar]

`lightlevel` is `short`, right? but only the low byte is used. so you can abuse higher bits for your own purposes, i believe. for example, to save the original light level, or vice versa — use high byte as the actual light level (updating it on each light level change, unless it is disabled).

 

this may break some bad maps with out-of-range sector light, but such maps are broken anyway (and i am almost sure that map loader can sanitize them).

[Gez]

Either that or introduce a new variable in the sector struct, that holds the "logical" light level for compatibility reasons.

[fabian]

1 hour ago, Gez said:

Either that or introduce a new variable in the sector struct, that holds the "logical" light level for compatibility reasons.

 

@fraggle Would you accept such a solution for Choco?

[Kinsie]

On 8/2/2021 at 1:50 AM, Jayextee said:

Literally any face buttons; although I'm using 4.5.0 (I don't keep super up-to-date with versions) so this could've changed since? But what I'm looking at here is just the stick axes and triggers remappable.

You should be able to rebind them through the same Customize Controls menu you'd use for keyboard and mouse.

 

[Jayextee]

Just now, Kinsie said:

You should be able to rebind them through the same Customize Controls menu you'd use for keyboard and mouse.

 

Ohhhhh, here I was looking in the controller menu. Thanks!

[fraggle]

5 hours ago, fabian said:

 

@fraggle Would you accept such a solution for Choco?

I think it's extra complexity that doesn't belong in Choco (since it won't have the feature), although Gez's proposed solution sounds like the best one.

[MattFright]

I'd love if ports had more customizability on how Spectres are rendered (similar to GZDoom, but focused on accessibility than just slightly cosmetic changes) to make them easier to see on higher resolutions where the distortion effect isn't as obvious for those with any kind of impaired sight.

 

Related:

Edited August 3, 2021 by MattFright

[Gibbon]

10 hours ago, Gez said:

Let's create a new function, that would look something like this:

void setAccessibleLightLevel(sector_t * sector, int level)
{
	if (!accessibility_strobe) // this is a new global option variable, when true it disables flashes
		sector->lightlevel = level;
}

Then your T_LightFlash becomes:

void T_LightFlash (lightflash_t* flash)
{
    if (--flash->count)
	return;
	
    if (flash->sector->lightlevel == flash->maxlight)
    {
	setAccessibleLightLevel(flash->sector, flash->minlight);
	flash->count = (P_Random()&flash->mintime)+1;
    }
    else
    {
	setAccessibleLightLevel(flash->sector, flash->maxlight);
	flash->count = (P_Random()&flash->maxtime)+1;
    }
}

Calls to P_Random are maintained, but actual light changes are made conditional.

Why would you want to do something that complicated?  Pooch maintains demo compatibility without any issues and without such a complex implementation of 'faking' when lights are / are not there.

 

I tested it with countless demo's from 1994 until 2001, no problems at all.  Lights and effects do not display on those demo's but do on the standard binary.  No other issues are shown.  Nothing complex about it.

[Charlie Love]

Speaking of accessibility I suffer from pretty bad motion sickness in Doom unless I play with view bobbing turned off. Unfortunately, in most ports that allow you to disable view bob, weapon sway also gets disabled which is a bit boring to look at. I was successfully able to decouple weapon sway and view bob after looking into it so that they can be two separate toggles.

 

My commits from https://github.com/CharlesLove/from-doom-with-love/commit/f4d1c6ad655a397c63a17752852412b4a4bce469

to https://github.com/CharlesLove/from-doom-with-love/commit/26c25103f6cfb27738f382d0664754f9d0f03950 show how I did it with the prboom+um/dsda-doom codebase. Of note is https://github.com/CharlesLove/from-doom-with-love/commit/ef50b9adb4cc7e1c9d531c338cbcc13e14a1c769 where the bob variable is changed to 0 after pretty much every other viewbob based calculation is calculated to maintain the math that powers the sway code.

 

 

Edited August 3, 2021 by Charlie Love
More detail

[Gibbon]

5 minutes ago, Charlie Love said:

Speaking of accessibility I suffer from pretty bad motion sickness in Doom unless I play with view bobbing turned off. Unfortunately, in most ports that allow you to disable view bob, weapon sway also gets disabled which is a bit boring to look at. I was successfully able to decouple weapon sway and view bob after looking into it so that they can be two separate toggles.

 

My commits from https://github.com/CharlesLove/from-doom-with-love/commit/f4d1c6ad655a397c63a17752852412b4a4bce469

to https://github.com/CharlesLove/from-doom-with-love/commit/26c25103f6cfb27738f382d0664754f9d0f03950 show how I did it with the prboom+um/dsda-doom codebase.

 

 

This is a good idea.  I'll take a look and wrap it up into my ACCESSIBILITY macro.

[fabian]

10 hours ago, Gibbon said:

I tested it with countless demo's from 1994 until 2001, no problems at all.  Lights and effects do not display on those demo's but do on the standard binary.  No other issues are shown.  Nothing complex about it.

 

This only affects Vanilla demos, Boom and above maintain separate RNG indices per context and sector lighting is one of them. I don't know how much "countless" is, but I know that plain MBF is pretty much Vanilla demo incompatible - unless you apply a whole bunch of patches to fix this up.

[Gibbon]

39 minutes ago, fabian said:

 

This only affects Vanilla demos, Boom and above maintain separate RNG indices per context and sector lighting is one of them. I don't know how much "countless" is, but I know that plain MBF is pretty much Vanilla demo incompatible - unless you apply a whole bunch of patches to fix this up.

MBF is vanilla compatible, at least with the demo's I have tried (half of doom 2), straight from dosbox).  That is why my implementation essentially removed all lighting (empty void function calls).  There is nothing to be calculated and so it is ignored entirely.  Lighting is now dependent on which binary you use regardless of what demo you are viewing.

[rfomin]

8 minutes ago, Gibbon said:

MBF is vanilla compatible, at least with the demo's I have tried (half of doom 2), straight from dosbox)

I think Fabian has literally tested over 9000 demos from the Compet-n archive, so you can trust him with demos compatibility issues. I have tested almost the entire DSDA archive with Woof and the unmodified MBF is not a demo compatible with vanilla and Boom and PrBoom+ complevel 11.

[Gibbon]

37 minutes ago, rfomin said:

I think Fabian has literally tested over 9000 demos from the Compet-n archive, so you can trust him with demos compatibility issues. I have tested almost the entire DSDA archive with Woof and the unmodified MBF is not a demo compatible with vanilla and Boom and PrBoom+ complevel 11.

So how exactly do you define vanilla compatibility?  I'm not concerned with any demos with prboom (as I don't support any higher than mbf and boom) but if 1.9 demos work in vanilla dosbox and work the same in Pooch, then I class that as compatible.  Of course, compatibility with everything plus the kitchen sink would pose more issues with supporting them.

 

But still, if you make an accessibility binary separate from the main binary, demo compatibility would be null, I don't think users who will need accessibility binaries are concerned with watching demos.

Edited August 4, 2021 by Gibbon

[rfomin]

2 minutes ago, Gibbon said:

So how exactly do you define vanilla compatibility?

If you can run all known vanilla demos without desync. This is probably offtopic and concerns mainly speedrunners. Many ports don't care about demo compatibility.

[ketmar]

6 minutes ago, Gibbon said:

I don't think users who will need accessibility binaries are concerned with watching demos.

why? i bet they may want to watch demos too, and currently they have no way to do that with proper safety features.