Godot2Amiga turns Godot projects into native Amiga applications

A new toolchain is bringing a modern game engine into the Amiga development process, and the idea is far more practical than it sounds. Godot2Amiga lets developers build scenes in the Godot editor, then convert them into native software for classic Amiga hardware. It doesn’t try to run the full Godot Engine on the machine. That would be unrealistic. Instead, it uses Godot as the front end and handles the difficult job of turning scenes, graphics and project data into something an Amiga can actually use. That’s the key difference. Developers get a modern visual workspace, while the Amiga still receives native code built for its own architecture. If the project keeps moving in this direction, it could make Amiga development more approachable and create space for many more games, tools and applications.

A modern development setup for classic hardware

The current version targets an Amiga 500 with Kickstart 1.3 and the OCS chipset. That’s a tough baseline, but it’s also a sensible one. The toolchain can’t rely on fast processors, graphics cards or expanded operating systems. It has to work within the limits of the original hardware.

The exported software uses the Amiga C Engine, and the final executable uses the Amiga HUNK format. In other words, this isn’t a desktop demo pretending to be an Amiga application. It produces code for the real platform.

Version 0.7.3-alpha showed the first complete conversion of a Godot text scene into a working Amiga programme. The pipeline checks the project, generates the build files, converts the assets, compiles the native code and packages the result for testing. It can also launch the programme automatically through FS-UAE.

That may sound like a small convenience, but it matters. When developers can export, test and repeat the process without constantly rebuilding everything by hand, development becomes faster and far less frustrating.

Turning Godot scenes into Amiga data

Godot2Amiga already supports several important scene elements, including Node2D and Sprite2D objects. It also handles basic properties such as position, visibility and z-index. The toolchain can find PNG textures, process them and prepare them for the Amiga’s graphics system. It reduces colours to the OCS RGB12 palette, then converts bitmap and palette data with tools from the Amiga C Engine.

That’s where the project starts to feel useful. A developer can arrange a scene visually in Godot instead of manually describing every object in source code. The exporter then handles much of the repetitive conversion work needed to move that scene onto the Amiga.

The newer alpha builds are expanding the idea with a unified runtime, direct scene assembly and an asset registry. These additions suggest that the project is growing into a proper development environment rather than stopping at a technical demonstration.

Why Godot makes sense

Godot is a strong choice for this kind of project because it already gives developers a clear way to organise games and applications. Its scene system uses reusable nodes. Developers can combine those nodes to build characters, interfaces, levels, menus and effects. That structure fits 2D development especially well, and 2D software remains a natural match for Amiga hardware. Godot also includes tools for animation, scripting, user-interface design and asset management. Developers don’t need to assemble a collection of unrelated editors just to get started.

It’s free and open source under the MIT licence, and it doesn’t charge royalties on finished software. That makes it attractive to independent developers, small studios and anyone experimenting with a new platform.

Godot supports both 2D and 3D projects, but its 2D tools are particularly relevant here. Sprite-based graphics, tile maps and carefully planned screen layouts all fit comfortably into the engine’s workflow. Godot2Amiga can build on those tools instead of creating a new editor from nothing.

A practical route to more Amiga software

The main appeal isn’t just convenience. It’s access. Amiga development often demands a detailed understanding of the hardware, graphics formats, memory limits and build tools before a project can even show something on screen. Godot2Amiga won’t remove the need to understand the machine, and it shouldn’t. But it could remove many of the slow, repetitive jobs that stop developers before they get to the interesting part.

The project remains alpha software. Features will change, some parts will break and plenty of work still lies ahead. Audio, input, scripting and memory handling will all need more development. Hardware support will matter too. The planned range covers Motorola 68000 to 68060 processors, along with OCS, ECS and AGA chipsets. Support for Paula audio, Amiga graphics features and standard controllers could make the toolchain useful across a much wider selection of systems. That’s an ambitious target.

Still, the foundation already looks promising. A dependable Godot-to-Amiga pipeline could help developers move from a visual scene to a native executable without spending most of their time on manual conversion. It could also attract programmers who’ve never built Amiga software before.

That’s where the real opportunity lies. Better tools usually lead to more experiments, more finished projects and a wider range of software. Godot2Amiga could make native Amiga development faster, clearer and easier to start, while keeping the final result focused on the hardware itself. If the project continues to mature, it may open the door to a new wave of Amiga games, utilities and interactive applications built with modern tools and released as genuine native software.

Spread the love

A modern development setup for classic hardware

Turning Godot scenes into Amiga data

Why Godot makes sense

A practical route to more Amiga software

MORE AMIGA & RETRO NEWS