Create documentation for Turbo Fire (suggested documentation added)
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 45/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Stale
- Domain
- documentation
Research direction
Start with the Turbo Fire settings path in RetroArch and the source-code comments included in the issue. Document the intended behavior of Turbo Fire, Turbo Modes, and Turbo Default Button, including how the listed modes respond to pressing or holding the turbo button; done means users can understand and use these settings.
Written by the indexing model from the issue text.
Description
Documents
Do not currently exist
Proposed changes
Documentation for usage of Turbo Fire function should be created. RetroArch>Settings>Input>Turbo Fire. I can't seem to get the Turbo Fire to work, but I'm not sure I'm using it correctly or understand it's intended function due to the lack of documentation. Description of the general intended function of the Turbo Fire, Turbo Modes, and Turbo Default Button would be much appreciated. There seems to be a lot of confusion in the community about how Turbo Fire is intended to work.
The most info I was able to find are some comments in the source code (see below).
if (turbo_mode > INPUT_TURBO_MODE_CLASSIC)
{
/* Pressing turbo button toggles turbo mode on or off.
* Holding the button will
* pass through, else the pressed state will be modulated by a
* periodic pulse defined by the configured duty cycle.
else if (turbo_mode == INPUT_TURBO_MODE_SINGLEBUTTON_HOLD &&
/* If turbo button is held, all buttons pressed except
* for D-pad will go into a turbo mode. Until the button is
* released again, the input state will be modulated by a
* periodic pulse defined by the configured duty cycle.
- Dominant language
- TeX
- Stars
- 346
- Forks
- 860
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 10
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from libretro/docs
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
libretro/docs#1195 · 4 comments ·
Maintainers usually reply within 3 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 3 days
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 3 days
-
Difficulty 1/5 Under an hour Newbie friendliness 65/100
Maintainers usually reply within 3 days
-
bug
Difficulty 1/5 1-3 hours Newbie friendliness 65/100
libretro/docs#960 · 3 comments ·
Maintainers usually reply within 3 days
Similar issues
-
docs pydanty:is-working
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
pydantic/pydantic-ai#8863 ·
Maintainers usually reply within 1 day
-
documentation from-review-extraction github-actions priority: low severity:nit
Difficulty 1/5 Under an hour Newbie friendliness 92/100
LearningCircuit/local-deep-research#6946 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 1/5 Under an hour Newbie friendliness 88/100
esphome/device-builder#2856 ·
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
Difficulty 1/5 1-3 hours Newbie friendliness 78/100
mantinedev/mantine#9223 ·
Maintainers usually reply within 6 days