Solar2D ShadersBank

Solar2D Custom Shader Effects
#1

Been having fun with massing my hand up with shaders from other website, mainly from Godot shader. created a repository for the transplanted shaders which are Solar2D-Ready. Solar2D_shaders

Most of them are works well say 95%, and few are not work as expected. I was mainly concerning on refactor thing, copy paste to quick start for new one, so many of the code are not polished( unused variables remains, but won’t affect it’s functionalities at all).

Having fun with them, sent me a pull request if you like to add more shaders or modification to it. :grin:

9 Likes
#2

Could you please add a few demos of their use in the repository

1 Like
#3

This would be really helpful, to save having to go in and check the parameters for each one individually.

#4

Thank you for sharing this! Added to the awesome-solar2d list.

1 Like
#5

Great idea, I’m now working on the showcase which dose switch between shaders, swap texture and tweak vertexDate in realtime. it won’t take long I suppose

3 Likes
#6

That would be amazing. I had a quick play around with a few of them, but having a way to quickly check them all out will make it much easier to find the effect that someone is after.

#7

Now the shader viewer is completed! I changed project name so the new link is Solar2D_ShaderBank.

@ bgmadclown : you would like to update the link in the list I guess :smiley:

Btw, tweaking some parameters won’t actually affect the current shader, that is because I didn’t fix them yet, not a bug. I’m working on fix them up and replacing variables with vertexData in those shaders, still you can have a quick tour for how those shaders look like. let’t me know if you encounter bugs and have fun!

3 Likes
#8

Thank a lot for your contribution!

1 Like
#9

I’ve downloaded the latest copy, and trying to view the kernelF_blur_box shader triggers an error:

plugin/shdilr.lua:193: attempt to index field 'paramName' (a nil value)
stack traceback:
	_plugin/shdilr.lua:193: in function 'new_dUniform_mat4'
	main.lua:352: in function 'load_shader_data'
	main.lua:362: in function 'apply_bank_shader'
	main.lua:483: in function 'swap_shader'
	main.lua:444: in function 'right'
	main.lua:548: in function '_onEvent'

I tried copying the paramName field from another shader to the blur_box data to fix the error, but don’t understand it well enough to know exactly what to add so it didn’t work.
Removing the kernelF_blur_box file entirely allows me to check out the other shaders though.

#10

Thanks for bug report! I’m still taking time on other parts of the shaders, didn’t go through all of them for checking and fixing bugs yet, so the reports helps a lot :smiley:

The reason why using paramName is for “shdlr” module to load it, so we could change the value from slider bar.

Just uploaded new commit for update that one, also created a shader which draws multiple lighting circles in black canvas with the their position and radius can be changed in runtime by uniformData, it suits for platformer or topdown stages which sort like dungeons and caves. try kernelG_Lit_vignetteN if you are interested.

Due to the weird attribution of which CoronaContentScale.x and CoronaContentScale.y are always the same regardless of rect width height ratio, we need to tweak the Aspect_Y parameter manually to make them perfect circle when the rendering rect is not a perfect square.

2 Likes
#11

CoronaContentScale is an application-wide property, initialized at the start of each frame.

It’s used to compute the CoronaTexelSize properties, details here. Those are updated if the texture changes, not the geometry, so aren’t per-rect. (Changes like this mean separate draw calls, which would be too expensive in the general case for each display object.)

What follows is some food for thought, but probably not immediately useful.

We synced these features in build 3713. (Still need to investigate this issue and squash this bug.)

There are a lot of things in there and I need to get on the docs and all that.

(I have a bunch of material in rough form at the API level, between the PRs and some local files. However, Solar’s vertex format, flow of control, etc. need documenting: I assumed nobody was going to completely rewrite the engine at this point, and designed with that in mind, promoting some of these former “implementation” details in the process.)

“Automatically” calculating a property, like Aspect_Y in your case, is something I’ve considered a lot. (In my case, often it’s about finding the center of a spritesheet frame, either the position or the texture coordinate, in order to do effects based on x and y positions between 0 and 1.)

The “effect data type” feature, demonstrated in the example with the boxes moving up and down, might be a way of achieving this. It’s a bit like a geometry shader, but outside the rendering pipeline.

I mentioned “An effect data type is something you will only see on the C++ side.” when describing them. This is obviously an awkward restriction and definitely not friendly to experimentation, and I’ve been considering ways to open this up. For speed reasons it isn’t ideal to do these things in Lua—they might operate on huge batches of vertices—but that’s no reason to outright forbid it.

The more difficult issue is that events like this happen outside “enterFrame” / timers / etc. context, once everything’s ready to go, so it’s assumed you’re done calling Solar APIs and manipulating display objects. There could be a “DON’T USE THOSE!” caveat on this kind of Lua code, but that would be a very easy policy to break, so it’s probably best to sandbox these bits in separate Lua universes.

2 Likes
#12

Very appreciate the detailed and comprehensive info, things are far more complex than I thought!

Noticed there are some “geometry->GetVertexData()” calls, not sure but it looks like this could be used for something like “CoronaCanvasInitialSize” which only fetch initial width and height of rendering geometry and won’t response to updated one. initial size would be helpful for calculating aspect.

Another inspiration is “CoronaScreenSampler” which fetch the render data from memory. this could be done by using snapshot as root group for gameplay objects and simply apply shader effect on it. just not sure is that a efficient way to do rather than fetching render data.

After all, these are “make life easier” ideas not imperative ones, so they shall be flagged “Low Priority”, many thanks for your reply! :smiley:

1 Like
Weird custom shader built-in variables attribution
#13

Another inspiration is “CoronaScreenSampler” which fetch the render data from memory. this could be done by using snapshot as root group for gameplay objects and simply apply shader effect on it. just not sure is that a efficient way to do rather than fetching render data.

Is the intention here to have a shader that would apply to everything on screen? When we tried to implement something like that in the past using the current shader system, it stopped touch input from working so we had to work around it quite crudely. If there is a way to apply a shader to the final render buffer, that would be a much better solution.

On a related note, do you (or @StarCrunch) know if it’s possible for a shader to use whatever has already been rendered behind the object as an input? If we currently apply a blur shader to an object, the object itself will look blurred but the background behind it will not.
As an example, we wanted to blur the entire screen when a pause menu is shown (but not blur the pause menu itself of course) but it doesn’t seem to be possible with current shaders. Or maybe it is possible but we’ve overlooked something.

#14

As an example, we wanted to blur the entire screen when a pause menu is shown (but not blur the pause menu itself of course) but it doesn’t seem to be possible with current shaders. Or maybe it is possible but we’ve overlooked something.

That is the circumstances which Snapshots can help. you have to add every thing you want render to a snapshot and remember to call invalidate() after that, simply apply the shader and voila.

Another solution is have some blur texture( something like kernelG_trans_scrnPixel or kernelG_FX_animatedTV in ShaderBank ) with alpha on top of the background to make it looks sort of unclear, it’s more efficient but the result may not so pretty as you just want.

Extra Tips:

  1. You can add groups to the snapshots so that will be easier for organization.
  2. You can also try it on invalidated texts for some fancy effect.
  3. If I remember right, the raw( not invalidated ) text objects roles as masks if you put shader on them.

Hope these helps! :smiley:

#15

Good point, that would work in the specific example I gave as you don’t usually need to interact with the stuff behind the pause menu. It was actually a poor use case for me to pick, because it doesn’t suffer from the problem we’ve had with snapshots+shaders in the past: using snapshots for the whole scene prevents the scene from being interactive.

For some shaders this logically makes sense. If you were to apply a heavy blur to the screen, the user wouldn’t be able to see what they were interacting with anyway. But for others like the TV style shaders, this isn’t an issue. Those shaders could be used in a way that the player could still be expected to interact with the scene (e.g. it could look like the Fallout Pipboy menus).
The only workaround we found was very crude, and involved placing a rect over the scene which captures all touch events and propagates them through to objects below. It worked but made the code harder to follow and added some other complexity. If the final screenbuffer was able to have the shader applied that would negate the need for the snapshot, and hopefully allow the scene to function as normal.

An additional use case I was interested in that would need to use the render buffer as input would be something like:
A lens that can move freely over the scene, but is out of focus using a blur filter. In that case, you wouldn’t want the entire scene behind the lens to be blurred - only the portion behind the lens. Blurring the lens image itself wouldn’t achieve this, but if the pixels behind the lens that have already been rendered could be used as input to the shader that would work.
I suspect this isn’t possible though, as it’s something I asked about over 10 years ago and the answer at the time seemed to suggest it couldn’t be done.

#16

@phoenixongogo @alanFlickGames The first example on the build 3713 link, “Capture Texture”, is pretty much exactly this.

As mentioned there, @Kan98 also played with it and has an additional example or two.

#17

@StarCrunch Where is the example you mentioned? I can’t find it here.

@Kan98 Would you like share us the examples or just some snippets about the “Capture Texture” features? thanks in advance :smiley:

#18

It’s in the STUFF.zip in the aforementioned link.

I believe that example still works; the others probably all need updating.

1 Like
#19

Yes, Capture Texture still works fine. And I’m looking forward to your update with the 3D object loading library. :muscle:

#20

You can easily see it in Star Crunch’s first example, but note that it will capture the entire screen, you will not be able to separate in-game and GUI objects.

1 Like