Public `bj_renderer_pixel_mode` accessor #111

New issue

Open

opened 2026-05-29 07:23:16 +02:00 by OragonEfreet · 0 comments

OragonEfreet commented

2026-05-29 07:23:16 +02:00

Owner

Context

After #107 lands, examples that need to precompute colours at setup time can't reach the renderer's framebuffer (it's only accessible from inside the draw callback). Three examples — physics_kinematics.c, physics_particle.c, random_distribution.c — work around this by hardcoding the renderer's pixel mode:

#define FB_PIXEL_MODE  BJ_PIXEL_MODE_XRGB8888
...
balls[at].color = bj_get_pixel_value(FB_PIXEL_MODE, r, g, b);

This works today because all software renderers use XRGB8888. It breaks the day banjo ships a non-XRGB renderer (RGB565 for embedded, anything new the renderer abstraction is supposed to enable). The hardcode is a tax the type system should be paying for us.

Outcome

A public accessor on bj_renderer:

BANJO_EXPORT enum bj_pixel_mode bj_renderer_pixel_mode(
    const struct bj_renderer* renderer
);

Returns the pixel mode of the renderer's framebuffer (the one a bj_render_target_bitmap inside the draw callback would yield). NULL renderer returns whatever sentinel is most useful (zero or a dedicated BJ_PIXEL_MODE_UNKNOWN).

Three example migrations to follow:

physics_kinematics.c — drop the FB_PIXEL_MODE define; use the accessor in reset_ball.
physics_particle.c — same drop; use the accessor in init_asteroids and initialize.
random_distribution.c — same drop; use the accessor in init_distributions.

After this the only remaining hardcoded-pixel-mode in examples is the one inside the on_draw helper for things like bj_set_bitmap_color(fb, bj_make_bitmap_pixel(fb, 22, 26, 32), BJ_BITMAP_CLEAR_COLOR) — those are fine, the framebuffer is in scope.

Depends on

#107 (draw-callback model). The accessor only matters once examples can't reach the framebuffer at setup.

Out of scope

GL / Vk render targets — no software pixel mode applies. The accessor returns the sentinel for those.
bj_bitmap_pixel_mode introspection — already public.

## Context After #107 lands, examples that need to precompute colours at setup time can't reach the renderer's framebuffer (it's only accessible from inside the draw callback). Three examples — `physics_kinematics.c`, `physics_particle.c`, `random_distribution.c` — work around this by hardcoding the renderer's pixel mode: ```c #define FB_PIXEL_MODE BJ_PIXEL_MODE_XRGB8888 ... balls[at].color = bj_get_pixel_value(FB_PIXEL_MODE, r, g, b); ``` This works today because all software renderers use XRGB8888. It **breaks the day banjo ships a non-XRGB renderer** (RGB565 for embedded, anything new the renderer abstraction is supposed to enable). The hardcode is a tax the type system should be paying for us. ## Outcome A public accessor on `bj_renderer`: ```c BANJO_EXPORT enum bj_pixel_mode bj_renderer_pixel_mode( const struct bj_renderer* renderer ); ``` Returns the pixel mode of the renderer's framebuffer (the one a `bj_render_target_bitmap` inside the draw callback would yield). NULL renderer returns whatever sentinel is most useful (zero or a dedicated `BJ_PIXEL_MODE_UNKNOWN`). Three example migrations to follow: - `physics_kinematics.c` — drop the `FB_PIXEL_MODE` define; use the accessor in `reset_ball`. - `physics_particle.c` — same drop; use the accessor in `init_asteroids` and `initialize`. - `random_distribution.c` — same drop; use the accessor in `init_distributions`. After this the only remaining hardcoded-pixel-mode in examples is the one inside the on_draw helper for things like `bj_set_bitmap_color(fb, bj_make_bitmap_pixel(fb, 22, 26, 32), BJ_BITMAP_CLEAR_COLOR)` — those are fine, the framebuffer is in scope. ## Depends on - #107 (draw-callback model). The accessor only matters once examples can't reach the framebuffer at setup. ## Out of scope - GL / Vk render targets — no software pixel mode applies. The accessor returns the sentinel for those. - `bj_bitmap_pixel_mode` introspection — already public.

OragonEfreet added this to the 1.0 milestone

2026-05-29 07:23:16 +02:00

OragonEfreet added the

enhancement

label

2026-05-29 07:23:16 +02:00

OragonEfreet added this to the 70's games readinesss project

2026-05-29 09:13:01 +02:00

OragonEfreet removed this from the 1.0 milestone

2026-05-29 18:28:35 +02:00

OragonEfreet removed this from the 70's games readinesss project

2026-05-29 20:04:51 +02:00