RandyGaul
WIP: Drop cf apply mesh
This needs a refactor that introduces cf_render rather than cf_apply_shader.
Perhaps: cf_apply_canvas(canvas) cf_render(shader, material, mesh)
It still makes sense to have these two separated, as it’s common to render to the same canvas with different items (draw calls).
Annoyance: We already have render_ api in cute_draw.h so there’s a name clash, e.g. cf_render_to already exists. Maybe this new function could be named something else? cf_draw_elements might be a good name. People already tend to look for something named this anyways so it has some familiarity.
Another question is: What is the scope of states like scissor and viewport? Even in SDL_GPU, SDL_SetGPUScissor seems to imply that it affects the next draws onward until the pass is over but I haven't tested.
I don't really use viewport but scissor is how GUI libraries implement scrolling containers.
I know it’s a noob question, but what are scissors for? Is that for cropping some textures to only display parts of them?Sent from my iPhoneOn 15 Oct 2025, at 10:32, Bach Le @.***> wrote:bullno1 left a comment (RandyGaul/cute_framework#403) Another question is: What is the scope of states like scissor and viewport? Even in SDL_GPU, SDL_SetGPUScissor seems to imply that it affects the next draws onward until the pass is over but I haven't tested. I don't really use viewport but scissor is how GUI libraries implement scrolling containers.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
Scissor limits what area of the screen can be drawn to. Anything outside will be clipped. This is the best graphical explanation: https://gamedev.stackexchange.com/a/167051.
UI libraries tend to use it for scrolling elements because that's the most straightforward way to do things like: Draw half a sprite or half of a character due to scrolling. Of course, totally out of view elements should not even be drawn but those that straddles the scroll border do not have to be treated specially by CPU code. Just draw them as usual and they will be clipped.
I'm not really sure if state persists (it probably doesn't in SDL_Gpu, but also who cares I suppose), I intended to implement as always setting the scissor for each draw call, same for viewport. It's simpler this way and probably more cross-platform. As in, the backend implementations always set those each draw call.