test_bed #130

Merged

OragonEfreet merged 4 commits from test_bed into main 2026-06-02 09:46:36 +02:00

Conversation 0 Commits 4 Files changed 4 +30 -5

OragonEfreet commented 2026-06-01 18:00:06 +02:00

Owner

Copy link

No description provided.

OragonEfreet added 3 commits 2026-06-01 18:00:06 +02:00

fix(bitmap): preserve glyph atlas across bj_assign_bitmap ... 7c9c5b67c6

Backends double-buffer by calling bj_assign_bitmap() on the window framebuffer every frame (e.g. the Wayland swap pair). bj_reset_bitmap freed bitmap->charset and bj_init_bitmap zeroed it, so the cached Latin-1 8bpp glyph atlas was wiped on every swap and rebuilt by the next text draw (~once per frame: 341 rebuilds over 352 frames in a text-rendering game).

The atlas depends only on the font, not on the pixel buffer/size/mode, so detach it before reset+init and restore it after. The destroy path still frees charset via bj_reset_bitmap, so nothing leaks. Verified: atlas built 1x instead of 341x; ctest 31/31 pass.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

fix(draw): avoid UB left-shift of negative in circle rasterizers ... 032b70c0f0

bj_draw_circle and bj_draw_filled_circle update the midpoint error term with ((y - x) << 1). In the algorithm y - x is negative for most of the loop (UBSan: 'left shift of negative value -5' at bitmap_draw.c:478, hit by a radius-10 bj_draw_filled_circle). Left-shifting a negative signed value is undefined behavior in C.

Use signed multiplication (y - x) * 2 instead; compilers lower it to the same shift for non-negative operands. Verified with UBSan (clean) and ctest 31/31.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs(shader): fix inverted return-value contract for bj_bitmap_shading_fn ... 64e0c02f9b

The doc said 'return 1 on success, non-zero if the pixel should be skipped' -- self-contradictory (1 is non-zero) and inverted. bj_shader_bitmap (src/shader.c) writes the pixel only when the callback returns > 0, and examples/shaders.c returns 1 to write. Following the old text (return 0 for success) would render nothing. Document the actual contract: >0 writes, 0 skips.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

OragonEfreet added 1 commit 2026-06-02 04:29:57 +02:00

fix(wayland): treat KEY_STATE_REPEATED as held, not a release ... ade0cb1166

wl_keyboard v10 added WL_KEYBOARD_KEY_STATE_REPEATED (2). banjo binds wl_seat at the compositor's advertised version, so modern compositors (mutter/GNOME) deliver auto-repeat as key events with state=2. keyboard_handle_key did 'action = (state == 1) ? BJ_PRESS : BJ_RELEASE', mapping REPEATED to a spurious RELEASE -- so every held key released itself at the ~500ms repeat delay (confirmed via keyprobe: PRESS at t=1.238, phantom RELEASE at t=1.744 while held). Held-key input was broken on all modern Wayland; X11 was unaffected (autorepeat peek).

Map RELEASED->BJ_RELEASE and PRESSED/REPEATED->BJ_PRESS. A repeat passed as BJ_PRESS is ignored while already held (keystate stays PRESS) or becomes BJ_REPEAT under BJ_WINDOW_FLAG_KEY_REPEAT. Self-test + ctest 31/31 green.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

OragonEfreet force-pushed test_bed from ade0cb1166 to 6270e40024 2026-06-02 09:45:18 +02:00 Compare

OragonEfreet merged commit 6270e40024 into main 2026-06-02 09:46:36 +02:00

OragonEfreet deleted branch test_bed 2026-06-02 09:46:36 +02:00

OragonEfreet added this to the 1.0 milestone 2026-06-04 19:46:07 +02:00

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

bug

Something is not working

  

duplicate

This issue or pull request already exists

  

enhancement

New feature

  

help wanted

Need some help

  

invalid

Something is wrong

  

question

More information is needed

  

wontfix

This won't be fixed

No labels

bug

duplicate

enhancement

help wanted

invalid

question

wontfix

Milestone

Clear milestone

No items

No milestone

1.0

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

OragonEfreet/banjo!130

No description provided.