This release is a total rewrite of Indigo’s rendering process to make it flexible and customisable.
Full details of this release with migration notes can be found on github.
(The diagram above attempts to show how this release has changed the rendering process.)
Thought I’d try a different format this time to see if I can make it easier to write these things. Hopefully it will encourage me to do it more often. Aiming for a sort of agile / stand-up / update format.
Next version is coming along nicely, lots of new exciting stuff going into it. The only technical hurdle ahead of me is to reimplement dynamic lighting, and hopefully make it better! After that I’ll begin prepping the next release.
Scala 3.0.0-RC1 & Scala 2.13.5 - Many thanks to auman for upgrading Indigo to the latest Scala 3 version!
Shapes! - A first version of shapes is now included as standard. There’s A LOT you can do with shapes conceptually, this first version is a limited functionality release to test the water. It contains Circles, Boxes, and Polygon’s that support borders of arbitrary thickness and can be filled with solid colours or linear / radial gradients. Worth noting that these shapes were initially implemented with the new custom shader mechanism - so if you know GLSL there’s nothing stopping you going the full Freya! (Note: If you do, I’d love a PR!! :-))
Custom Shader Data - Ability to supply custom data to your shaders.
Blending and BlendMaterials - As well as entity shaders, you can now write shaders that control how layers blend together, enabling things like simple post processing effects. You can also control hardware blend functions. This arrangement has been used in combination with entity shaders to re-implement the old image based lighting layer functionality, but now you can have as many lighting layers as you like.
Reimplemented screen effects as layer effects - The current Indigo version allows you some basic fixed post-processing effects. This has been reimplemented and expanded using the BlendMaterials mentioned above. One big difference is that the effects are layer level, as opposed to screen level, and you can optionally apply the effects to only the current layer or to the merged layer stack (below the current layer).
Reimplemented legacy effects - The old border and glow effects, which are quite cheap and I suspect of limited use, have been reimplemented just in case anyone is depending on them. However they aren’t built into Indigo by default any more, you need to add them from the extras library.
Reimplemented Distortion layers as Refractions - Not only reimplemented but also slightly improved. In the same vein as effects, I’m not convinced this is up to scratch quality wise and so I’ve moved it into the extras project. The implementation is achieved using entity and blend materials.
The current work in progress is to reimplement and improve dynamic lighting. The two improvements specifically are (hopefully):
Rethink how specular lighting is handled, a mistake was made during the original implementation that I’d like to correct.
Ambient lighting will no longer rely on image based ambient lighting.
There is also an unresolved question about whether lights will be global, layer based, or both. As it’s a forward renderer, there will be a light count limit in the next version (which shouldn’t be a problem for most use cases), so if you had global + layer lights that went over the limit, which should take priority? I’m sure I’ll think of something.
It’s unclear how much effort this will be as Indigo has moved from being an inflexible deferred renderer to a programmable forward renderer. But I’m hopeful it will be in the order of days rather than weeks.
Essentially release prep, however, a lot has changed in terms of the APIs and how Indigo works. So the plan is the work through the various demos and example projects, and while I upgrade them, take down migration notes, and re-assess the API choices I’ve made to see if I can make them clearer or reduce the impact of change.
Thanks for taking the time to read this little update. Looking forward to getting the next version out and seeing what people make of it. I'd also like to say thank you the expanding cast of people supporting the project. Whether you are helping financially, contributing code and documentation improvements, or just being around to help discuss ideas: It's all very much appreciated!
Dave
The current work in progress is to re-think Indigo’s rendering pipeline. This isn’t the first time I’ve gone back to the drawing board, but it is the first time since Indigo’s launch. Since this is going to mean a bit of a longer wait between releases than usual, I thought I ought to explain what’s happening and report on my progress so far..
I don’t know how interesting this is but I feel like the context is important.
Back in 2016 I wasn’t even sure if it was possible to make a usable game engine in Scala, but I was confident that there was a minimal feature set that I would enjoy that might be achievable, as long as I kept it small. Really small.
Pixel-art only, something that approximated blitting operations. No arbitrary shapes, scenes, real fonts, special effects or shaders or anything, not even rotation. Something you could just about build the original Mario with.
Graphics rendering is complicated, but the great thing about a super minimal set of rendering requirements is that the pipeline can be specialised and focused, which is easier than building something more general purpose. Indigo was not as fast as it could have been I’m sure, but it was/is able to draw decent numbers of on screen elements while retaining a pretty solid performance profile.
Reliable performance for low effort felt important to me because, I reasoned, most people coming from Scala were likely to be new to game building, and I didn’t want them to be too worried about performance tuning.
The problem is that at the point of Indigo’s initial launch, this renderer design was basically maxed out in terms of how many graphical features I had the ability (as an amateur) to push through such a constrained pipeline.
I don’t like to nail down roadmaps too firmly as a rule. I work on the principle of having a mirage on the horizon that I can use to give me a bearing in case I think I’m losing my way, but I don’t worry too much about the exact destination or the route I‘m going to take to get there. The only real detail in the plan is of the work I’m doing right now, the next step on the journey.
I try not to look up from my feet too often in case I find the length of the road ahead off-putting.
What does the vague impression in the distance look like at the moment? Well, I think it looks a bit like a GUI editor for Indigo. What kind of editor? What features will it have? How will it work? Will we ever reach that goal? Who knows! ...and it doesn’t matter, it’s just a direction to head in.
To move in the direction of that goal there are a few obvious and chunky things that Indigo needs, like the ability to draw arbitrary shapes, a more flexible layers system, and possibly better/real font support to name but a few.
To do any of those things means having a more sophisticated rendering pipeline that can cope with things like custom shaders, and that in turn means a rethink of the renderer.
So that’s what I’m doing.
What I have already is the foundations:
Safe to say that the next release will feature many breaking changes, but I’m planning to write migration notes of some kind.
One of the major philosophical differences that the next release will introduce, is that the game developer will be much more in control of performance. Fewer rendering requirements will result in faster performance, but if you wish, you’ll also be able to trade off raw speed for much more sophisticated rendering.
My aim is to keep the new renderer as beginner friendly as I can, but also to allow people to explore more advanced rendering techniques.
Undecided. I think I shall aim for feature parity but some things may not make the cut.
Scala 2 is still important because the dev tooling around Scala 3 hasn’t (unsurprisingly since it hasn’t been released yet) caught up with the Scala 2 experience yet. But once the tooling is better, could Scala 2 just be dropped? Since there is no-one depending on Indigo for their business or livelihood, the usual library support / backwards compatibility considerations don’t really apply here, so it might be reasonable.
However unless Scala 3’s tooling is much better before the next release (possible...), it’s likely that the next release will support Scala 2, just not guaranteed.
Maintaining WebGL 1.0 and 2.0 is effectively maintaining two completely different renderers, which is a lot of work for one person. Also worth noting that sooner or later I’ll need to look into supporting WebGPU too.
At the time of writing all the new work is happening in the WebGL 2.0 renderer, and I don’t know how feasible back porting it will be.
The performance of WebGL 1.0 is far worse than WebGL 2.0, but it’s market/browser penetration is near 100%, where WebGL 2.0 is closer to 75% with big names like Safari conspicuously missing (Safari tech preview version does add support). However, WebGL 2.0 is probably available everywhere that you’re likely to find a gamer that wants to play your game, so does the other 25% matter? Hard to say.
One option, rather than removing WebGL 1.0 support altogether is to reduce it to a bare minimum, so that it’s just about good enough to inform your players to try a different browser or platform. Would that be acceptable? Your guess is as good as mine.
Thanks for taking the time to read this update. If you have any questions or would like to discuss any of it I can usually be found on our Discord channel.
Dave
