Also, find out that when i resize the window , then dbl-click to fullscreen, and then dbl-click for back to the window, then size of window jumps on the original size when program runs, but not on the size we have when dbl-click to fullscreen. Not that it also very important, but probabaly when we switch back from fullscreen, size of window need to be the same as when we switch from.
I have added iTimeDelta and also iFrameRate (1.0f / iTimeDelta). However, that particular shader doesn't link on Nova 1.68.
Quote:
Also, find out that when i resize the window , then dbl-click to fullscreen, and then dbl-click for back to the window, then size of window jumps on the original size when program runs, but not on the size we have when dbl-click to fullscreen. Not that it also very important, but probabaly when we switch back from fullscreen, size of window need to be the same as when we switch from.
It's kind of subjective what is the best behaviour here. Probably to make it user-configurable (REMEMBERSIZE tooltype or something).
- 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.
I have added iTimeDelta and also iFrameRate (1.0f / iTimeDelta). However, that particular shader doesn't link on Nova 1.68.
For me, on 1.71 beta, it passes iTimeDelta error on shaderjoy 1.8 now, just to bring famous "need XXX SGPRs" :)
Quote:
It's kind of subjective what is the best behaviour here. Probably to make it user-configurable (REMEMBERSIZE tooltype or something).
Sure not a big deal, and if you will ever spend time on, the tooltype will be the best way indeed.
Quote:
Version 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.
Thanks a bunch!
So far everything indeed fixed and works from that list as I test now. The only things which can't check is if VBOs usage works as expected or not (but shaders I checked works the same as before, so should be fine, but maybe some speed up expected somewhere ?), and for "Initialize fragment color because some shaders do not" maybe there some shaders which fail with 1.7, but ok with 1.8?
So far everything works and fixed indeed from that list as I can test now. The only things I can't check is of VBOs usage works as expected or not (but shaders I checked works the same as before, so should be fine, but maybe some speed up expected somewhere ?),
As Daniel wrote earlier OGLES2 will optimize the unnecessary data transfer away but VBO at app level is what I was supposed to do. It's possible to use glSnoop here but it will be boring I guess.
Quote:
and for "Initialize fragment color because some shaders do not" maybe there some shaders which fail with 1.7, but ok with 1.8?
Ps. AppWindow feature is cool, I think it speeds up testing. I couldn't verify .frag filetype properly yet, I failed to use DefIcons but I can define some .frag file to start Shaderjoy and it seems to work.
Well, no, it change nothing. The same garbage on 1.7 and on 1.8. And it looks like one of those Nova's issues almost all of which were fixed lately (but that one still not, on 1.71 diagonal line, and garbage overwrite original effect all over the window).
Maybe it change something about colors, but while all garbaged can't compare.Tried to test if it change something with the shaders i mention lately in "warp3dnova's shader bug" thread where shaders do have issues with colors being different than expected, but issues same here.
Quote:
Ps. AppWindow feature is cool, I think it speeds up testing.
Yes, that one the first thing i tried. Works as expected :)
Quote:
I couldn't verify .frag filetype properly yet, I failed to use DefIcons but I can define some .frag file to start Shaderjoy and it seems to work.
Deficons prefs a bit nonlogic yep, the point there that you need to setup your filetype as FIRST (or it will be treated as ASCII one, and if you add new filetype later, it just will out of luck).
Check this out how it should be setuped (open in new tab for fullsize):
Place icon to the Sys:Prefs/Env-Archive/Sys/def_fragmentshader.info
Just don't forget to change default tool in it to the place where your shaderjoy binary are and be sure that in DefIcon prefs you call the the same "fragmentshader".
There I go heavy! Complex shaders on the latest nova, many at the same time, all with that deficons, app icon stuff, fullscreen (1920x1080), and so on. Shaders of choice are ones which were fixed lately, so they look "a bit" better in comparison with ones working before. If only Hans can deal with that register allocator crap and we will have no issues with "need XXX SGPRs/need XXX VGPRs", then shaders can be even more complex and almost everything from shadertoy will works. At least currently taking into account latest beta of Nova, the only real error is about needs for registers left, other shaders or just works, or works with some rendering glitches which can be dealt with.
Hans seems to spend quite a good time on bug fixing last week, and he dealt with most of the issues we had: matrix one, garbage with helper functions, boolean issues, and some others. I think he's latest video were about fighting with Nova bugs: https://www.youtube.com/watch?v=hZpb0b0ai58
The only big issue remains which means some major rework probably, it's register allocator part. As I understand it (but can be wrong), the current register allocator in Nova is a more or less simple one, which takes the amount of GPU registers as it, in the hope it will be enough. But with complex shaders, it's not enough sadly. So we need new register allocator doing spiling and stuff (create a buffer to which copy content of all registers, and take necessary values when needing it only). It's like we do 20 years ago on some i286 CPU which had quite a small amount of registers which wasn't' enough. But I didn't know of course how it in comparison with today's GPU, probably much harder :)
And there is a couple of rendering issues, which I trying to catalog and creating bug reports one by one.
And few missing instructions which used pretty often, like OpImageSampleExplicitLod and OpFwidth.
And a couple of regressions since 1.68
But if I understand things right, all the latest issues we had and which were fixed, almost all the time were related to current register allocator. So rewriting it can be also resulting in auto-fixing other bugs that we had now. But maybe it better to fix all bugs with current register allocator, and only after moving on a new one if Hans decides to do so at all of course.
But surely Nova pretty advanced already, taking into account that Hans alone works one, together with Radeon drivers :) Who imagine that we will for real have all those OGLES2 (which is pretty much advanced too), and 3d party apps too like shaderjoy and glsnoop :)
I was watching Kas1e's awesome video and I thought how cool that would be to have such graphics as backgrounds, something like CANDI... Is it possible?
surely Nova pretty advanced already, taking into account that Hans alone works one, together with Radeon drivers :) Who imagine that we will for real have all those OGLES2 (which is
Yeah, Nova + OGLES2 combo is really appreciated here and it's quite amazing what these guys have achieved.
Quote:
pretty much advanced too), and 3d party apps too like shaderjoy and glsnoop :)
I'm sure there will be more apps coming this year.
But surely Nova pretty advanced already, taking into account that Hans alone works one, together with Radeon drivers :) Who imagine that we will for real have all those OGLES2 (which is pretty much advanced too), and 3d party apps too like shaderjoy and glsnoop :)
.. and the constantly updates to SDL1 and SDL2 .. you for sure did not forget them considering the heavy test you did ;) 3 or 4 good developers and a bunch of decent testers can improve things a lot, indeed it's good moment for OS4
@Capehill Here's one entry of my wishlist if you don't mind Apparently Shaderjoy's verbose logging only spits out the shader-log if an error occured. I think it would be better if you'd always print it in "verbose" mode (maybe check GL_INFO_LOG_LENGTH).
@Capehill Great, thanks IIRC you have beta access to my FTP (if not, drop me a PM). If you want you can already download the fresh includes and the beta ogles2 3.0 lib from there and already implement support for two new aglCreateContext / aglSetParam options:
- OGLES2_CCT_DEBUG_SHADER_LOG: If set to TRUE then the library asks Nova for extra shader compiler info. A detailed log will be returned even on successful shader compilation. If this flag is set to FALSE (default) then only the usual standard error log will be returned.
- OGLES2_CCT_DETECT_UNINITIALIZED_GLSL_VARS: If set to 1 or 2 (default 0) then ogles2.lib will analyze the generated SPIR-V code and look for uninitialized shader variables. If set to 1 then it will only put a warning in the log and continue, if set to 2 then glCompileShader will return with an error if something suspicious is being detected.
Note: OGLES2_CCT_DETECT_UNINITIALIZED_GLSL_VARS is beta, I wrote it yesterday. It's certainly not perfect (altogether less than 150 small lines of code, incl. the SPIRV parser, no kidding ) but seems to do a decent job so far - obviously not tested toooo much though. So if you encounter a shader which gives wrong results, throw it into a mail or on my FTP please. You'll also find an updated glslangvalidator_redux on my FTP which has that feature.
Edited by Daytona675x on 2020/6/6 15:28:46 Edited by Daytona675x on 2020/6/7 16:26:11 Edited by Daytona675x on 2020/6/7 18:05:53 Edited by Daytona675x on 2020/6/7 18:11:20
@Capehill Great, thanks, looking forward to 1.9! You may want to download another fresh lib version. More optimizations for the SPIRV uninit var detector, resulting in even higher performance and less C++ code (now 159 tiny lines incl. class defs, no STL, no clib, just one dyn memory allocation (plus those for the warning string, if there's any)). I'm really curious if you can even measure any glCompile difference between enabled / disable var checker.
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
