You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice if GraphX had a way of setting a global pixel function for drawing routines. (especially primitives)
This would be useful for example in texturing and shading. Yes I know this would lower performance, but it'd be really cool.
The pixel function (and state information) would probably have to be loaded into cursorImage (fast ram) to have any semblance of speed.
In places that don't already call the existing global pixel function it could be padded with nop opcodes and SMC'd into a call if the custom pixel function is set. To handle alternative argument combinations multiple functions could be used to move the arguments around for the user's pixel function. As for preserving registers during, use the shadow registers and disable interrupts as part of setting the custom function. (documented in bold obviously)
I'll probably work on this myself at some point, as well as (attempt) to write a shader compiler of sorts for generating more efficient code for said pixel function.
The text was updated successfully, but these errors were encountered:
Practically all of the filled drawing functions don't use a global set pixel function, but a horizontal line function (which is also already being called via C ABI and tends to be chosen based on clipped or non-clipped variants of the routines). In my opinion, this would be a much more effective customization point for efficiency purposes, at a minimum of added code - simply add a new API for each filled graphics routine that accepts a horizontal line draw function as its last parameter.
It would be nice if GraphX had a way of setting a global pixel function for drawing routines. (especially primitives)
This would be useful for example in texturing and shading. Yes I know this would lower performance, but it'd be really cool.
The pixel function (and state information) would probably have to be loaded into cursorImage (fast ram) to have any semblance of speed.
In places that don't already call the existing global pixel function it could be padded with nop opcodes and SMC'd into a call if the custom pixel function is set. To handle alternative argument combinations multiple functions could be used to move the arguments around for the user's pixel function. As for preserving registers during, use the shadow registers and disable interrupts as part of setting the custom function. (documented in bold obviously)
I'll probably work on this myself at some point, as well as (attempt) to write a shader compiler of sorts for generating more efficient code for said pixel function.
The text was updated successfully, but these errors were encountered: