Version 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.

@Capehill

Thank you very much for your work and fast bugfixes!

Edit: And oh yeah to confirm back, now the Editor focus works with Composite effects on.

@khayoz

Good to hear. Now that some of the "mysteries" are gone, it's possible to concentrate on features :)

(But I don't know why SetWindowTitle call loses the texteditor.gadget focus...)

@Capehill

Quote:

Sounds very good!

Quote:

Dont worry about that for now, the separate gui element works! Someone will post an answear why it behave like that sooner than later I guess.

@Capehill

Tested 1.11. First impressions: very nice :) Report as usual:

1). No more errors about text editor start, yeah!

2). It didn't lose focus now, even with enabled compositing! Double yeah :)

3). External editor:
a). auto-reload of shader when saved works in NotePad and CodePad. Cool!
b). through auto-reload didn't works when an external editor is StormED, but that can be because of StormED internal locking/protecting while working with files, dunno.
c). "gvim" as the external editor didn't start at all sadly. I can see in snoopy that the last call is correct to execute , like "work:vim/gvim" with "path_to_shader/shader.frag", etc, but nothing starts.
d). shouldn't auto-reload of shader be controlled from tooltype? Not necessary of course, being it working by default fine enough.

4). Can you also add just the name of the shader after the "size" field? I.e. Time | FPS | Size | Name_of_filename. That will be pretty handy when you work with more than one instance of shaderjoy.

5). When we in window mode, and disable fps-counter from a menu, it didn't clear, but only after I switch to fullscreen and back to window mode. Only then it has there "shadertoy".

6). Tooltype for set the initial window size can be handy as well

Thanks for not ending work on :)


EDIT: Oh, found that this "auto-load of shader when changed" are handy feature! It's help to test shaders when i upload new ones with the same name from win32 to os4 machine, without needs to hit "recompile" all the time.

@Capehill

Is it possible to add screensaver option to ShaderJoy?

E.g. after 1-2 minutes (or user modifiable time), ShaderJoy switches to a fullscreen and runs the shader until you touch mouse or keyboard ?

@SinanSam460

Very nice idea!

@Capehill
Can it be that mouse initial values do not clears when you load new shader in already opened instance of shader joy (via drag&drop for example) ?

I have found that issue : if you open any shader, then hold a mouse button and move a bit down, and then open that shader: https://www.shadertoy.com/view/MtBcz1 , then values of the mouse from the previously loaded shaders taken as default for the new one, and so we have wrong rendering based on the non-cleared mouse initial values (imho).

@kas1e

Mouse is not reset at any point IIRC so there could be some issue.

File monitoring requires that the file is closed. If you literally close StormED, does that trigger reload?

Regarding Gvim, does it require some input/output stream to work? I think I'm passing NULLs and that might be the reason.

Auto reload tooltype sounds sensible.

Shader name can be added.

@SinanSam460

Screenblanker is doable but I would like to add some missing Shadertoy features first.

Version 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.

@Capehill

Thanks for implementing all the stuff! Everything good and works as expected. I even can use gvim now (had to run it like "EDITORNAME=work:vim/vim -g" ). Also clearing of mouse position works too as well as WINDOWSIZE tooltype.



And that new prefs window for channel's textures is pretty cool. Have through found something maybe you will be in interest about:

1). Made them asynchronous. I.e. if one choice "load iChannelX", then while window open, it didn't block usage of shadertoy, so you can do other "load iChannelX", or anything else, just these window didn't block the main one.

2). Made by default Filtering be "Nearest", or at least "Linear", because as it now (with MipMap), we had all the time diagonal line, so you need to checkbox another one always.

3). When we open the Channel window and do nothing, we have 100% CPU loading.


PS. Currently have checked dunno how much shaders (5 thousands, or 10). And already have about 1000 shaders working on nova 1.73 (and that include more or less good looking ones, not shity ones). Probably when Nova will be released to public, that archive can be loaded somewhere to os4depot as well.

@kas1e

IIRC I had "gvim" running. Do you get the assign requester?

1) Yeah, it would be nice. It shouldn't be very difficult but maybe I'm overlooking something.

2) I wonder could Daytona take a look at mipmap filtering?

3) Thanks. This could be fixed either by a wait call or with asynchronous implementation (vsync).

PS. you need to take a break from shaders :)

@Capehill
Thanks for the great updates

Quote:
Sorry, if this workaround had been mentioned before I missed it. Yes, it did and my report was wrong, it was just that sometimes I had started notepad or sth else with a text gadget before and didn't realize it. But who cares, it's fixed

@kas1e
@Capehill
Quote:
Quote:
Nova once had problems with NPOT mipmapping but that should have been solved long ago (IIRC it was fixed during "Spencer" development). But that bug resulted in general pixel garbage, the texture data was misinterpreted, IIRC. Here however the texture fetch is obviously broken, not the texture data. Also interesting that the "pixels" of the diagonal line are actually always 2x2 pixel blocks of which all of its 4 pixels share the same color.
Really weird, never saw sth. like this before. Looks as if you just found a fresh big Nova bug.

However, before I give my final verdict, please mail me the source of your texture setup. Maybe there's some subtle bug somewhere which in turn tricks ogles2 to prepare an invalid sampler (e.g. if I forgot to check some error condition somewhere). A Nova bug is much more likely of course (last not least because I actually cannot imagine any bogus sampler setup which would result in sth like this), but let's check first.

@Daytona675x

E-mail sent.

Some time ago I tried to modify Nova's TextureCube example to use mipmap filtering but wasn't able to trigger the problem with simple changes.

@Capehill
At first glance I cannot see a bug neither in your code nor in ogles2.lib. The automatically generated mipmap chain seems to be okay too.
Btw.: the 2x2 pixel look stems from the fact that both triangles of your fan produce the same artefacts at their respective edges (most often but not always those are of the same color as I saw now).

That garbage diagonal line revealed a minor issue with Shadertoy though: apparently the render-rectangle is not necessarily resized correctly until you manually force it to resize.

Edit: Wanted to see what happens if I explicitely select a LOD by using textureLod() instead of texture() -> not implemented in Nova.

Edit: I'm now building a test app from ground up to see if I can somehow reproduce this with my own code So far I could not, but so far I'm using normal UV mapping (which is what that textureCube example does too).

Edit: Some Nova-"fun": if you add the following no-op lines on top of your texture_rotator.frag, then the diagonal garbage starts to flicker (stop animation to see the effect):
vec2 fc=fragCoord;
fc.x+=0.0;

Verdict:
Severe Nova bug. Can be reproduced and triggered if you use gl_FragCoord to access a mipmapped texture via texture(). No workaround found.

Quote:
I tried too, and it was pretty easy after all:
Modified Nova's own textureCube example to reproduce the bug and to rule out any other factor, check it out here.

@Capehill
@kas1e
Reported as Nova bug.

@Daytona675x

Thanks for looking into it. If Nova fix gets into the next release, then great, if not, I can change the default filter setting to linear.

I will have a small "holiday" from Shaderjoy, maybe back in business next week :)

@Capehill, Daniel

Checking some more shaders with textures, and can say that this definitely needs to be fixed in Nova only, not workaround in ShaderJoy: the reason is that only now I found that it for real made difference if one use mipmap, linear or nearest textures in ShaderToy's shaders. Take a look at that shader: https://www.shadertoy.com/view/ldXXDj

On Win32 it looks like this (with Filter = Mipmap, Wrap = repeat and VFlip enabled for both textures):



And now, it looks the same on os4 only when we have Mipmap too, just with the diagonal trashy line:



And how ugly it starts to look like with Linear or Nearest (while not have a buggy diagonal line, but looks pretty bad still, see when the water meets a horizont):



I assume some small rendering bugs I found also will be related to the same fact that mipmap wasn't used when I do test all the stuff.

@Capehill
Well deserved "holiday"

@kas1e
yes, not having working mipmaps is close to being a show-stopper here in case of ShaderJoy (in most games it should work, the common way of vertex interpolated UV mapping seems to work). That's why I marked the bug as what it is: severe and with high priority. Wonder what Hans messed up there, it's really a weird issue. I mean, it's not random garbage. Looks as if the wrong lod is picked for fragments on the edge of the triangles only if a mipmap filter is enabled for the respective sampler.

@Capehill

Found an interesting issue. There is shader: https://www.shadertoy.com/view/WlBXzy

That one works fine in all ShaderJoys till 1.11. Now, in 1.12, it starts cause lockup, and in serial I start to have issues from Radeon driver:

RadeonRX (0): Wait idle timed out. GPU busy
RadeonRX (0): mmGRBM_STATUS: 0xF7D20028
RadeonRX (0): mmGRBM_STATUS2: 0x70000008
RadeonRX (0): mmGRBM_STATUS_SE0: 0xEC400000
RadeonRX (0): mmGRBM_STATUS_SE1: 0xEDC00000
RadeonRX (0): mmGRBM_STATUS_SE2: 0x00000006
RadeonRX (0): mmGRBM_STATUS_SE3: 0x00000006
RadeonRX (0): mmPA_CL_CNTL_STATUS: 0x00000000
RadeonRX (0): mmPA_SU_CNTL_STATUS: 0x00000000
RadeonRX (0): mmSQ_THREAD_TRACE_STATUS: 0x80000000
RadeonRX (0): GFX ring hung. Performing a GPU reset


But that shader surely works ok with any ShaderJoy before 1.12. Strange! Strange because I had the same kind of issue with few shaders, but that all the time, with any ShaderJoy. Strange that in the case with this one, the matter is ShaderJoy itself. Was something changed in 1.12 which can cause that? (and maybe other shaders causing that will be not nova/Radeon issues in end ?)

PS. Did you get beta versions of Nova at the moment? Mattew should send you one a weeks ago.