Shaderjoy 1.25

@kas1e

I have been mostly doing simple tests, like load four_in_one.frag and then load some shader channels.

It seems that many Shadertoy shaders use Common and also it seems that Buffers A...D are doubled so there is previous frame and current frame (shader can refer to previous frame if I understand right) and we have only the current frame so SJ cannot run most (?) ST multipass shaders today. So I need to add Common and double-buffering as soon as possible.

But what is the error you are getting, is it shader compilation related or something else?

@Capehill

Nope, didn't find any major bugs here.

@Capehill
Quote:

Just tried few multipass shaders from shadertoy, which had mainimage + bufferA only, as result once i load test_main.frag, i have "Main channel doesn't exists, cannot update channels". If i then load as iChannel0 test_bufferA.frag, i have the same error.

@kas1e

Please share a link and I will try the same shader. That issue would indicate that main shader failed to load for some reason.

@Capehill

Quote:

Sorry wasn't able to give you shaders you need, because in general, I feel that the current way to set buffer/common/etc shaders a bit unclear now in ShaderJoy. I mean that iChanne0 subchanne0 blabla , and before giving the test shaders was in hope to bring some idea how to made it all more intuitive and easy, but have no ideas at moment except maybe creating a ".shaderjoy" where you will describe all of this. Like text file called "shader.shaderjoy", in which pure text like:

BufferA="aaaa.frag"
BufferB="bbbb.frag"
Texture0="aasdfas.png"
Texture1="baabab.png"

etc. What do you think?


Anyway, the reason for that post is about another issue I find: take the latest ogles2 from Daniels FTP, where he improves the functionality of the detection of uninitialized vars.

Now, in ShaderJoy (at least in version 1.13), to make it all be visibly, you need for first enable "check uninitialized" (that is the default , and expected to be enabled, of course), but also enable "verbose log". Which is not that good. I.e. issue is: It didn't bring a separate warning window. Instead, it throws that warning in the "Verbose log" output (and only when it set) and continues execution like everything fine. So the only way to see an error, its to enable "Verbose Log", which, brings together with that warning a lot of other text, and warning easily missed from the whole output.

My suggestion is to mimic it as it was before with the ogles2 version with "force uninitialized var to fail". I.e. if we have in ShaderJoy "Check uninitialized" enabled, then does not matter if we have "verbose log" enabled, or disabled, once that option set, and uninitialized variable found, then we immediately bring a separate warning window about (and only about that, so it will be not missed), and then halt the execution of shader with an error.

If "check uninitialized" is not set, then it continues to works like before, without check, with all bugs it brings.

In other words:

- when we have a "Check uninitialized" set, then better to bring a standalone warning window with output from ogles2 (and only that output, no other one, just an output window with an only warning), does not matter if Verbose Log set or not.

- when we have a "Check uninitialized" set, we shouldn't be forced to see an error in "verbose log" only. It of course can also be in the verbose log as it now, no problems, but it also needs to bring another window with that error, so to be visibly standalone.

- when we have a "check uninitialized" set, then after we have a warning window from ogles2, we probably need to stop the execution of the shader with "fail to execute/fail to load/fail to load because of uninit vars.found" words. That of course, not necessary default (or indeed necessary?) and can be for example controlled via tooltypes, or, can be as it now (continue execution), but warning window with pure info about uninitialized vars should be brought in the face, does not matter if it is verbose or not set.

I mean, those "uninitialized vars", is not like something optional or not, it just some bugs in shaders, which we need to handle more aggressive, as Daniel do before in his "ogles2_forced_uninit_to_fail" version. Imho of course.

@kas1e

Quote:

Yeah, I haven't been thinking details too much but something like that. In addition to a project file, there should be some kind of configuration view to just select everything. There is also a need for shader tabs so that not only the main image shader can be edited.

Quote:

I will add a warning window but if I understand correctly, it's so typical issue with Shadertoy shaders, that I wouldn't like to block the compiling because of that. Regarding logging in general I would like to add an "output" view similar to what Daytona had in his version. It would be an ideal place for things like compilation time, warnings, errors and general status.

@Capehill

Quote:

I thinking about ShaderJoy "knowing" not just .frag files, but also .shaderjoy files, and so you can load as alone .frag file (with just mainimage only), and .shaderjoy files, which describe what else needs to be loaded, and that will be done automatically when you just load it. It can be just the same "Load Shader" option, just it will know and pure .frag, and .shaderjoy.

Quote:

Yeah sure, and it will be visually more logical: you will see in GUI what else was loaded.


Quote:

It happens from time to time, yes. If you don't want to broke execution, then warning window, in this case, should be brought to the face (and only with that warning, not together with other status output). Reason is that missing initialized vars cause all sort of issues, and when you will have things be executed, but trashed by look or didn't work as expected, you firstly will think about bugs in Nova, but if you will see a warning that there were uninitialized var, then you will know what can be wrong and check that first.

Quote:

Just it should be not just one single window for all that output, like in "verbose" now. Point is that this uninitialized vars thing are _very_ important, and they should be highlighted alone, in a single window, so you will be forced to see it in any case.

If that will be a window with "status/compilation-time/other warnings/etc", then it mean that words about unitialized vars will be again put together with other text, and you can easy miss it.

@Capehill
Regarding log / log display of compiler warnings like unitialized variables:
As far as I can see one problem is that (unless you run the uninit-detector in GL-error-mode) you are only spitting it into the log if in "verbose" mode. But in "verbose" mode you also fill the log with the shader source etc.
In general you should always show the GL-log if it's not empty, verbose or not. This would already help kas1e with his flooded log: if not in "verbose" mode it would usually be empty or contain the uninitializer warning.

@Daytona675x @kas1e

I tried to play with something like

Shaderjoy | grep uninit

But it only worked if I modify the logger to fflush(stdout), otherwise it only works after quit. So, it probably means I have to release a new version.

@Capehill
Quote:

You tried internally call "grep" command so to grep internal buffer if it has unitialisation warning? Or you just tried to play with it in the shell? In both cases, its not the solution, and I mean a different problem there :

What we need is just that: we load shader, if it has no initialized var found by ogles2, and if "uninint check" hit, it then brings us a window with output from ogles2 about that error.

Just make it like this maybe: shader loaded, if ogles bring any error about, you then output that in a new indow (just like it happens now when we out of registers). Without needs to check "verbose log". But if the "verbose log" set, then it just reacts as it reacts now. I.e. just need brining the warning window when uninit set, and verbose log not set, with redirecting ogles2 output to that window.

1.14 Changes:

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

@Capehill
Quote:

Yes! Thanks! It's even better now with requester: user forced to hit "ok" to continue execution of the broken shader, so kind of important interruption before you can continue. Good solution IMHO.

@Capehill
Yes, well done! Considering that currently most of kas1e's Nova bug reports are based on ShaderJ/Toy shaders this solution will make sure that Hans is only flooded with real Nova issues and not so much with issues caused by broken shaders.

There is one issue with requester: if extra shader debug is enabled, it will also be shown in the requester but it cannot fit. Luckily requester can still show the buttons in visible areas.

Maybe in the future requester output should be filtered.

@Capehill
Find out an issue which therefrom beginning: shaderjoy can't load shader if it put out of the main shaderjoy directory (i.e. one level up).

For example, I have that layout:

work:ogles2/shaderjoy1.14/

And put 01.frag to the:

work:ogles2/01.frag

Now, if I try to load it from the via "Load" menu in ShaderJoy it then says "failed to load shader". But if I load it directly from RAM: or from any directory which is inside of work:ogles2/shaderjoy1.14, then it works.

I assume the issue is that when we out of main directory, we have "/" added, and when it alone, we have a broken path or something.

@kas1e

Fixed, thanks. Path handler was only checking for ':' and not '/', so path became "//shader.frag".

Version 1.15:

- Add tab support (Common, Image and Buffers A, B, C, D).
- Allow editing of Common/Buffers A-D.
- Monitor changes of Common/Buffers A-D.
- Change Buffer logic: they are loaded outside the iChannel selection.
- Add Buffer selection to iChannel window: select either texture or Buffer A, B, C or D.
- Fix path issue related to '/' handling.
- Flush stdout to make real-time log filtering possible.
- Rewrite rendering logic for improved frame buffer support.

How to use buffers?

1) Load some shader that uses iChannel0
2) Load another shader as Buffer A, B, C or D
3) Using Load iChannel0 menu, select the loaded Buffer A...D, instead of a texture.

@Capehill

Thanks for the new version. This program has became my favourite shadertool on amiga!

@Capehill
Cool ! Doing some tests.

1). just a "main image" + "common" :

https://www.shadertoy.com/view/tlBfDh : works!

2). just a "main image" + "Buffer A":

https://www.shadertoy.com/view/wt2fDt : functionality seems to be ok, i.e. compiles and something renders, but i see visual bugs. Can be again Nova issues, but looks like something with "mixing" two rendering at once. Btw, in this one "pause" didn't work as expected as well
https://www.shadertoy.com/view/ttBBWc : this one works as expected.
https://www.shadertoy.com/view/3tSfD3 : works as expected, but if you watch closely produce some lines of strange pixels at the left and at bottom (like, again, mixing of 2 rendering a bit wrong). CPU Loading there 100%, and pressing "pause" didn't drop cpu loading, still 100%. And those lines at left and bottom continue their animation.
https://www.shadertoy.com/view/Wl2BDV : allso functionality ok, but can be seen how 2 buffers renders wrong. When you try to resize window a lot, you will even see some trash there and there.
https://www.shadertoy.com/view/WlSfDm : good one, works as expected. Pause through also didn't works as expected.
https://www.shadertoy.com/view/Md3GWS : works!
https://www.shadertoy.com/view/Xdt3DB : that one again looks like 2 buffers mixed a bit wrong

3). "mainimage" + "buffer A" + textures :

https://www.shadertoy.com/view/3lffzS : works as expected!

4). More heavy example : "main image" + "Buffer A" + "Buffer B" + "Buffer C":

https://www.shadertoy.com/view/WtSfRy : That one works ! And this one pretty hardcore : it use ichanells and for "mainimage", and for "buffers" too. Effect renders a bit different in compare with win32 version, and that
can be maybe because simple because one of the buffers didn't taken in account. I.e. i can't see on os4 "yellow" part of effect. In that one "pause" also didn't works as expected.

Bugs which found at moment:

1). Drag & Drop works only for general "main image" shaders. I.e. if i do load shader, then create a "new tab" for "Buffer A", and drag & drop shader to buffer A while tab is active : it still loads Buffer A as "main image" one.
2). When you can't compile "Common" or "Buffer A/B/C/D" shaders, then instead of bringing error and keeping running, ShaderJoy just exit with words can't compile shader and closes.
3). In most of those "multipass" shaders "pause" didn't works as expected.

@kas1e

Thanks for testing. Some general comments:

a) There is some issue with buffer usage when buffer is sampling other buffer, like Buffer A sampling its previous frame. I will try to initialize FBO texture with glClear when viewport is created / resized, hopefully this will cure the visual issues than happen especially during resize.

b) Pause mode is problematic because it's rendering new frames so in case Buffer A is blending with its earlier frame this will change also the current frame even though iTime is static. Pause mode needs a change so that old frame is displayed and no new ones should be rendered, until resume.