I recently read Juniper Dev's pixel art guide and put together a set of notes covering everything from choosing software to advanced coloring, to share with anyone else who wants to get started.
For software, I recommend Aseprite: the interface is friendly, and its animation and tileset features are designed with game development in mind. If you don't want to pay, the open-source LibreSprite or the browser-based Piskel are good free alternatives. For colors, I didn't obsess over color theory at first and just used ready-made palettes from Lospec, then studied it gradually as I drew more. Prepare at least three colors for each material — a base color, a shadow, and a highlight — and you can already create a basic sense of volume.
When drawing lines, remember to remove stray pixels; turning on Pixel Perfect in Aseprite makes things much cleaner. For curves, keep the pixel segment lengths symmetrical (e.g. 1-2-3-2-1) and your lines will flow much better. When coloring, use neighboring hues on the color wheel for shadows or highlights to make the image more vibrant; also avoid "pillow shading" by deciding on the light source direction first and lighting everything consistently. Dithering and anti-aliasing are two very handy little techniques: one creates a sense of gradual transition, the other smooths out edges.
Outlines don't have to be pure black — try a darker version of the object's own color. Finally, some advice for developers: don't pile on too many colors, since more than three for a single material easily gets messy; zoom out to preview often to make sure everything still reads clearly at small size. Most importantly, enjoy the process — that matters far more than agonizing over a "perfect final piece."
Source: 32comic
Pixelblog 62 is about landscape backgrounds, and it makes a point I agree with: backgrounds should not sit at the back of your production priorities. They establish the setting and pull players into the world, but they also have to serve the gameplay. In platformers and shmups they may need to be muted so sprites stay readable, while in turn-based RPGs they can be rich and immersive.
For this lesson Raymond Schlitter focuses on the battle scenes of an imaginary turn-based JRPG, taking inspiration from Dragon Quest and Phantasy Star 4, with space left at the bottom for heroes seen from behind. The challenge he sets is a convincing sense of depth using 16 colors or fewer.
He picks a 192x144 canvas. It has a 4:3 ratio, fits within common 8-bit and 16-bit console resolutions, and divides well if you want pixel-perfect parallax scrolling later. The process begins with solid horizontal bands of colour that define the horizon, and then the ground and sky are split into more bands. His key point is that depth comes mostly from colour choice, following atmospheric perspective: the nearest plane is the most saturated with the strongest contrast, and each receding plane loses saturation, gets lighter and shifts its hue toward the sky colour. In a clear blue sky the closest grass is warmest and the distant planes drift toward blue.
After the colour planes he adds two mountain layers, reusing colours from the sky bands, and then gets into details. The grass is made of many short single-pixel vertical streaks, and the key is consistency in clustering and scale. He includes every step as a separate image so you can follow at your own pace. It is a helpful read if you struggle with palettes that feel flat.
Source: SLYNYRD
I came across a long article on Habr about how the Rubik's Cube became an artistic medium, and it has a lot for anyone who loves pixel art. The author has been building mosaics from cubes for several years and explains why this genre sits so close to digital graphics.
The main idea is simple: a colored tile on the face of a cube is essentially a pixel. Each face has nine squares, and the palette has six colors, so a group of cubes can form a low-resolution image that resembles the screen of an old computer or an arcade machine. The timing also lines up: the golden age of 8-bit games like Space Invaders, Pac-Man, and Donkey Kong coincided with the Rubik's Cube craze of the early 1980s. According to the author, the term "pixel art" was first used in 1982 by Adele Goldberg and Robert Flegal of Xerox.
The article then traces the genre's history. The earliest experiments are attributed to the British artist Fred Holly in the mid-1980s. In the 1990s, programmer Jacob Devenport documented mosaics of several dozen cubes, including the first two-sided one. The real breakthrough came from the French street artist Invader, who in 2004 built his space invader character from nine cubes and called the style Rubikcubism. His 330-cube "Mona Lisa" sold at auction in 2020 for 480,200 euros, and in 2022–2023 the MIMA museum in Brussels hosted an exhibition of more than a hundred of his cube works.
What I liked most was how the author describes the process: first a pixel diagram in six colors, and then, for more complex pieces, Photoshop to check the colors. It's the same path any pixel artist takes, except the "pixels" here are plastic cubes. For anyone working with a limited palette, it's a good reason to look at familiar techniques from a different angle.
Source: Habr
I recently read a very long, in-depth Aseprite guide that breaks down the workflow for pixel-art games in detail. I've noted the parts most useful to me, especially the default setup that's hard to go wrong with if you just copy it.
Canvas: start characters at 32×32, enemies, items and icons at 16×16, and go up to 64×64 for the hero when needed. You can set the default zoom to 800% while editing, but keep 1:1 rendering in the game; don't let the zoomed canvas in the editor fool you.
Palette: start from DB32 on Lospec, expand to 48–64 colours as needed once the main colour scheme is set, but keep the colours actually used in a single frame to 16 or fewer. A palette is "colours you can choose", not "colours you must use up". Ideally the whole project shares one main palette; swapping it out mid-development leaves older assets mismatched.
Animation: idle at 8 FPS, attacks at 12 FPS, special moves at 24 FPS. Within one file you can give individual frames different lengths with Frame Duration.
Export: sprite sheets laid out by rows with JSON Hash data, and files named "character_action" as PNG + JSON pairs.
The most common trap once in the engine is filtering: Filter Mode must be Point, not Bilinear, and pixel art doesn't need texture compression. In Unity, the official Aseprite Importer lets you import .aseprite files directly, saving the manual export step.
One more piece of advice I strongly agree with: find an action you repeat more than ten times a day and write a small 20–30 line Lua script for it, one a week. After a few months, the time saved is far more than you'd expect.
A good place to start choosing palettes:
https://lospec.com/palette-list
Source: Xmohe 独游魔盒
One of Raymond Schlitter's Pixelblog tutorials from this spring tackles something I have always found tricky: a turn-based mech game in the style of Front Mission, drawn on an isometric grid. It is a concept for educational purposes, not an actual project, and it cross-references his earlier posts on isometric projection.
The mechs are drawn at roughly 32x32 pixels, smaller than his usual 64x64 and up, which means details have to be abstracted into very few pixels. His method is to start from simple geometric shapes for each part and build the body first. The torso should project forward like the front of a tank, the shoulders are bulky and set higher than the head, and the head stays low and sleek with just one or two bright pixels for the optics. Feet are designed for stability, borrowing from talons, claws and hooves, because plain humanoid feet look awkward in this style. Accent stripes come last and only where they strengthen the shapes.
He sketches three unit types, infantry with rounded shapes, artillery with a giant cannon fused to the head, and fighters with sharp triangles and reverse-jointed legs, and gives each a short tactical note.
The environment half is just as useful. The base tile is a 32x32 cube whose top diamond has 2px corners, and adjacent tiles must be layered in a consistent order so textures sit flush. Natural tiles start from a dirt tile with varied grass textures on top, water sits at about half the height of a normal cube, and its animation loops over 16 frames by shifting a line texture down 1px per frame while the highlights alternate.
My favourite line is the reminder that repeating tiles must look good when repeated across a whole map, so it is worth testing the layering yourself.
Source: SLYNYRD Pixelblog
Raymond Schlitter's latest Pixelblog on SLYNYRD is a study in 8-bit ninja platformers, and it is a good read for anyone who likes to see a whole set of game assets built around one idea. He openly takes his cue from Ninja Gaiden and works with the NES palette throughout, though he does not stick strictly to the hardware limits.
The player character comes first. He starts from a plain dummy template so the animations are settled before any design detail goes on, and the bright red suit is chosen for pop even if it is not very stealthy. The moveset is modelled on Ryu Hayabusa: a brisk run, climbing walls, hanging from ceilings, a flip jump and an air slash. What I liked is the reasoning that the character stands still while attacking on the ground, because that compromise forces precision in encounters instead of letting you mash slash while running.
Then come the enemies: a heli-turret that sweeps its cannon over 180 degrees in five directions, a spider tank that clings to walls and ceilings, and a slow cyber gorilla that acts as a damage sponge. For the gorilla he worked from knuckle-walking reference, blocked out simple body shapes to get the motion right, and only afterwards added robotic details. Merging head and body into one part gives it a deliberate stiffness.
The environment is the part I found most useful. It uses 16x16 tiles in six layers, each of which can scroll at its own speed for parallax, and a cabinet-style projection where depth lines run at roughly 67.5 degrees so they step cleanly, two pixels up for every one across. The result is shown in a 320x180 mockup.
One more thing worth knowing: this is the first Pixelblog where one of the mini tutorials, the full frame breakdown of the ninja, sits behind a Patreon paywall, while the main lesson stays free. The assets and source files are sold as a separate pack. I would love to see someone drop these sprites into a real player controller.
Source: SLYNYRD
Habr has published a translation of a long article by Karl Svensson on how cathode-ray tubes (CRTs) affected pixel art. The topic is debatable, and I liked that the author disagrees with the simple explanation that “CRTs blurred everything.”
He starts with a popular TikTok video claiming that older artists accounted for CRT blur, which made rough pixel edges look softer. Svensson admits this is partly true, and agrees that modern blocky pixel art often turns into inaccurate nostalgia. But he points out that old hardware has many more aspects to consider. He still uses old CRTs regularly, so he turns off the software CRT filters in emulators, saying that none of them reproduce a real screen faithfully. A photo of a Commodore 64 on a Commodore 1084S monitor shows that the uneven pixel edges are visible on a CRT too.
Next he compares two C64 games. Maniac Mansion (1987) runs at 160×200 and looks angular, while Mayhem in Monsterland (1993) uses dithering and smoothing with the same fixed 16-color palette to imitate higher resolution and color depth. These techniques depend on CRT properties: slight blur, scanlines, and a little color bleeding.
The author considers the 16-bit era the golden age of pixel art: the Amiga 500, SNES, Atari ST, and Mega Drive. The Amiga could show 32 colors out of 4096, and graphics in games such as Silkworm or Ruff'n'Tumble gradually improved. He also covers CGA color tricks and explains that on VGA screens with a fine dot pitch, individual pixels are much more visible.
For me, the article was a good reminder: before adding “retro blur,” it is worth understanding which screen the original was drawn for.
Source: Habr
In Pixelblog 63, Raymond Schlitter turns to the horizontal shoot 'em up and builds a set of assets around WW2 aircraft battling over a natural landscape. After earlier features on vertical shmups, this is his first take on the horizontal kind, where bullet patterns come across the screen rather than down it.
He starts with the player plane, because it sets the tone and the resolution for everything else. At roughly 48x32 pixels there is room for detail without becoming expensive to animate. The plane is modelled on the P-51 Mustang. A point I found interesting is that he animates roll rather than pitch for vertical movement. The nose stays level so the bullets always leave straight ahead, and rotation at such a low resolution tends to leave noisy clusters of pixels anyway. In summary, roll keeps the sprite clean and looks good.
The animation uses five orientations: one neutral frame and two roll positions each for up and down, plus a constantly spinning propeller. He also gives a design rule for how it should feel in play: a tap shows only the first degree of roll, holding shows the fully banked pose, and releasing passes back through the shallow pose to neutral. He advises against adding inertia to movement in a genre built on precise reactions.
Options, the little pods that orbit the ship, are covered as well. Beyond their gameplay use, he argues they add screen presence, which helps you feel where your ship is while your eyes follow bullet paths.
The enemies are German aircraft and a Hummel artillery vehicle. His workflow is a template made of a few blocked-out colours, then proper colours and basic detail, then lighting and fine detail, and outlining last. A palette swap lets the propeller animation be reused across planes, and he suggests spending extra frames only where the behaviour justifies it. It is a practical lesson in economy.
Source: SLYNYRD
The Aseprite team announced on 22 July 2026 that v1.3.18 is the new stable version. It includes bug and crash fixes plus the new features introduced since v1.3.18-beta1, and you can download it from your account at aseprite.org.
The headline changes in the base release are a new tag separation in groups on the timeline and a new "power of two sheet size" option for sprite sheet export. There are also fixes for copying user data (colour and text) for tags and slices when duplicating a sprite, and for several crashes, such as deleting a pasted selection or hiding a layer while moving pixels.
The point releases that followed matter for anyone working with tiles. v1.3.18.4 fixed Snap to Grid alignment for brushes larger than one pixel and improved copy and paste of tiles between tilemap layers. Later builds fixed a crash when pasting tilemaps and a crash after exporting a sprite sheet when the sprite had a selection. Animated GIF exports now use the correct 89a header, and grayscale PNG files load with a grayscale palette.
Scripters get some updates too: the Lua API version moved to 41, with Dialog:samerow{} and new save and beforesave sprite events.
I like release notes like this because they show where the daily friction is: grids, tilemaps, exports. If you have been putting off an update because of a tile-copy bug, this one looks like the version to try.
Source: Aseprite Blog
Once you start drawing characters in pixel art, sooner or later you run into the term "sprite sheet." I am sharing a beginner-friendly explainer that Keitaro wrote on note, because it walks through how the system works step by step and I found it useful.
A sprite is a 2D image shown on the game screen. Characters, enemies, items, bullets and effects all count, and a sprite sheet is what you get when you gather them into one large image. For a walk cycle, you show a frame with the right foot forward, then a frame with both feet together, then a frame with the left foot forward, switching quickly so it looks like walking. In other words, motion comes from swapping still pictures, not from video.
The game does not display the big image as a whole. It cuts out only the frame it needs by splitting the image into coordinates. For example, if each frame is 128×128px and eight sit side by side, the display area moves through 0–127px, then 128–255px, and so on. The article also gives an example of arranging the horizontal axis as 8 directions and the vertical axis as actions (walking, attacking, being hit, guarding), so you manage 8 directions × 7 states, or 56 frames.
When you actually use them, the article stresses that lining up the reference position in every frame matters most. If the feet drift by a few pixels from frame to frame, the character appears to jitter up and down during the animation. Keeping the background transparent is also essential.
Finally, it explains the difference between a sprite sheet, which is simply related pictures arranged together, and a sprite atlas, which packs several images into one texture for drawing efficiency. My personal takeaway from the article is its summary that making the images is less difficult than shaping them into a form the game can use correctly. I think it will be useful for pixel artists as well, especially at the export stage.
Source: note (Keitaro)
In pixel art backgrounds, rocks are a small but surprisingly time-consuming job. In Friday's pixel news, the note writer おかか容疑者 introduced the Aseprite extension “Rock Generator for Aseprite.”
The extension is published on itch.io. It is a rock-only production tool that brings in rocks as 3D meshes and lets you use them as pixel art. Even the download page shows a lot of parameters, and the article says that narrowing the tool down to rocks is why it can be adjusted so finely.
According to the article, it comes with 10 preset shapes, 21 preset structures, and 72 looks. You can make moss-covered rocks and snowy rocks too, so it seems easy to use when building backgrounds. The UI supports 27 languages, including Japanese.
It is a paid tool, starting at US$4.99 (about 800 yen) as of October 2026. There is a trial at the bottom of the page, but the article notes that it only contains sample output images. If you want to check before buying, keep that in mind.
You could already model rocks in Blender or another program and import them into Aseprite. Still, being able to rough out rocks inside Aseprite itself seems very efficient, and it could be useful when you need to produce a lot of background pixel art. I always struggle with how to paint different rock textures, so news about helper tools like this is genuinely welcome.
Source: note (おかか容疑者)
The pixel art festival “Pixel Art Park 9 (PAP9)” will be held on Sunday 11 October 2026 at Pacifico Yokohama. The exhibits for this year were introduced in a note article by Mr. Morita of Ixeal, a game development company in Nerima.
Ixeal is taking part as a sponsor. It will show two completely new original games developed for PAP9, and the article introduces one of them, 『Magical Soup』.
The idea is to catch “hidden flavours” to make soup. There are three kinds of hidden flavour, “Normal”, “Dangerous” and “Magical”, and the combination you choose changes which soup you can make. Players also get a sticker matching the type of soup they made. The game comes from the team behind 『JUST Onigiri』, which exhibited at the previous PAP8.
The second game and new pixel art goods will be introduced in later articles.
It sounds like a fun event for people who love pixel art, with things you can play and hold in your hands. Seeing how pixel art moves inside a game, and getting to talk directly with the creators, seems like a rare chance. If you live nearby, it might be worth stopping by.
Source: note (Ixeal, Morita)
