Btw, is it expected, that when I set for textures "VFLIP texture vertically", then for some shaders rendering starts to be visibly slower. Once I remove that option, it starts to be faster. That probably related to how shaders coded?
is it expected, that when I set for textures "VFLIP texture vertically", then for some shaders rendering starts to be visibly slower. Once I remove that option, it starts to be faster. That probably related to how shaders coded?
No, that cannot happen in my opinion. Vertical flipping is done once, when texture is loaded. Remove the impact of camera movement, for example replace all iTime by 0.0 and then FPS should be stable.
I think the logical explanation is the combination of moving camera and ray marching which involves a for-loop per fragment. FPS fluctuates on Windows side, too.
I think found some nasty bug in shaderjoy: starting from the 1.16 version some shaders just "rotated from the bottom to top", or from the "left to right". At 1.15 still fine.
There is a list of those shaders which start behave wrong since 1.16 (and including 1.17 too):
Now those problematic shaders seem to use directly gl_FragCoord instead of the flipped input variable "fragCoord".
Background:
1.16 changed the rendering pipeline by adding FBOs for the Image shader and this makes the behaviour different from 1.15.
There is also gl_FragCoord.y flipping in FBO cases because otherwise FBO textures are upside down for the reasons I don't know. Both gl_FragCoord and textures should be using the same coordinate system: origin at the bottom left corner.
I will ask Daniel and Hans about this. I would be keen to remove that flipping hack if possible.
y flipping in FBO cases because otherwise FBO textures are upside down for the reasons I don't know
That's because the first FB pixel is at the bottom-left, much in contrast to most textures that come from files where the first pixel is at the top-left.
@kas1e Quote:
Btw, is it expected, that when I set for textures "VFLIP texture vertically", then for some shaders rendering starts to be visibly slower.
And for others it will become visibly faster That's because some such textures' values are not meant to be interpreted as pure colors but are actually texture-encoded input parameters to the shader's logic and thus may influence its runtime.
I didn't find a concrete documentation but I find the format rather self-explaining. If you have an account at ShaderToy you can easily download the JSON for a specific shader that way:
Thanks! I will be looking into JSON format later, next year I guess :)
- Add project file support (.sjp). - Activate the most recently loaded tab. - Blank mouse pointer completely in fullscreen mode. - Reorganize RMB menus due to project file. - Rename "Channels" menu to "Shaders and Channels". - Rename "Shaders" menu to "Debug". - Refactor code dealing with file handling. - Reset frame counter on rewind.
Now when i d&d that file on shaderjoy have for all of them "cant load file".
Tried to add PROGIDR: before , same errors.
Probabaly hardcoded to be in some place only ?
Tried from shaders directory of shaderjoy, and only then it works. And it only works when it in shaders and in some subdir, like shaders/test/ , because if you just do test/ , and in the .sjp delete "shaders" directory at begining, it also fails to load.
I.e. even just putting files to the "shaders" dir and doing .sjp like this:
Probabaly the only hardcoded part sohuld be about "textures" (as they always come with ShaderJoy, and placed where they placed), but for the image.frag and buffers, it imho need to take any location from which you run .sjp from , as well as in the file itself pure names should mean current directory where .sjp placed, and anything deeper, mean starting from curent directory of where .spj file running from.
Hmm...paths should be relative to binary. If binary is started from some "random" location then it cannot find the files. Did you check with Snoopy how it looks like? I will take a look next year :)
I removed absolute paths on purpose but maybe there should be some assign...
Yeah, there no need to have absolute patches (just relative one for textures, which always placed in the "shaders" directory), but other files imho should be take as it from the directory where they placed together with .sjp.
Checked via snoopy and it show me just:
FAIL = Open("buffera.frag",OLD)
Same for all other buffers, while they there, in the same directory where .sjp file are. And their path in .sjp just like "BufferA path=buffera.frag".
Try to resize the window to be more or less like in the original shaderjoy site. Some shaders are done with meaning exactly the size of the window like on shaderjoy site.
@Capehill Give it a go for a normal 1.18 check, and one of the good things which I love is reorganizing the menu. More logical now and more clean/polished. Even if there wasn't project file support before, reorganizing by itself the menu is done well.
Also, the complete vanishing of the mouse pointer in fullscreen are tasty too, as well as auto activating of the tab :)
The only real issue I had now it with paths in the project file, I just can't point on the directories I need: not by absolute path, not by PROGDIR: one. While absolutely patches may only need for testing/debugging purposes, the PROGDIR: one can be made any project files work from any place, which is a must. Like, you wrote in = image = aaa.frag, and it takes aaa. frag from PROGDIR: If you want to put shader in one place, but project file in another place, then: image = path_to_shaders_from_progdir_of_project_file. And if one needs an absolute path for any of the reasons then just image = work:aaaa/aaa/aaa.frag
But overall it looks like something which soon is "Final". I mean what else it misses except polishing project file support + issue with rotated shaders, and audio/keyboard support added? Nothing ?:)
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
