XScreenSaver 6.14 is out now, including iOS (soon) and Android. A whopping eighteen new savers this time! As I mentioned last month, I wrote a new XScreenSaver module that is API-compatible with Shadertoy, which means that I am now able to pull demos written that way into the XScreenSaver fold. These 18 savers are the first of that batch.
A limitation here is that I can only redistribute Shadertoy-derived savers that have licenses that are compatible with the rest of XScreenSaver.
The default license on shadertoy.com is “CC-BY-NC-SA”, and so the vast majority of uploads use that. However, that license, by prohibiting commercial use, is not an open source license, and is more restrictive than the license used by the rest of XScreenSaver. For a Shadertoy saver to be distributed with or within XScreenSaver, it must be licensed under a compatible license, such as: MIT, BSD, CC-BY, CC-BY-SA or CC0.
So this first batch of 18 new savers are the ones that I was able to find that were both interesting and compatibly-licensed.
If you know of other cool Shadertoys that use one of the above licenses, please send them my way, and maybe I’ll include them in a future release.
Likewise, if there are some others that are really good but that are not compatibly licensed, let me know about those as well and maybe I’ll ask the author if they’d be willing to relicense them for inclusion. It’s worth a shot.
(XScreenSaver does not, cannot and will not load the savers from shadertoy.com directly, because reasons, so let that idea go.)
One odd thing that you may notice about these is that they are oddly static as far as screensavers go, which is to say that despite their complexity, they draw the exact same scene every time. Most things written for Shadertoy generate each frame based on time-since-launch, without any mechanism for external sliders, or a random number seed. That’s just how they’re written.
Anyway, about the new XShaderToy framework that powers these new savers:
You may find that performance sucks on your machine. That means your GPU is not good, oh no. In particular, the Raspberry Pi 4b sucks at running most of these. Crank down the “Resolution” slider for a better frame rate.
To make these work in the wider XScreenSaver ecosystem, I had to target four different versions of GLSL that are all stupidly and arbitrarily incompatible with each other, both in the set of available library functions, and in basic syntax of the language such as the type promotion rules and whether integers exist.
Linux: An OpenGL “compatibility profile” context anywhere from 3.1 to 4.6. Pi is 3.1, some other Linux devices are other versions.macOS Cocoa: An OpenGL 4.1 “core profile” context, which means no backward compatibility affordances for earlier versions.macOS X11: OpenGL 2.1, yes, 2.1.iOS: OpenGL ES 3.0. Note that “OpenGL ES 3.0” is not “OpenGL 3.0”, it is “WebGL 2.0”. This is all completely sane and normal.Android: An OpenGL ES context anywhere from 3.0 to 3.2.
So I had to write a bunch of compatibility shims to, for example, make code written to the “OpenGL ES 3.0” API able to run on an “OpenGL 2.1” system. And it’s a complete shitshow. Maybe it will work, most of the time. Huge thanks to Carsten Steger for helping me understand this nonsense.
And of course thanks to the original authors of these “new” savers for putting there work out there, and under compatible licenses: mrange, otaviogood, nemerix, kali, jaszunio15 and 3w36zj6.
Previously, previously, previously, previously.
From jwz via this RSS feed