0.16.0
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:
- Worlds are now bounded, i.e. you will need to provide a
BoundingBox
covering the simulation area. - 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
Double
s instead ofInt
s - 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
- minor improvements by @mprevel in #645
- Fix Polygon shader by @JPonte in #654
- Update sbt to 1.9.8 by @davesmith00000 in #655
- Issue #656: Move Tyrian Bridge to Indigo repo by @davesmith00000 in #657
- Fixed #658: Large box overlap small circle check by @davesmith00000 in #664
- Add pathfinder by @mprevel in #648
- Physics engine: Improved scaling performance by @davesmith00000 in #666
- Fixed #671: Bresenham's line algorithm port by @davesmith00000 in #673
- Fixed #672: Added SparseGrid datatype by @davesmith00000 in #674
- Fixed #647: Entry points use defs not vals by @davesmith00000 in #675
- Physics: Terminal Velocity by @davesmith00000 in #679
New Contributors
Full Changelog: v0.15.2...v0.16.0