Trap candidate: target-state-persists
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- c
- Domain
- testing-qa
Research direction
First find a public SDL3 port, commit, or issue showing this target state persistence bug and post its code for confirmation. If accepted, read CONTRIBUTING.md’s “Adding a trap” instructions and copy linear-by-default in the SDL3 porter references; add fixtures and verify CI against SDL 3.2.0 and 3.4.18 on Windows, Linux, and macOS. Done means CI passes and the candidate is removed from the README list; the maintainer runs the eval.
Written by the indexing model from the issue text.
Description
What changed: The viewport, clipping state and scale of each render target now persist and stay set whenever that target is active. SDL2 code that relied on switching targets to reset them keeps the old state. (migration guide)
Why it's a candidate: it compiles cleanly and can be proven headless, but no port has shown it in real code yet. It becomes a trap, with fixtures and an eval case, when a port or an issue shows it. If your SDL3 port ran into it, comment with the code.
Taking it on: first comment with the real code that shows it: a public SDL3 port, commit or issue where it caused a bug. Once I confirm it qualifies, follow "Adding a trap" in CONTRIBUTING.md and copy linear-by-default, which draws and reads pixels back with SDL_RenderReadPixels. The card goes in plugins/sdl3-porter/skills/sdl3-porter/references/render.md. The fixtures have to pass CI on Windows, Linux and macOS against SDL 3.2.0 and 3.4.18, and the PR removes the id from the README's list of candidates. I run the eval case myself, because evals use a repository secret.
- Dominant language
- C
- Stars
- 1
- Forks
- 1
- Avg merge
- 3m
- Merged PRs (30d)
- 1
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
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 hazeliscoding/sdl3-porter
-
trap-cards check: require every part of a trap cardPossibly taken A pull request linked to this issue is open or already merged. Openenhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
hazeliscoding/sdl3-porter#20 ·
-
documentation good first issue
Difficulty 1/5 1-3 hours Newbie friendliness 83/100
hazeliscoding/sdl3-porter#19 ·
-
Test find_traps.py's search of the committed SDL2 codePossibly taken @ian0318git claimed this 1 day ago. Opengood first issue
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
hazeliscoding/sdl3-porter#18 ·
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
hazeliscoding/sdl3-porter#17 ·
-
trap-cards check: require a sample and an eval case for every trapPossibly taken A pull request linked to this issue is open or already merged. Openenhancement good first issue
Difficulty 3/5 1-2 days Newbie friendliness 82/100
hazeliscoding/sdl3-porter#21 ·
All issues in hazeliscoding/sdl3-porter
Similar issues
-
TLS: a stale OpenSSL error makes non-blocking reads fail with "Resource temporarily unavailable"Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
bigtreetech/BIGTREETECH-TouchScreenFirmware#3056 ·
Maintainers usually reply within 1 day
-
Allow pillow 13Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
[pico][astrocade] emu/apply.sh edits src/mame/midway/astrohome.cpp, which current MAME has in bally/Open
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
FujiNetWIFI/fujinet-firmware#2120 ·
Maintainers usually reply within 1 day