GodotRetro is a twenty two shader pack for two different Godot renderer paths

One pack, two renderer paths, and the difference matters

Godot Retro is a pack of retro compositor effects and shaders for Godot, with various ports of shaders from ShaderToy, Unity and The Book of Shaders. The primary language of the repository is GLSL, and the default branch is 4.x, with a separate 3.x branch kept for people who need a version compatible with the older engine.

The installation instructions split by renderer, and that split is the first thing to understand.

For the Forward+ and Mobile renderers, the effects are compositor effects. You create a Compositor inside your WorldEnvironment, and when you add a new CompositorEffect, the list of all available effects appears automatically once you have imported the GodotRetro plugin.

For the Compatibility renderer, the same shaders are delivered as materials instead. You copy the GodotRetro folder into your project, anywhere in it. For a normal shader, you add the shader to a ShaderMaterial. For a screen space shader, you create a ColorRect, set it to FullRect in the Layout options, and assign the shader of preference to a ShaderMaterial in that ColorRect.

So the choice of renderer decides how the pack is wired in, and a project that has to support both will find itself maintaining two integration paths.

The pack is also published on the Godot asset store, and the repository itself is small, with an addons/ directory, a project.godot file, the README and the licence.

Stacking effects means adding a BackBufferCopy per effect

The two disclaimers at the end of the installation section are the part that will cost you an afternoon if you skip them.

The first is that to use two or more shaders at the same time, you need to use a BackBufferCopy set as a Viewport for each effect. That is a Godot scene node, and the requirement exists because each effect in the chain needs its own copy of the screen to work from, since the previous effect has already modified what is in the frame buffer.

The second is about the user interface. For UI, you need to set it above the shaders in the node hierarchy for the interface to be affected as well, which is what the README calls more immersion.

Both of these are consequences of how the effects are composed rather than arbitrary restrictions, and the fact that the README states them at all, in a plain disclaimer list rather than in a tutorial, suggests they are the part people forget.

There is a third piece of advice in the same spirit, in Tip 5, which says to always check the headers inside the shaders you are using, because the information about compatibility, credits and licensing is in there. That is the file to open before you commit to an effect for a shipped build.

Twenty two effects, and the advice to combine them

The README lists the shaders in the pack, and the naming makes the coverage obvious: CRT Simple and CRT Complex, TV, VHS and VHS Pause, Dithering, Posterization Simple and Complex, Glitch Simple and Complex, Grain Simple and Complex, Lens Distortion, Monochrome, Sharpness, Color Correction and PSX (Spatial). The features section counts twenty two easy to use Godot shaders, alongside five well done example projects.

What is missing from that list is telling too. There is no palette quantisation, no CRT aperture grille mask, no scanline shader with adjustable beam width, and no shader for the phosphor persistence trails that a real tube has. The pack is built from ports of effects that already existed elsewhere, and the original ShaderToy versions are credited individually in the Credits section, by author, with several of them from ShaderToy and a couple from GitHub.

The README's own recommendation is that the shaders look better when they are combined, and it gives two examples. One scene uses Lens Distortion plus Grain plus TV, and another uses Lens Distortion plus Sharpness plus NTSC.

The tips make the trade-offs concrete. Sharpness is described as a must have if you use the TV, VHS or NTSC shaders, because those effects blur the image and the sharp pass restores the edges. Lens Distortion combined with a high field of view is said to give an MTV 2000 blumbers aesthetic. And Grain is the one to be careful with, because it can get messy easily.

One more tip matters for anyone who wants to go further: all the shaders can go beyond their default range values, by opening the shader code and changing the numbers inside the hint_range() function in the variables section.

CC0 for most of it, MIT for four shaders

The licence is split, and the split is the kind of detail that has to be read before a pack ships inside a commercial game.

All the shaders are licensed under CC0, with the exception of the Glitch and the NTSC Basic shaders, which are licensed under MIT. In the example scenes, the models, scripts, textures and sounds are all under CC0. There is one more exception in that group, since the shrWind shader used in map 4 was made by Maujoe and is licensed under MIT.

So the pack is almost entirely public domain, with two shaders under a permissive software licence. The badge in the README header says CC0 and MIT, which is accurate, and the GitHub classification of the repository licence is recorded as a custom one that cannot be categorised, so the LICENSE file in the tree is the text to read.

The MIT-licensed shaders are not a problem for a commercial project, since MIT requires only that the notice is kept, and unlike a copyleft licence it does not reach into the rest of your project. The credit list in the README is what a careful adopter should keep anyway, because the pack is largely a redistribution of other people's work and the original authors are named one by one.

The Tip 5 instruction to check the headers of each shader is consistent with that, since the header is where the specific licence and the original author for that effect are recorded.

The five examples are the documentation

The pack ships five free and easy to learn example projects, and the README documents their controls rather than describing the scenes in prose, which is the more useful choice.

The general control is ESC to quit the game. Map 1 is driven with W, A, S and D to move forward, turn left, go backwards and turn right, with E and Q to walk left and right, and Shift to run. Map 4 is simpler, with A and D to move left and right, and that is the map that uses the shrWind shader.

Reading the control tables tells you the shape of the examples: one is a movement and camera test, one is a side to side scene, and the other three are demonstrated in the video captures embedded in the README rather than in the tables.

The examples are also how you find out what the pack actually looks like in motion, since a shader screenshot tells you much less than a recording of a scene with the effect applied. The repository's media are the screencasts, one of which is a video to GIF converter demo, and the README embeds them as short loops.

For an adopter, the practical sequence is to open an example, note the combination of effects in the compositor or the material, and then reproduce that stack in your own scene. The examples are the reference implementation of how these effects are meant to be combined.

The web export caveat, and where this pack is the wrong choice

The Limitations section is short and honest. Some shaders are not 100% perfect, and some shaders may not work in the web export, with the instruction to check each used shader's code header for more information.

That caveat decides the question for a browser game. A pack of screen space effects that are meant to be combined, each needing its own BackBufferCopy viewport, is already a heavy arrangement, and the README is telling you that some of the effects will not survive a web export. A project whose target is the browser should treat this pack as a starting point to port, not as a drop in.

The second case is a game that needs one coherent look across many scenes. The pack's own guidance is that the effects are best in combinations of two or three, and that the combination is what produces the result. That is a per scene decision that somebody has to keep making, and a large project will accumulate inconsistent looks unless someone owns that.

The third case is a team that wants a specific effect done properly rather than approximated. These are ports of ShaderToy and Unity effects, which is exactly the right approach for a retro look that matches what people remember, but a bespoke look, or a CRT simulation that responds to the game's own colour palette, is a different job.

Used as intended, with one or two effects per scene, the pack is a fast way to get a credible retro presentation without writing GLSL, and the permissive licence is what makes it easy to ship.

Editorial conclusion

GodotRetro fits a Godot developer who wants a CRT or VHS look without writing a single line of GLSL, since the pack covers the common retro effects and ships five worked examples, and the licence is permissive enough for commercial work with a short attribution list. It is the wrong choice for a project that only runs on the web export, because the README warns that some shaders may not work there, and it is the wrong choice for a game that needs a coherent look across many scenes, because the pack's own advice is that the effects are best combined in pairs and triples, which is a look you can only maintain by hand. Before adopting it, check the shader header for the one you plan to use, because the README points there for compatibility, credits and licensing, and pick the installation path that matches your renderer.

Frequently asked questions

Official sources

1. ahopness/GodotRetro on GitHub
2. Issues
3. Project website
4. README
5. Releases