Shaderjoy allows you to display Shadertoy (https://www.shadertoy.com) compatible
fragment shaders. Fragment shaders (sometimes called pixel shaders) are programs
that are executed per fragment (pixel) on the GPU.

Version 1.14 is available on http://capehill.kapsi.fi/ .
Version 1.11 is available on http://os4depot.net/?function=showfil ... hics/viewer/shaderjoy.lha .

If you have created some compatible shaders, why not share your art with others :) If you haven't created a shader ever, why not start today?

Take a look at the shaders directory, there you can find some shaders (.frag) created by me and some by Shadertoy community.

Requires OpenGL ES 2.0 and Warp3D Nova.

History:

1.14
- Add Common support. Common file is "included" before shader programs.
- Refactor GUI code.
- Display shader info log always when available. In case of errors and warnings display also a requester.

1.13
- Make channel windows asynchronous and allow opening them simultaneously.
- Make load and save requesters asynchronous.
- On quit or fullscreen toggle, wait for save requester to finish. Otherwise try to close extra windows.
- Do not advance iDate uniform in pause mode.
- Update shader name when filename is passed as a startup argument.
- Set GL viewport during startup.
- Add multipass rendering concept: allow loading of shader programs as iChannels, and
allow loading of textures for those shader programs.

1.12
- Duplicate input / output streams when starting an external text editor.
- Add WINDOWSIZE tooltype.
- Add AUTORELOAD tooltype.
- Display shader name on info element.
- Display info element regardless of EDITORVIEW setting.
- Add channel window for setting up the textures.
- Clear mouse position when loading a new shader.

1.11
- Fix issue with texteditor.gadget creation (caused by missing OpenClass calls).
- Combine Play and Pause buttons.
- Display FPS and time info in a separate GUI element instead of window title bar.
- Monitor shader source file and reload it on change.
- Add Control menu (Play/Pause, Rewind, Compile).
- Rename EDITOR tooltype to EDITORVIEW.

1.10
- Add tooltype EDITOR. When enabled, allow editing in window mode.
- Add tooltype FONTNAME and FONTSIZE, to configure editor font.
- Add tooltype EDITORNAME, to define external editor tool.
- Blank mouse pointer in fullscreen mode, when mouse is inactive.
- Allow pause mode toggling with SPACE key.
- Unpause when loading a shader.
- Update display also during pause mode, but on a slower rate.
- Re-enable reload functionality.

1.9
- Allow shader editing in window mode.
- Add play, pause, rewind and compile buttons in window mode.
- Allow saving of shaders.
- Remember window size when coming back from fullscreen mode.
- Add possibility to check uninitialized variables (requires ogles2.library version 3).
- Add tooltype CHECKUNINITIALIZED.
- Add possibility to dump verbose Nova-level compilation logs (requires ogles2.library version 3).
- Add tooltype SHADERDEBUG.
- Log shader info log always when available (in verbose mode).
- Time and log shader compilation (when in verbose mode).
- Remove possibility to reload shader.

1.8
- Use vertex buffer objects (VBOs).
- Add iTimeDelta and iFrameRate uniforms.
- Add AppWindow support: shaders can be dropped into the window.
- Shader filename can be passed as an argument.
- Improve About box: display GL information.
- Fix issue with blitting over window borders.
- Initialize fragment colour because some shaders do not.
- Reverse iMouse.y.

1.7
- Open all screens with SA_LikeWorkbench tag.
- Disable optimized bitmap allocation.
- Log OpenGL information during startup.
- Display version number on screen title bar.
- Fix an issue where FPS counter was not visible when started in fullscreen mode.

1.6
- Improve VSYNC mechanism.
- Remove FPS counter flickering in fullscreen mode.
- Allow toggling of FPS counter.
- Add SHOWFPS tooltype.
- Add SCREENMODE tooltype.
- Disable Iconify menu option in fullscreen mode.
- Drop command-line argument support in favor of icon tooltypes.

1.5
- Fullscreen mode. Created using SA_LikeWorkbench so it's likely larger and slower than default window mode!
- Improved logger: buffer is no more limited to 16 kilobytes.
- Changed default texture path to "textures/shadertoy" for improve usage.
- User-selectable VSYNC mode (WaitTOF, WaitBOVP or disabled).
- Changed default window size to 800 x 450.
- Display running time on window title bar.
- Display window size on window title bar.
- Use window pointer in ASL requesters.
- Fullscreen tooltype.

1.4
- Add icon tooltypes.

1.3
- Add iDate support.
- Add verbose logging.
- Fix: window pointer is now cleared when close gadget is used.
- Keep textures (iChannels) active when switching shaders.

1.2
- Fix: iChannelResolution is an array of vec3s.
- Workaround: use GL_LINEAR texture filtering to avoid diagonal line where triangles meet.

1.1
- Add iChannel0...3 texture support. Each channel must be loaded manually at the moment.
- Add iChannelResolution0...3 support.
- Add stack cookie and log stack usage at the exit.
- Display a message box in case shader or texture loading fails, instead of exiting.

1.0
- First version

@Capehill

Some shaders are really beautiful, like kissing_donuts and foot_torus.

Do some frame-rate table of all shaders on my setup (x5k + radeonHD 250x) (without VSYCN of course), and with default size of window on running (810x650 ?)

defaul (blue window) : 1188

capehill/amigaa : 1186
capehill/bars: 990
capehill/gear: 1187
capehill/helloh: 1167
capehill/helloh2 : 1147
capehill/mandelbrot: 48 (?)
capehill/nuts: 1186
capehill/ripple: 1190

shadertoy/dueling_mandelbulbs : 418
shadertoy/foot_torus: 13 (?)
shadertoy/kissing_donuts: 13 (?)
shadertoy/sunset: 1030 (is it static, or something should changes there?)
shadertoy/yetanother_torus: 21 (?)


So far some are fast as expected, some are pretty slow.

Intersting also that when i resize the window, speed of execution pretty much slower down (i was under impression, that with ogles2, most of time does not matter size of window, it all about the same should be).

But if just more data need to be transfered from ram to vram, then we hit DMA wall then..

@capehill:

Awesome, i was hoping to make something like this, but with an integrated editor like bonzomatic, but as always, some bugs and my own incompetence made me abandon it too early.

@kas1e

FPS depends on window size, because larger pixel area means more fragments, so fragment shaders need to do more work. One pixel equals to at least one fragment.

Foot_torus is slightly broken, when you compare to Shadertoy.

Regarding sunset.frag, it's really static and here is the "making of" video for it: https://www.youtube.com/watch?v=0ifChJ0nJfM Inigo is a real wizard.

@Ami603

Yeah, integrated editor would be nice to have, to make it more "live".

@Capehill
I made pretty much the same in 2016 as a testbed for ogles2 and Nova, I however called it ShaderBoy


I totally forgot about it; back then Nova supported not enough shader commands for it to be fun.

@Daytona675x

Cool :) Does it have iChannel support?

@Capehill

Nicely done! simple and clean program for shader prototyping. Thx!

Pause option/key would be nice. But for now iconifying seems to pause the render loop as well.

And here are my results (X5K + R9 280X + VSYNC disabled + default Window size):

default (blue window) : 1069

capehill/amigaa : 1066
capehill/bars: 1062
capehill/gear: 1066
capehill/helloh: 1067
capehill/helloh2 : 1065
capehill/mandelbrot: 90
capehill/nuts: 1067
capehill/ripple: 1067

shadertoy/dueling_mandelbulbs : 704
shadertoy/foot_torus: 23
shadertoy/kissing_donuts: 24
shadertoy/sunset: 1062
shadertoy/yetanother_torus: 45

@IamSONIC

Quote:

Yes :) I noticed by a chance that CPU hit 100% when iconified. Then I added a Wait() call in event handler and it started to behave nicely again.

WoW, really nice ! Some of them would make good screen saver ;)

@Capehill
Quote:
No, it's rudimentary: it supports iResolution, iGlobalTime, iTimeDelta iFrame and iMouse. Back then I was too lazy to add some sort of texture-manager, so no iChannel The variable list on the top right is just a reminder

@kas1e
Note that with ShaderJoy you only measure fill-rate / Nova's fragment shader performance, pretty much nothing else: the geometry is just a static quad, the vertex shader is minimalistic, the shader program never changes. The only thing that changes per frame and therefore is being sent to the GPU is the DBO with the handful of uniform variables.

Would be very interesting to see how those fps numbers compare to a Windows rig with the same gfx card.

Here are my results:
X5000, ogles2 3.0 (wip), Nova 1.68, passively cooled R7 250 1GB:

default (blue window): 1049

capehill/amigaa: 1046
capehill/bars: 862
capehill/gear: 1046
capehill/helloh: 1033
capehill/helloh2: 1016
capehill/mandelbrot: 42
capehill/nuts: 1045
capehill/ripple: 1048

shadertoy/dueling_mandelbulbs: 363
shadertoy/foot_torus: 11
shadertoy/kissing_donuts: 14
shadertoy/sunset: 909
shadertoy/yetanother_torus: 18

@Daytona675x

It would be nice to have some kind 3D object viewer with material support, for example, load Stanford Bunny (or cow :) and apply some fire / glass / whatever shaders on it. Maybe someone has already something like that?


Quote:

:)

By now everyone should know that I love benchmarks .

Sam460ex, ogles2 2.11, Nova 1.70, Single Slot Radeon Rx 550 4GB:

default (blue window): 1438

capehill/amigaa: 1428
capehill/bars: 1284
capehill/gear: 1424
capehill/helloh: 1419
capehill/helloh2: 1393
capehill/mandelbrot: 112
capehill/nuts: 1420
capehill/ripple: 1426

shadertoy/dueling_mandelbulbs: 644
shadertoy/foot_torus: 36
shadertoy/kissing_donuts: 39
shadertoy/sunset: 1287
shadertoy/yetanother_torus: 52

@CampeHill
Very nice work!

My results (X1000 + RadeonHD 7550 2G, No VSYNC, default Window size):

default (blue window) : 1044

capehill/amigaa : 1040
capehill/bars: 870
capehill/gear: 1040
capehill/helloh: 1027
capehill/helloh2 : 1011
capehill/mandelbrot: 42
capehill/nuts: 1040
capehill/ripple: 1042

shadertoy/dueling_mandelbulbs : 366
shadertoy/foot_torus: 11
shadertoy/kissing_donuts: 10
shadertoy/sunset: 905
shadertoy/yetanother_torus: 18

@ Capehill

cool..thanks!


@Spectre660

hehe me too..will post my results tomorrow...late here and too lazy to head down to mancave tonight

@Daniel
Quote:

Did i got it right, that this mean if there will be DMA it will be faster ? I.e. now we meassure sending to the GPU of fragment shaders ?

@All

Installed RadeonRX Polaris11 on my x5000 , and with RadeonRX beta driver with fixes in the PCIe speeds and with maximum power level have those results which look pretty better:

default (blue window) : 1928

capehill/amigaa : 1925
capehill/bars: 1902
capehill/gear: 1923
capehill/helloh: 1921
capehill/helloh2 : 1918
capehill/mandelbrot: 175
capehill/nuts: 1915
capehill/ripple: 1912

shadertoy/dueling_mandelbulbs : 1153
shadertoy/foot_torus: 54
shadertoy/kissing_donuts: 63
shadertoy/sunset: 1902
shadertoy/yetanother_torus: 85


So while the same shaders slower much than others, they at least has much better fps on my RadeonRX 11 with latest beta drivers.

@kas1e
Quote:

No. Here having DMA / GART makes almost no differnce here because nothing but some bytes are being sent to the GPU each frame (maybe 100 in worst case, depending on DBO layout and on which uniforms change).
We don't measure any sending of fragment shaders neither. Those aren't sent per frame. It's compiled once and sent / activated once when you select the desired effect.
What's measured here is the fragment-shader being run for every fragment (which in this case means for every pixel, because we only draw a window-sized rectangle), that's it (well, plus some rather static function call / OS overhead etc. of course). So the current AmigaOS-brakes don't apply here.

@Daytona675x

It seems that I have forgot to use a VBO. Maybe in next version.

@Capehill
Not really necessary, I just deleted that text fragment out of my above comment
ogles2 will detect that your vertex data is the same and use the already prepared internal VBO. Providing your own will in theory still be faster but in practice this difference will hardly be measurable. The point is: in neither case will vertex data be sent to the GPU more than once.