Skip to content

0.15.0-RC1
Compare
Choose a tag to compare
@davesmith00000 davesmith00000 released this 15 Apr 21:37
· 489 commits to main since this release
v0.15.0-RC1
6b3686f

Release Candidate

This release is expected to become a full release of Indigo 0.15.0, as long as no serious issues are discovered in the next few months.

It's been over six months since the last release of Indigo, but that is a reflection of the magnitude of the changes the engine has undergone. The aim of all this work is eventually to break Indigo away from being reliant on Scala.js and WebGL, so that it can move onto new platforms like WebGPU, and one day Scala Native / JVM. There is much more work to do, however.

If you're excited about that work, please consider contributing to or sponsoring the project.

New / Noteworthy stuff!

Ultraviolet Support

This is the bulk of the change in this release. Indigo no longer has any GLSL code in it, all of its shaders have been rewritten in Scala 3 using Ultraviolet.

Ultraviolet is an early and slightly rough around the edges DSL + macro that converts Scala 3 into shader code, and at the moment that code is GLSL flavoured. However in the future, the aim is to expand the output formats to support other shader dialects allowing Indigo shaders to work on other platforms. There is more work to do here, but it really does work!

From an end user perspective, if you aren't writing custom shaders then you shouldn't notice any difference. If you have written custom GLSL shaders, these will still work, you just need to be aware of one change, which is that two of the standard function hooks must now take an argument and return a value.

These functions:

void vertex() {}
void fragment() {}

Must now be:

vec4 vertex(vec4 v){ // where v is the vertex as calculated so far...
  return v;
}
vec4 fragment(vec4 c){ // where c is the colour of the fragment as calculated so far...
  return c;
}

The other standard hooks of composite, prepare, and light are unchanged.

You can use Ultraviolet to write shaders for Indigo in two ways:

  1. As generated source code in a Source shader, which just takes a string.
  2. Using the new UltravioletShader shader type.

Full documentation will be provided at some point in the near future (hopefully), but at the moment the Indigo website is undergoing a rebuild. In the meantime, please refer to the Ultraviolet repo, examples that are being produced, and come and ask questions on our Discord server.

Pointer support

Huge thanks to @grzegorz-bielski for adding support for pointer events, allowing Indigo games to response to touch inputs on things like phones and tablets. This is also an overhaul of mouse input events. The work is a combination of a new set of Pointer events, and Pointer state in the InputState object in the FrameContext.

Frame Rate Limiter

The framerate limiter has never worked. At various times it was thought to work but didn't. In a nutshell this is because the browser chooses when a frame will be rendered, and any attempt to massage or throttle that time is an uphill battle.

However! The frame rate limiter (err... once again?) now works! And this is very important, so much so that a previous change to disable it by default has been reverted and new games are limited to 60fps by default.

What is behind this move?

  1. Improved electron performance.
  2. VSync.

If you're using Electron, then in an Indigo game's build you can tell Electron to disable it's frame rate limiter. In older version of Electron this does not present a problem, but in newer versions the performance has improved significantly, and you can now get frame rates in excess of 1000 fps! (On a simple game doing very little, with up to date graphics drivers, and so on and so on...)

Unfortunately at these high frame rates strange things begin to happen, so as a recommended default, it's been capped to 60 fps. You can still turn it off if you so wish.

The other reason is vsync. VSync is when your graphics card updates your game at the same rate as your monitor. For a pixel art game of the kind Indigo was designed for, 60 fps is ...lets just say it's ample, but if your game is running in a browser and the monitor has a 144 refresh rate, then your game will try and run at 144 fps! More than double our recommended cap of 60. Bear in mind that this doesn't just update your rendering, but also all your model processing and so on, which is needless work.

So again, the default has now been capped at a sensible 60 fps.

You can modify the framerate limit or disable it as you wish via your GameConfig. Existing games are recommended to enable it at some specific frame rate rather than just leaving it to peoples machines to decide.

Improvements!

General Shader Improvements

  1. Custom/Blend UBO offsets have been reviewed and we've been able to make more room for custom data UBO's, meaning you can now send more data to your shaders.
  2. The binding of the VERTEX variable now happens in a different place, so that in general you need only manipulate UV's in vertex shaders without needing to worry about how that translates onto texture atlases. (There is more work to do here to make this stuff easier...)
  3. The ShaderData APIs such as UniformBlockName and the various data types have seen a range of improvements, and there are more helpful conversion extension methods now under the indigo.syntax.* and indigo.syntax.shaders.* imports.

BlankEntity

A new super simple BlankEntity primitive has been added. This is for all you shader writers out there. BlankEntity is a way to describe a space on the screen with nothing in it, that you can then draw to using a shader.

This was made for the IndigoShader game type described below, but in fact has more general purpose uses.

IndigoShader game type

Along side the existing IndigoSandbox, IndigoDemo, and IndigoGame game types, we now have IndigoShader. Again this is aimed at people who just want to practice writing shaders for fun. You can see a few examples of it in use in this repo.

Essentially this is a new game type with a pared back API that only renders a single shader that fills the window, somewhat like the brilliant ShaderToy.

Other bug fixes and improvements

Here are some of the general improvements in this release. These have been made to smooth out development and were generally discovered while working on a new demo.

  1. The confusing sceneTime has been replaced with sceneStartTime and sceneRunning.
  2. AudioPlayer now throws when an asset is missing, to avoid confusion as to why your audio isn't playing.
  3. Transparent backgrounds really are transparent now!
  4. Added withSize and withPosition to Rectangle.
  5. Improved and expanded local storage events.
  6. Add Dice.rollRange helper
  7. Indigo's sbt and Mill plugins now support fast/fullLinkJS
  8. Added Outcome.fromOption and syntax improvements
  9. You can now multiply Point / Size / Rectangle by Doubles
  10. You can construct SceneUpdateFragments from Batch/Option of Layers
  11. Bug fix: Volume of a playing track can now be changed! 🤦
  12. Improved asset loading
  13. Ability to query timeline animations for their length
  14. Added Timeline.atOrElse, timelines return an optional value, and this helper allows you to quickly ensure you always get something back.
  15. Added Timeline.atOrLast, when a timeline ends, instead of vanishing, the last frame continues to be rendered.

What's Changed

New Contributors

Full Changelog: v0.14.0...v0.15.0-RC1

Contributors

davesmith00000 and grzegorz-bielski
Assets 2
Loading