Pixelorama: six download channels and a Godot version you cannot ignore

Godot 4.7.2 is a hard floor when you build from source

The repository is a Godot project, so cloning it means installing an engine first, and the version is not negotiable. Pixelorama uses Godot 4.7.1, so you will need to have it in order to run the project, and older versions will not work. No exceptions are offered in the text.

The Mono build is a softer point. Most of the code is written using GDScript, so the Mono version of Godot is not required, and the README adds that Pixelorama should also work with it. The project root carries the usual Godot furniture: project.godot at the top, export_presets.cfg beside it, code under src/, plugins under addons/, data under pixelorama_data/ and translations under Translations/ with crowdin.yml at the root. A linter config sits in .gdlintrc, and there are two changelogs, CHANGELOG.md plus a separate CHANGELOG - v0.x.md for the older line.

Five channels, and only one of them is a command

The download section is a set of channels whose differences decide what you can actually obtain. Steam carries Windows and Linux. Itch.io carries Windows, Linux, Mac and Web. GitHub Releases carries Windows, Linux and Mac. GitHub Pages serves the Web build. Flathub serves Linux. WinGet is the Windows entry, and the only one written as something you can paste:

winget install pixelorama

Read that as a coverage matrix rather than a list, because it is uneven. macOS arrives through Itch.io and GitHub Releases and through nothing else named here, with no Homebrew or App Store entry in the README. The web build exists in two addresses, GitHub Pages and Itch.io. Anything installed through a store arrives as that store's package and updates on the store's schedule rather than the GitHub one.

Early access is assembled by GitHub Actions and labelled unstable

Between the stable channels and the release page sits an early access line. You can also find early access builds in the GitHub Actions page, and there is a separate web version at an early access address. The warning that follows is the part that matters: keep in mind that these versions will have bugs and are unstable. Unless you're interested in testing the main branch, it's recommended that you stick to a stable version.

That makes early access a testing commitment rather than an install. Nothing in the README says how long a build survives between runs or how to file a failure against a moving commit, so the reproduction is yours to hold. The same automation carries the shipping path too: a godot-ci Docker image exists so the team can export Pixelorama automatically using GitHub Actions.

The gif exporter and the dockable windows are upstream Godot plugins

The editor is assembled from other people's repositories, and the credits name each one. Godot itself is the foundation, without which Pixelorama would not exist. godot-dockable-container is the plugin the UI system uses for dockable containers, and the Keychain plugin is what the shortcut system uses for its customizability. The gif exporter is godot-gdgifexporter. File exchange in the HTML5 web version is handled by HTML5-File-Exchange-for-Godot.

Treat that as a dependency surface rather than a credit list. Four external projects sit underneath features a user experiences as native.

Indexed mode, cleanEdge, OmniScale and rotxel are the pixel-specific core

Most drawing programs treat pixels as a side effect of the file format. Pixelorama names the algorithms instead: rotation and scaling algorithms tailored specifically to pixel art, citing cleanEdge, OmniScale and rotxel, alongside perfect pixel lines and indexed mode. Those three names are the difference between a sprite that stays crisp and one that turns to mush when you resize or rotate it, and they are named rather than implied.

The same reasoning runs through the canvas. Guides, rectangular and isometric grids and tile mode exist so patterns repeat exactly rather than approximately. Palettes are managed rather than assumed, with pre-made palettes, import, and creation of custom ones inside the software. Colour is something you choose from a list you control, not something the canvas picks on your behalf.

Tilemaps and 3D layers push the document past 2D

Two feature groups change what kind of file you are making. Tilemap layers create rectangular, isometric or hexagonal tiles for games, so a tileset and a frame sheet come out of one document instead of two tools. 3D layer support brings 3D models and shapes into the 2D canvas. Extensions go further: free, community-made extensions include tools that convert 2D pixels into 3D voxels.

Community-made is the phrase carrying the risk there. Extensions are credited to the community with a voxel converter named as an example, but the README states no extension API version and no compatibility range, so a pipeline that depends on an extension inherits that extension's own update schedule. Project metadata is the internal counterpart: custom user data attached to layers, frames and cels, described as the way to integrate with game development.

Command line automation stops at export, and the docs are unfinished

Automation gets one line: command line automation for bulk exporting, aimed at streamlining workflows. Nothing else about scripting is described. No flags, no save commands, no render commands are enumerated, so a build script that needs more than a batch export has to be written against the source rather than against documentation.

Documentation is the second soft edge. The online documentation lives at the Pixelorama-Docs site, the README calls it a work in progress, and it says plainly that some pages are missing. Contributing to it happens in a separate repository, Pixelorama-Docs on GitHub. Two consequences follow for a team standardising on the tool: the reference you hand a new artist can be incomplete, and fixes to it go to a different repository with its own review queue.

Three 1.2.x patches in four weeks, MIT licensed

The tag list shows the cadence: v1.2.1 on 2026-08-19, v1.2.2 on 2026-09-09 and v1.2.3 on 2026-09-15, with the last push to master on 2026-11-02 and the repository not archived. Releases land inside a 1.2 line, so pin the patch you validated and read CHANGELOG.md before upgrading rather than after.

Licensing is MIT, with the LICENSE file at the repository root and the feature list stating the open-source guarantee directly. Funding runs through the sponsor link in the README, where sponsoring is described as enabling more focus on Pixelorama and more projects afterwards. Localisation runs on Crowdin, with the translated strings kept in Translations/ and crowdin.yml holding the configuration.

Editorial conclusion

Adopt Pixelorama when your work needs tilemap layers, an animation timeline with frame tags and onion skinning, or GIF and spritesheet export out of one document, and when installing through a store is acceptable. Do not adopt it when you need an Android build, when you need scripting beyond batch export, or when a documented workflow matters more to your team than the feature list, because the documentation site is a work in progress with pages missing. Verify first: install one stable build and note the engine the source expects, Godot 4.7.1, because older versions will not run the project.

Frequently asked questions

Official sources

1. License: MIT
2. Orama-Interactive/Pixelorama on GitHub
3. Project website
4. README
5. Releases