Indigo Dev Log 1: Rethinking Indigo's Renderer
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..
A brief history of Indigo’s renderer
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.
Indigo’s roadmap
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.
Progress report
What I have already is the foundations:
- An infinite number of non-specialised layers (no more fixed named layers)
- New syntax to describe layer blend modes
- The ability to write completely custom scene entities
- The ability to write custom shaders
- Some prebuilt entities and shaders that work similarly to the existing primitives
- The tentative beginnings of work on shape primitives
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.
Questions without answers (yet)
- The next release will include new features Indigo has never had before, will it also have all of the features of the previous versions?
Undecided. I think I shall aim for feature parity but some things may not make the cut.
- Will Indigo continue to support Scala 2?
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.
- Will Indigo continue to support WebGL 1.0?
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!
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