Happy New Year - Graphics GD in 2025

[Splizard]

Hope everyone is having a good 2025! There's been some change brewing and I'm happy to announce that after some major reorganization and re-engineering, we've managed to eliminate the need for gd.Context in the project. Yep, that means no more awkward API usage and memory management. We've switched to an entirely new memory management strategy and at the same time managed to fix a lot of the pain points that come up using the project. The project is now well on the way to reaching a stable point and without some major new features arriving in Go, I don't expect any further changes to occur at this scale but there may still be some small breaking changes here and there as the exported interfaces are refined.

New Features

🗑️ Automatic Frame-Based Memory Management, use it or lose it!

Engine references must be 'used' every frame in order to remain alive, otherwise
they will automatically be garbage collected each frame. You shouldn't have to
worry about any memory management as long as you keep Engine references inside an
extension class and don't hold onto references across frames. If you get an
"expired pointer" error, it means either the reference has outlived its frame and
has not been used since or the ownership of the value was transferred to the engine.

➿ Class Package Reorganization

Each Engine class has been moved into an isolated package, this has resulted in much better developer experience. You can instantiate classes with the New constructor. ie. Label.New(). The documentation is now sensibly partitioned for convenient digestion - the documentation pages are now usable instead of being a single page of a billion lines. Each class includes the dependencies it needs and both a idiomatic Go Instance as well as a 1:1 Advanced instance that has all of the optional parameters exposed and low-level Engine types for those who know what they are doing.

🚀 Much Faster Compile Time

You would think we are using a scripting language, the reorganization of the project has resulted in significantly improved compile times, from what used to take a few seconds to launch a project, is now booting up almost instantly on my machine. Since each class is separated into a distinct package, each package can be compiled in parallel and glue code will only be included if you actually import the class. There's still some gains to be made on the initialization front as well, in future, only the classes that are imported will be loaded into the runtime at startup.

💪 Startup Flexibility

The startup package is responsible for starting your project and connecting to the graphics/game engine (ie. Godot), you can now run code in the main function without first creating an extension class, this provides a truly functional graphics-programming experience, similar to the likes of Ebiten or LÖVE. You can wait for the engine to startup or provide your own MainLoop, or simply drop straight down to a for loop for HelloTriangle rendering with theRenderingDevice.

   // different startup options to use in your main function
   startup.MainLoop[MyMainLoop]()
   startup.Wait() // wait for the engine to start up
   frames_iter := startup.Rendering() 

⚙️ Functional Variant Packages

The variants have all been slotted into their own type-safe packages, all the math variants are still pure Go and are now designed to be generic so they work on any struct that has the same underlying type (so you can create your own named types and methods and still use the functions defined in these packages). Resulting code is clear and readable. The math types are named after their field structure, so Vector2.XY, Plane.NormalD, Rect2.PositionSize. You will always know what the field names are and you can use the package functions like so:

    dot_product := Vector2.Dot(a, b)

🔤 New Import Path

Going forward, the project will be under the new import path of graphics.gd, now that the project has grown, this is shorter and should more effectively reflect the identity of the project. We want this to be a standalone way to work with graphics in Go, leveraging existing Open Source engines (ie. Godot) as the primary way to do this. You should be able to write all of your code in Go if you want to and only use the editor for asset management and scene setup. At the same time, we are still aiming to support the ability to create general purpose Go engine extensions, and GDScript interfaces.

Migrating to the new version

Hopefully there aren't too many big projects already - I'm certainly not aware of any. If you have an existing project and need help migrating over, please leave a comment here and I can support you through the process. I've already updated all of the examples and will be updating all the snippets in the Github discussion pages to reflect these changes to graphics.gd.

You can get started by installing the latest graphics.gd command!

go install graphics.gd/cmd/gd@master