Skip to content

0.16.0

Compare
Choose a tag to compare
@davesmith00000 davesmith00000 released this 07 Jan 22:04
· 158 commits to main since this release

Great to have a couple of contributors on this release, thank you for your help @JPonte and @mprevel, much appreciated!

As usual, this release has been driven by using Indigo, finding problems, and fixing them.

Noteworthy changes

Scala.js 1.15.0

All newly release Purple Kingdom Games libs are now on Scala.js 1.15.0, and Indigo is no exception.

Electron Executable option is now working properly

This was a tiny fix that is worth it's weight in gold. By default, when you use the indigoRun command to run your game via Electron, your build will install the latest version via NPM and then run. This works ok, and gives you the latest and greatest Electron version with almost no effort on your part.

The only problem is that NPM will try to check the install is up to date on every single run, slowing down development.

What you can now do instead, is install Electron by some other means, e.g. yarn add --dev electron, and then add the following line to your build's IndigoOptions:

.useElectronExecutable("npx electron")

This does the local install manually just once, and then just reuses it with no installation checks, resulting in much faster game start times.

Polygon shader fixed!

During the original port to Ultraviolet, a mistake was made in the polygon shader translation from GLSL to Scala 3. This has now been corrected by @JPonte.

Tyrian / Indigo bridge

The Tyrian / Indigo bridge is a module that allows Tyrian web apps to communicate with embedded Indigo games.

The release of Tyrian 0.9.0 removed the tyrian/indigo bridge module in order the correct the library dependency order.

This module is now published with Indigo, and so follows Indigo version scheme, i.e. it has jumped from 0.8.0 to 0.16.0.

Improved PathFinder

This is the first release of a new A* PathFinder by @mprevel. It is both more flexible and more correct than previous attempts!

Please note that the old, suspect SearchGrid implementation has now been marked as deprecated, and will likely be removed soon.

Improved Physics Scene Scaling

Indigo includes a rudimentary physics engine that is squarely aimed at pixel art games and nothing more. It uses discrete rather than continuous simulation, and so suffers from issues like tunnelling (to be addressed in future updates), but nonetheless is good fun and quite helpful.

Previous versions did not scale well as the simulation had no 'broad phase' to cull unnecessary collision comparisons. This has now been fixed, allowing for much larger simulations.

Adding this new phase has required some changes to the API:

  1. Worlds are now bounded, i.e. you will need to provide a BoundingBox covering the simulation area.
  2. You must also supply a SimulationSettings instance as part of the world set up, that gives clues about the size and density of the simulation.

Physics: Transient colliders are static

Another change is that transient colliders (colliders that only exist in this frame and are not officially part of the world instance, typically user controller) are now treated as static in all cases, and you no longer need to set them as such.

Physics: Collider Terminal Velocity

You can now set a terminal velocity on your colliders. This gives you much better control over how your game's play, and helps reduce the possibility of tunnelling.

Bresenham's line algorithm

Bresenham's line algorithm is a useful tool for working out a line across a grid with no overlapping squares. Super handy for drawing pixel art lines or lines of sight across a grid.

There is now an implementation of the algorithm in the Indigo extras library, that was ported from the Roguelike-Starterkit:

indigoextras.utils.Bresenham.line(from, to)

QuadTree overhaul

QuadTree's are data structures used to store spatial data so that it can be quickly queried. QuadTree's are now the underlying data structure used to allow the physics engine to scale.

There has been a "QuadTree" implementation bundled with Indigo in the extras package for many years now. It was based on work done in Indigo's core that handles the texture atlases. Unfortunately, borne out of that very specific use case, it wasn't a true QuadTree, and could only handle data associated with vertices, and then only one entry per leaf, leading to some interesting design choices. What it ended up being used for, in a number of places, was actually not a query-able tree at all, but a sort of sparse data look up for grids.

The QuadTree implementation has now been totally re-worked to meet the physics use case, and can now support data stored against all of the standard spatial types, i.e. Point, Rectangle, Circle, BoundingBox, BoundingCircle, LineSegment, and Vertex, or any custom type with a SpatialOps instance. The implementation is also much more robust, and can store many entries at the leaf level. How many entries and how deep the tree should go is specified by you.

All this change has resulted in a substantial API rethink and the behaviour is now significantly different. QuadTree's are also now part of the main Indigo library, not the extras package.

SparseGrid

The use case that the old QuadTree's was fulfilling as a sparse data grid was a real need, and since QuadTree's can no longer meet that requirement, a new data type has been made, cunningly named: SparseGrid!

SparseGrid is a straight-up grid data structure, that provides a nice API for managing the data in that grid.

Minor bug fixes and improvements

  • BoundingBox.resizeBy now takes Doubles instead of Ints
  • Fixed #658: Large box overlap of small circle check
  • Vector2/3/4 all now have a clamp operation that takes the same type, i.e. you can clamp a Vector2 with another Vector2.

Generated notes below

What's Changed

New Contributors

Full Changelog: v0.15.2...v0.16.0