Skip to content

v4.0.0

Latest

Choose a tag to compare

@github-actions github-actions released this 07 Aug 19:43

Changed

  • Core: spatial grid queries are now allocation-free apart from the single result array they return. neighbors*, inRange, ring, spiral, lineOfSightCells, floodFill and findPath on Grid2DSpatial, Hex2DSpatial, Grid3DSpatial and Hex3DSpatial no longer allocate intermediate collections, queues, heaps or throwaway grids per call — 3D hex distance and neighbor queries previously allocated a full grid-sized array per call. Hex A* now uses the exact hex-distance heuristic (was an underestimate that expanded extra nodes). Public signatures are unchanged.
  • Core: command/subscription batching (Cmd.batch2, Sub.batch2, the System pipeline), layered-grid edits and 3D layout line drawing no longer allocate tuples per call. Breaking: LayeredGrid2D/LayeredHexGrid/LayeredGrid3D/LayeredHexGrid3D getOrAddLayer now returns a struct tuple — callers must destructure with let struct (a, b) = getOrAddLayer ...; the previous let a, b = ... form no longer compiles.
  • Core: dictionary lookups and dictionary enumeration no longer allocate — the Elmish loop's subscription bookkeeping and per-frame bool * 'T/KeyValue tuple allocations from TryGetValue and for KeyValue loops are gone (internal zero-allocation helpers in Mibo.Elmish).
  • Raylib 3D, MonoGame 3D: fewer per-frame/per-draw allocations — render-target pools, material/part/transform caches and palette-texture bookkeeping no longer allocate tuples per lookup; instanced renderer grouping is allocation-free per cell; per-block light merging is a single exact array copy.
  • MonoGame 2D: fewer per-frame allocations — batch-state checks and mouse input handling no longer allocate tuples per draw or per frame.
  • MonoGame 3D: fewer per-frame allocations — per-draw effect validation and per-frame post-process checks no longer allocate tuples.