This is a loading screen filter that I put together for my project and for the community. It includes many options to customize it, all of which are documented in the readme. The readme contains a lot of information for a simple 2D filter (or not so simple as it turned out). I also included information for people who are not as familiar with programming.
You can check it out in this video, but it looks better at 60 fps rather than the 30 fps I recorded it at.
The code is still a little messy, but its manageable.
I recommend only trying it in the standalone player (currently set to 1920x1080). The embedded player doesn’t want to display it right. Also if you are going to use this on a platform other than windows you might need to check out the readme for more information (I recommend checking it out anyway).
Edit: Updated - I had completely forgot about time.monotonic() until agoose77 made me remember on someone else’s thread, ha! There should be no problems for any OS now.
I have only tested this on Windows 7 x64 with an Nvidia card…
I might put together a version that is attached to a plane (full shader) instead of a 2D filter. Wouldn’t be too hard, depends on whether or not the community wants it.
Very nice. I’ll be taking a look, I’m sure there’s a lot I can learn from this.
EDIT:
It already make think about the structure of such a script. There’s been times in the past when I wanted to add a virtual object (for example some simple particle) in the script, but ended up feeding screen co-ordinates as a uniform. I guess you could keep the virtual object (like a rolling ball) in the shader, as long as every pixel calculated its position each turn and you could be sure each would reach the same conclusion about the possible simulated location of the virtual object.
Which would be faster though? modeling the object’s movement in python then feeding the screen co-ordinates in to the shader, or calculating the balls within the shader?
@Smoking_mirror: A lot of what you ask really just depends on what you are trying to do. For a lot of calculations (parallel calculations at least), the GPU is faster than the CPU. Because of this keeping calculations on the GPU in a complex scene can be beneficial; as each time it needs to fetch information from the CPU, the GPU has to stop and wait on the CPU.
However, if you are needing only one calculation done per frame, it might be beneficial to calculate it before it is sent to the GPU. A busy fragment/pixel shader might do that same calculation for every pixel in the screen in addition to whatever else it needs to calculate. That is the same calculation, potentially, 2,000,000+ times per frame - not very efficient…
@adriansnetlis: Without some kind of error I can’t really help. If there are no errors being thrown, I would have to point to your drivers as the culprit, since we know those are causing issues for you.
Nvidia:
//----------------------------------------------------------------------------------------------------
0(58) : error C7102: unmatched #else
0(61) : error C0122: #else cannot follow #else
0(156) : warning C7623: implicit narrowing of type from “vec2” to “float”
Error Totblock: 24
//----------------------------------------------------------------------------------------------------
errors in the preprocessor definitions if loop?
#ifndef randomColors
#define cycleColors //randomColors must be off - colors change at random -> turn this option off to set specific color below
//
#ifdef cycleColors
const float fac = 1.25; //larger values increase brightness
//
#else
const float fac = 1.25; //larger values increase brightness
//
#endif
//
#else
const float fac = 1.0; //larger values increase brightness
//
#endif