Gondwana v2.6.0 is here

[Isthimius]

Gondwana v2.6.0 is now available.

This ended up being a much larger release than the version number probably suggests.

Since v2.5.2, the engine has gained a new effects system, direct lighting, WebGL rendering, resolution-independent presentation scaling, SceneLayer wrapping, a substantially expanded widget library, a reworked audio architecture, new collision and tilesheet capabilities, new desktop tooling, new demos, AI/MCP integration, and a fairly serious overhaul of the project's documentation and release infrastructure.

More importantly, a lot of things that had existed as individual pieces are beginning to feel like complete systems.

Rendering grew up quite a bit

One of the biggest changes in 2.6 is the separation between the resolution Gondwana renders at and the size of the window or canvas displaying it.

The Backbuffer now represents a logical rendering resolution instead of simply following every resize of the host window. RenderScale can be used to choose that internal resolution, while PresentationScale reports the scale actually used to present it. Resizing a window or browser canvas scales and centers the existing Backbuffer rather than rebuilding the game world around a new rendering size.

That means a game can, for example, render consistently at a lower internal resolution and present cleanly on a much larger display. Linear and nearest-neighbor presentation filtering are both supported, so this works for traditional rendering as well as pixel-art games.

This work touched WinForms, Avalonia, and Blazor, along with input coordinate normalization, Views, Viewports, and both Bitmap and GPU rendering paths.

Blazor also received a proper WebGL GPU rendering path in 2.6. Browser games are no longer limited to the original canvas/bitmap presentation path, and the Blazor hosts, templates, CLI workflow, and Spot.Blazor demo were updated accordingly.

The engine loop itself now uses fixed-step simulation timing, separating simulation progress more cleanly from rendering cadence. Sprite rotation has also moved into Sprite.Draw, putting that responsibility where it belongs instead of making it a Backbuffer concern.

Several rendering bugs were cleaned up along the way, including GPU coordinate-conversion tearing, bitmap adapter behavior, zoom calculations, movement timing, refresh behavior, and image-instance updates.

SceneLayers can finally wrap

This is an old capability that has effectively returned in a much more complete form.

SceneLayer.WrapHorizontally and WrapVertically are now operational and make a layer periodic across the appropriate axes. This isn't just a visual trick: wrapping is understood throughout the engine.

Wrapped layers work with:

• rendering across seams and corners;
• tiles, sprites, DirectDrawing, fog, and collision visualization;
• collision queries and collision response using translated instances while preserving canonical objects;
• cameras and camera following;
• world-space Widgets, including hit testing, capture, and dragging;
• negative and multi-period grid coordinates;
• Orthogonal, Isometric Rhombic, Isometric Axial, Hex Flat-Top, Hex Pointed-Top, Oblique Right, and Oblique Left projections.

Projection-aware period vectors are used instead of assuming that "horizontal" and "vertical" always mean simple screen-space X and Y movement. That becomes particularly important for isometric, hexagonal, and oblique maps.

This was one of those features where doing it halfway would have created more problems than it solved, so the implementation was carried through rendering, collisions, cameras, UI, serialization, and testing together.

Effects and lighting are now first-class systems

2.6 introduces the new Gondwana.Effects subsystem for applying presentation effects to an entire View or SceneLayer without rewriting the positions or collision geometry of everything inside it.

The initial set includes fades, slides, fills/erases, zooms, and an earthquake/shake effect. Effects have lifecycle state, easing, cancellation, completion events, and can be composed when they occupy different presentation channels.

That makes common operations such as scene transitions, level reveals, screen shakes, fades, and View transitions engine features instead of one-off game code.

Lighting received similar treatment.

New DirectDrawing lighting primitives provide darkness overlays, light layers, and radial lights, including SceneLayer-aware darkness. This gives games a straightforward way to build darkness/light composition without requiring a separate fog system or manually modifying every object being rendered.

Gondwana.Widgets is becoming a real UI toolkit

Widgets saw one of the largest expansions in this release.

The earlier Widget foundation—input routing, DirectDrawing integration, dragging, containers, and View/SceneLayer attachment—has been built out into a much broader set of actual controls.

2.6 adds or substantially develops controls including labels, text boxes, buttons, check boxes, radio buttons, combo boxes, list boxes, hyperlinks, panels, progress bars, stack panels, health bars, name tags, conversation UI, popup overlays, toast notifications, dialogs, splash screens, and related layout/container functionality.

The input pipeline was tightened as part of the work, including mouse/touch routing, capture behavior, dragging, and integration with wrapped SceneLayers.

Menus also received a much deeper pass.

MenuBarWidget, dropdowns, headers, and menu items now form a full menu system rather than just something that can draw a menu bar. Menu items can represent ordinary commands, check items, and radio groups; nested submenus can recurse beyond a single level; items can have icons, keyboard shortcuts, and Alt-key mnemonics; and menus support keyboard navigation as well as pointer input.

Most importantly, application behavior can be attached directly to a menu item through callbacks. Consumers do not have to funnel every selection through a giant switch statement. Stable keys and item references make it possible to later enable, disable, check, uncheck, or otherwise update specific items as application state changes.

The WidgetsTest project now serves as a working sample of these patterns, including dynamic state changes, nested menus, shortcuts, mnemonics, icons, check/radio behavior, and callback-driven commands.

This feels much closer to the Widget system I originally wanted Gondwana to have.

Audio is now backend-neutral

The audio architecture received a fairly fundamental cleanup.

The core Gondwana package no longer depends directly on NAudio. Instead, core now defines the backend-neutral audio resource and playback contracts, while platform implementations live outside it.

For Windows, the new Gondwana.Audio.NAudio package provides the NAudio implementation. It supports WAV, MP3, OGG-family formats, Windows Media Foundation formats, seeking, looping, volume, stereo pan, and variable playback speed from 0.25x to 4x.

WinForms hosting configures the Windows backend automatically, while the same common AudioResource API is used by game code.

Gondwana.Audio.Browser was refactored around the same model for WebAssembly, including browser playback-rate and stereo-pan support. MIDI remains tied to the Windows/NAudio pipeline.

This leaves the engine itself much cleaner and, more importantly, gives Gondwana an actual audio-backend boundary that other platform implementations can use later.

The CLI and project templates were updated to understand this distinction as well: Blazor can select browser audio, Windows-targeted desktop projects can use NAudio, and genuinely cross-platform desktop projects are no longer silently coupled to a Windows-only library.

Tilesheets and collisions received another major pass

Collision configuration can now live at the tilesheet Region and Frame levels and persist through .gts files.

That includes collision types and CollisionAdjust values, with inheritance between region defaults and individual frame overrides. Existing collision-adjustment behavior was standardized so the runtime, serializer, and tooling agree on the same semantics.

The .gts serializer and validator were expanded accordingly, and a number of sprite, clone, movement, and collision edge cases were corrected along the way.

Gondwana also now has both Oblique Right and Oblique Left coordinate systems, filling out the oblique projection pair.

And .gts files finally have a real editor

This is probably one of the most visible additions to 2.6.

Gondwana.Tooling.Tilesheets.WinForms is a standalone Windows editor for Gondwana .gts tilesheet definitions.

It includes a working-directory browser, dockable and floatable documents, an image viewport, Definition/Region/Frame inspectors, region and frame selection, geometry editing, collision inheritance controls, zoom and scrolling, visual overlays and legends, customizable overlay colors, validation, dirty-document handling, Save/Save As, image replacement, and lossless editing of the current tilesheet model.

The editor understands the distinction between inherited and explicitly overridden frame values instead of flattening everything when a file is opened. Validation is shared with the runtime model, and invalid geometry or collision configuration is surfaced before save.

This is the first substantial visual authoring tool specifically for Gondwana's tilesheet format.

The existing Gondwana Asset Files WinForms tool remains available as well, now under the standardized Gondwana.Tooling.* naming. It provides a desktop UI for .gaf/.zip asset containers, including plain or password-protected files, importing, replacing, renaming, exporting and deleting assets, type filtering, searching, and Save As.

Gondwana remains a code-first engine. I don't intend to turn the engine into an editor that happens to run games. But code-first does not mean every data file should have to be written by hand.

More games to tear apart

The demo collection expanded significantly during the 2.6 cycle.

There are now self-contained examples and prototypes covering several different styles of game: a platformer, SpaceDuel, Flappy, a side-scroller, a Zelda-style top-down prototype, The Great Plop, and Rage to Pro, in addition to the existing demos.

These weren't added just to increase the project count. They have been useful for exercising collisions, sprites, particles, DirectDrawing, widgets, audio, tilesheets, serialization, rendering paths, and the host abstractions under actual game-like workloads.

Spot also received further work across its Windows, Avalonia, and Blazor versions, including Widget-based HUD work and updated .gts usage.

There's also a dedicated WidgetsTest application now because the Widget system has reached the point where it deserves its own comprehensive example.

Gondwana can talk to AI tools now, too

2.6 adds Gondwana.Mcp, along with repository-level AI/agent integration and documentation.

The MCP service gives compatible AI development tools a Gondwana-aware interface rather than forcing them to infer the engine entirely from arbitrary source-code searches. The repository now also carries explicit agent guidance and plugin metadata intended to make AI-assisted Gondwana development more predictable.

This isn't a replacement for learning the engine. The goal is the opposite: give coding assistants enough accurate engine-specific context that generated code follows Gondwana patterns rather than inventing an approximation of them.

The project infrastructure changed almost as much as the engine

There has also been a lot of work behind the scenes that users will hopefully notice mostly because things are easier to find and releases are less fragile.

API documentation is now published with a stable/versioned model so released documentation can remain immutable while development documentation follows master.

The GitHub Wiki is now represented in the repository under docs/wiki and synchronized with the normal GitHub Wiki, allowing Wiki editing to continue while also putting documentation changes through source control and the repository's protected-branch workflow.

CHANGELOG generation was reworked into a weekly aggregation model rather than having every merged PR immediately compete to modify the same files. That should greatly reduce the stream of pointless CHANGELOG merge conflicts.

Repository mirroring has also been expanded. GitHub remains canonical, with automated read-only mirrors available through Bitbucket, Codeberg, GitLab, and SourceForge.

Release labeling, PR-title handling, API-documentation validation, CI checks, NuGet/project metadata, per-project CHANGELOG handling, funding links, and project/tooling naming have all received cleanup during this cycle as well.

There are plenty of smaller fixes in here too

Not everything in 2.6 needed its own subsystem.

The release also fixes or improves hexagonal partial-coordinate movement, zoom calculations, sprite cloning, engine-configuration persistence, image-instance layer updates, custom logger dependency injection, timer edge cases, engine initialization safety, disposal deadlocks, effect-manager startup, mouse and touch polling, render adapters, and several rendering/coordinate edge cases.

Gondwana.Movement has also been moved to the more appropriate Gondwana.Physics.Movement namespace, and the tooling projects have been normalized under the Gondwana.Tooling.* naming convention.

If you're upgrading from 2.5.2

There are three architectural changes worth paying particular attention to.

First, window or canvas resize no longer means "resize my Backbuffer." Backbuffer resolution and presentation size are now deliberately separate concepts.

Second, Windows audio implementation details have moved out of core into Gondwana.Audio.NAudio. Most ordinary WinForms-hosted games get the backend configured for them, but applications that directly depended on NAudio-specific types should review the new package boundary.

Third, code using the old Gondwana.Movement namespace should move to Gondwana.Physics.Movement.

Beyond those, 2.6 is largely additive: more rendering options, more Widgets, more tooling, more examples, and more complete implementations of systems that were already taking shape in 2.5.

Where this leaves Gondwana

v2.5.x established a lot of groundwork. v2.6.0 is where several of those pieces started connecting.

The browser target has a GPU path. The UI system has real controls and menus. Tilesheets have a real visual editor. Audio has a clean backend boundary. SceneLayers can represent genuinely repeating worlds. Rendering resolution is independent from the display presenting it. Effects and lighting are reusable engine systems instead of demo code.

There is still plenty left to build—there always is in a game engine—but 2.6.0 is a meaningful step toward Gondwana being not just a collection of capable engine components, but a coherent environment for actually building games.

As always, Gondwana is open source under the MIT license.

Thanks to everyone who has taken a look, opened an issue, tried one of the demos, starred the repository, or simply followed along while I continue building this thing.

Now I can finally get back to making games with it.