summaryrefslogtreecommitdiff
path: root/src/libs/ray
diff options
context:
space:
mode:
authorVito Caputo <vcaputo@pengaru.com>2022-04-27 13:46:04 -0700
committerVito Caputo <vcaputo@pengaru.com>2022-04-27 13:46:04 -0700
commitc881616cfbbd8c20d67f469d363254b2c56a12b7 (patch)
treee3366155b36d06bf49441746d98912988f6ad9c6 /src/libs/ray
parent0f16aad8e0f51b8259b9a8c0a5bac26fcf8b3ef5 (diff)
til_fb: til_fb_fragment_t.{pitch,stride} uint32_t units
Originally it seemed sensible to make these units of bytes, for flexibility reasons. But it's advantageous for everything to be able to assume pixels are always 4-byte/32-bit aligned. Having the stride/pitch be in bytes of units made it theoretically possible to produce unaligned rows of pixels, which would break that assumption. I don't think anything was ever actually producing such things, and I've added some asserts to the {sdl,drm}_fb.c page acquisition code to go fatal on such pages. This change required going through all the modules and get rid of their uint32_t vs. void* dances and other such 1-byte vs. 4-byte scaling arithmetic. Code is simpler now, and probably faster in some cases. And now allows future work to just assume things cna always occur 4-bytes at a time without concern for unaligned accesses.
Diffstat (limited to 'src/libs/ray')
-rw-r--r--src/libs/ray/ray_render.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/libs/ray/ray_render.c b/src/libs/ray/ray_render.c
index 535b71a..9b36e6c 100644
--- a/src/libs/ray/ray_render.c
+++ b/src/libs/ray/ray_render.c
@@ -213,7 +213,7 @@ void ray_render_trace_fragment(ray_render_t *render, til_fb_fragment_t *fb_fragm
buf++;
} while (ray_camera_fragment_x_step(&fragment));
- buf = ((void *)buf) + fb_fragment->stride;
+ buf += fb_fragment->stride;
} while (ray_camera_fragment_y_step(&fragment));
}
© All Rights Reserved