@Capehill Yeah, in 1.21 those shaders start to works again as well as project files support matured enough now and work as expected in all conditions I tried.
Home in next day or two make that big shaders-pack upload
@Capehill Not sure if it is worth of worry about, but just in case: we have now "auto-update" of the shaders in shaderjoy - i.e. we load one, and if we in realtime overwrite it (like by writing a new version on top of the current one), then it auto-compiles and new version start to renders. That fine and good.
But shouldn't we have the same for ".sjp" files as well then? Seems currently no, but I not sure if that for real need to changed, just noticed it while testing now...
@Capehill I finished cleaning and sorting and testing that big shaderjoy database! Check the news items, and thanks for your never ended work on ShaderJoy (and SDL, and glSnoop, and whatever else you works on:) )
It's currently only possible to switch between Debug And Info by using the VERBOSE flag. Maybe something to improve in version 1.22.
Quote:
I finished cleaning and sorting and testing that big shaderjoy database!
Yay! I will test it later today. Thanks.
@khayoz
You are welcome!
@TSK
Some shaders are heavy but it's sometimes possible to tweak them slightly to make them faster without losing too much quality. For example, decrease some for-loop counters or remove anti-alias or things like that.
Many of the textures for the various demos available in the latest ShaderToy Pack seem to have rendering issues on my A1222. In fact nearly thirty-percent of them don't render correctly; points or flares render as lines. The best illustration of this is "The Eye," but I can point to many others. I'm running the latest OpenGLES and Warp3DNova libraries from A-EON as well as RadeonRX 2.5. The video card is a Radeon RX560.
I should say that everything renders just fine on my X5000, so the issue may be the FPU emulation layer on the A1222 -- but thought you might know what this is.
-- eliyahu
"Physical reality is consistent with universal laws. When the laws do not operate, there is no reality. All of this is unreal."
@elihauy Tabor have a lot of issues with 3D and very big slownes when it come to 3D stuff. That surely need to be taken into account by those who adapt all the things for Tabor. And still i not sure, that in our little developer-base, developers will made special SPE based tabor versions. It all need to be deal inside of the OS coming with Tabor.
It seems that the screenshot functionality is broken. It tries to save PNG but files seem to be actually ILBM (says Multiview). Is it actually possible to save PNG files using system datatypes?
if (ncols)
{
GetDTAttrs (o,PDTA_ColorRegisters,&cmap,PDTA_CRegs,&cregs,TAG_END);
GetRGB32 (vp->ColorMap,0,ncols,cregs);
for (i = 3*ncols; i; i--)
*cmap++ = (*cregs++) >> 24;
}
if (fhand = Open (name,MODE_NEWFILE))
{
i = DoDTMethod (o,NULL,NULL,DTM_WRITE,NULL,fhand,DTWM_IFF,NULL);
Close (fhand);
if (i)
Error = FALSE;
else
Delete (name);
}
Thanks, no breakthroughs yet. I am not able to save jpeg, bmp or tiff either.
Yesterday I wanted to upload an image to Amigans.net and then I noticed that there is some issue with my "png" files and files were too large for upload.
Maybe with OS4 default datatypes you can’t save in all picture formats because there’s full support only for load. Use iff ilbm format, it’s our standard for pictures. We are amigans we have our peculiarities
@Capehill it is most likely a matter of what datatypes you are using warpPNG, akPGN or PNG, some .datatype libraries support writing some don't, if we go back to the commodore days the datatype system was only meant to write the default format (FTXT, 8SVX, ILBM)