Replies: 1 comment 6 replies
-
For the moment I think you can handle the N shader invocations in the order you want, in a user function responsible for the post-processing effects, right ? |
Beta Was this translation helpful? Give feedback.
6 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi, I'm very interested in how ebiten deals with fragment shaders, and how you implemented a go-like DSL for cross-compiling to different shading languages. I happened to create a similar thing, called tinsl, which is a sort of extension to GLSL with type inference using
:=
. Beyond this, I was also interested in being able to render to texture half-way through a shader, and read from that texture later in the shader, essentially specifying an entire rendering pipeline in shader-like code. The tinsl compiler will split this up into multiple shaders. Consider this example of doing a "bloom" effect:This gets compiled into four separate GLSL fragment shaders (a sort of "shader tree") which then get run in a specific sequence. I think such a feature would work really well within ebiten, since you already have a shader DSL. This would enable the user to do much more complex post-processing effects that cannot be accomplished efficiently within a single shader. (Like Kage, tinsl also doesn't have structs yet, because parsing is a lot of work lol)
Beta Was this translation helpful? Give feedback.
All reactions