I have been working on a Aliasing.Pro since October of 2023 called and version 5 is close to what I had in mind for the app from its conception. The goal for version 6 is to be able to export animated GIFs with retro aesthetics that can be shared in a gallery. One feature I want to add is tile-based graphics, which has started me down a rabbit hole of refactoring. I have a degree in animation, and one thing I learned is that restrictions can make your art more successful and it can make programming more focused. Up until now, I limited the colors in your palette to 32 colors or less. The canvas could be up to 1024×1024 pixels with up to 32 layers that had to be large enough to cover the entire output. Performance is scaling at O(N^2) with resolution, the history states take up gods know how much memory, and the restriction on colors isn’t helping with performance at all. This is not to mention the file size would be huge when exporting a 50fps 1024×1024 GIF once animation is added.

I think I am trying too hard to be web-based Photoshop, but for pixel art, when I should be looking more at PICO-8 for inspiration. PICO-8, pictured above, is a “fantasy console” that provides a constrained environment for creating and playing retro-style games. I have been researching retro graphics hardware, and I am more inspired by 90s hardware instead of the 80s consoles that the PICO-8 is based on. I don’t want to actually emulate the hardware realistically, just the aesthetic, and I’m leaning slightly in the direction of higher fidelity.

I really like the number 24, even though it isn’t a power of 2. It is divisible by 2, 3, 4, 6, 8, and 12! I’m thinking about a fixed output of the main canvas size 384 by 240 pixels. That could be thought of as a 16×10 grid of 24 by 24 pixel tiles. This might help focus my development but it will restrict the use cases of the app. That would be a problem if I had tons of users used to my app but I have practically no existing users to tick off. This appraoch would focus the on the sites own gallery instead of other social media. The restrictions would provide a level playing field between artists on the platform.

The Technical Details

GIFs support up to 256 swatches of color, which can include a swatch for full transparency. I don’t want to have just one giant palette because it doesn’t facilitate the retro look, and it would be unmanageable for artists. The SNES allowed 8 palettes of up to 16 colors each (4-bit), with the first color in the palette being full transparency. So let’s imagine that for an Aliasing.Pro project we will be allowed 10 palettes with 24 colors each, plus alpha. That gives 241 colors, as much as can be achieved with 24 color palettes. I want to reserve the first palette for a system palette that is used for saving the sprite sheets to my CDN. The sprites will be dynamically converted and rendered in one of up to 9 custom palettes. Palettes will be savable and sharable on the gallery too!

All the layers will be put together and animated in the canvas window, which will have no real boundaries. There will be a 384×240 camera that crops the canvas on output, and its position will be animatable. The sprite layers might be composed of grids of up to 48×48 tiles (I have to set a limit somewhere or users might make a layer with, say, 1000×1000 tiles, and crash the app). Each sprite layer would pull from the same sprite sheet and each tile can have a different palette index. I am not yet sure if I want to restrict sprite dimensions to squares of 8×8, 16×16, 24×24, 32×32, 40×40, and 48×48, or if I want to allow dynamic sprite sizes between 8 and 48 pixels. I do know that sprites are going to be able to be flipped dynamically. That might save resources for symetrical characters like how Mario. The sprite sheets can be up to 960×960 resolution, which can be exported for use in games, satisfying some use cases for uses needing more dynamic output resolution than the canvas editor can offer. However, with what I have in mind, the sprite editor will only have one layer and be previewed in only one palette at a time.

Under the hood, the art is drawn on HTML5 canvases in a React.js stack. In version 5 each layer has its canvas positioned with CSS, but I am weighing the performance implications of switching to drawing on one output canvas frame by frame. In the future. Version 5 already has advanced guides. For example, you can make a horizon with perspective vanishing points, and if you hold shift, it will snap to a line towards the vanishing point in the direction you start drawing. These are currently drawn with SVG graphics, but I like the idea of switching them to raster graphics since it might look cooler, but then I would need an HTML5 canvas that dynamically spans the entire viewport.

The Future of Aliasing.Pro

I want users to be able to draw on the sprite layers from within the canvas window and have it wrap dynamically to the equivalent location on the sheet, wrapping as needed. I’m having a hard time wrapping my head around how to implement that, especially how that will change the selection tools. I will have to do some benchmarks of different implementations, including the one canvas per layer method or having one output canvas that spans the viewport, that is drawn to frame by frame like a game engine.

How I implement this will affect everything that is to come. I hope to offer text layers, vector graphics layers, and low-poly 3d rendering. For now, though, I want to focus on laying a strong foundation and writing clean code. This is where the Kickstarter comes in. Having funding will allow me to focus more of my energy on the project and make an app the artist want to use! Follow the Kick starter with this page to be notified when the campaign launches sometime this Summer.