Onlangs las ik de pixelartgids van Juniper Dev en heb ik de belangrijkste punten, van softwarekeuze tot gevorderd inkleuren, in een set aantekeningen gezet om te delen met iedereen die ook wil beginnen.
Qua software raad ik Aseprite aan: de interface is gebruiksvriendelijk en de functies voor animaties en tilesets zijn ontworpen voor gameontwikkeling. Wil je niet betalen, dan kun je het opensource LibreSprite of de webversie Piskel als gratis alternatief gebruiken. Wat kleuren betreft, heb ik me in het begin niet druk gemaakt om kleurtheorie en gewoon kant-en-klare paletten van Lospec gebruikt; pas na veel tekenen ben ik me er langzaam in gaan verdiepen. Zorg per materiaal voor minstens drie kleuren (basiskleur, schaduw en highlight), dan krijg je al een basaal gevoel van volume.
Vergeet bij het tekenen van lijnen niet overbodige pixels weg te halen; met Pixel Perfect ingeschakeld in Aseprite wordt het een stuk strakker. Houd bij curves de lengtes van de pixelsegmenten symmetrisch (bijvoorbeeld 1-2-3-2-1), dan lopen de lijnen veel vloeiender. Gebruik bij het inkleuren naburige kleuren op de kleurencirkel voor schaduwen of highlights, dan wordt het beeld levendiger; vermijd ook 'kussenschaduw' (pillow shading): bepaal eerst de richting van de lichtbron en belicht alles consequent. Dithering en anti-aliasing zijn twee heel handige trucjes: het ene zorgt voor textuur in overgangen, het andere maakt randen gladder.
Een omlijning hoeft niet puur zwart te zijn; probeer eens een donkerdere versie van de kleur van het object zelf. Tot slot een tip voor ontwikkelaars: stapel niet te veel kleuren, want meer dan drie voor hetzelfde materiaal wordt al snel rommelig. Bekijk de preview vaak verkleind en zorg dat alles dan nog steeds helder is. Het belangrijkste is genieten van het proces, en dat is belangrijker dan blijven hangen in een 'perfect eindresultaat'.
Pixelblog 62 gaat over landschapsachtergronden en verdedigt een punt waar ik het mee eens ben: achtergronden horen niet onderaan je productieprioriteiten te staan. Ze zetten de setting neer en trekken spelers de wereld in, maar ze moeten ook het gameplay dienen. In platformers en shmups moeten ze soms gedempt worden zodat sprites leesbaar blijven, terwijl ze in beurtgebaseerde RPG's rijk en meeslepend mogen zijn.
Voor deze les richt Raymond Schlitter zich op de gevechtsscènes van een fictieve beurtgebaseerde JRPG, geïnspireerd op Dragon Quest en Phantasy Star 4, met ruimte onderin voor helden die van achteren te zien zijn. De uitdaging is een overtuigende diepte te creëren met 16 kleuren of minder.
Hij kiest een canvas van 192x144. Het heeft een verhouding van 4:3, past binnen de gebruikelijke resoluties van 8- en 16-bitconsoles en deelt goed op als je later pixelperfecte parallax-scrolling wilt. Het proces begint met horizontale banden van effen kleur die de horizon bepalen, daarna worden grond en lucht in meer banden verdeeld. Zijn kernpunt is dat diepte vooral uit de kleurkeuze komt, volgens het atmosferische perspectief: het voorste vlak is het meest verzadigd met het sterkste contrast, en elk achterliggend vlak verliest verzadiging, wordt lichter en schuift in kleurtoon naar de hemelkleur. Onder een helderblauwe lucht is het dichtstbijzijnde gras het warmst en lopen de verre vlakken naar blauw.
Na de kleurvlakken voegt hij twee bergenlagen toe, met kleuren uit de hemelbanden, en gaat dan naar de details. Het gras bestaat uit veel korte verticale streepjes van één pixel, en de sleutel is consistentie in clustering en schaal. Elke stap toont hij als afzonderlijk beeld, zodat je in je eigen tempo kunt volgen. Handig als je palet vlak aanvoelt.
Op Habr vond ik een lang artikel over hoe de Rubiks kubus een artistiek materiaal werd, en het biedt veel voor wie van pixelart houdt. De auteur maakt al jaren mozaïeken van kubussen en legt uit waarom dit genre zo dicht bij digitale beelden ligt.
De kernidee is eenvoudig: een gekleurd tegeltje op het vlak van een kubus is in feite een pixel. Elk vlak heeft negen vakjes en het palet telt zes kleuren, dus meerdere kubussen samen vormen een beeld met lage resolutie, dat doet denken aan het scherm van een oude computer of arcadekast. Ook de timing klopt: de gouden tijd van 8-bitgames als Space Invaders, Pac-Man en Donkey Kong viel samen met de Rubiks-kubushype van begin jaren tachtig. Volgens de auteur werd de term "pixel art" in 1982 voor het eerst gebruikt door Adele Goldberg en Robert Flegal van Xerox.
Het artikel schetst daarna de geschiedenis van het genre. De vroegste experimenten worden toegeschreven aan de Britse kunstenaar Fred Holly, halverwege de jaren tachtig. In de jaren negentig legde programmeur Jacob Devenport mozaïeken van enkele tientallen kubussen vast, waaronder de eerste tweezijdige. De echte doorbraak kwam van de Franse straatkunstenaar Invader, die in 2004 zijn ruimte-indringer met negen kubussen bouwde en de stijl Rubikcubism noemde. Zijn "Mona Lisa" van 330 kubussen werd in 2020 op een veiling verkocht voor 480.200 euro, en in 2022-2023 toonde het MIMA-museum in Brussel meer dan honderd van zijn kubuswerken.
Wat ik het mooist vond, is hoe de auteur het proces beschrijft: eerst een pixelschema in zes kleuren en bij complexere werken Photoshop om de kleuren te controleren. Het is dezelfde weg die elke pixelartiest volgt, alleen zijn de "pixels" hier plastic kubussen. Voor wie met een beperkt palet werkt, is dit een goede reden om vertrouwde technieken eens vanuit een andere hoek te bekijken.
Recentelijk heb ik een uitgebreide handleiding over Aseprite gelezen, waarin de workflow voor pixelart-games in detail wordt beschreven. Ik heb de meest nuttige onderdelen genoteerd, vooral de "standaardconfiguratie" die helpt om fouten te voorkomen.
Canvas: Personages beginnen met een resolutie van 32x32 pixels, vijanden, items en iconen beginnen met 16x16 pixels. De hoofdpersoon kan indien nodig worden vergroot tot 64x64 pixels. De standaardzoom tijdens het bewerken kan worden ingesteld op 800%, maar in het spel moet de weergave 1:1 zijn. Laat je niet misleiden door de vergrote weergave in de editor.
Kleurenpalet: Begin met het DB32-palet van Lospec, bepaal de hoofdkleuren en breid deze indien nodig uit tot 48-64 kleuren. Probeer echter het aantal kleuren per frame te beperken tot maximaal 16. Het kleurenpalet is een "optie", geen "verplichte set". Het is het beste om een consistent hoofdkleurenpalet te gebruiken voor het hele project en deze niet tussentijds te wijzigen, anders kan de stijl van oudere assets niet meer overeenkomen.
Animatie: Standaardsnelheid is 8 FPS voor inactieve animaties, 12 FPS voor aanvallen en 24 FPS voor speciale vaardigheden. Binnen hetzelfde bestand kunnen verschillende frames verschillende duur hebben via de "Frame Duration".
Exporteren: Sprite sheets worden per rij geplaatst, met bijbehorende JSON-gegevens. Bestandsnamen worden gecombineerd als "personagenamen_actienamen" in PNG- en JSON-formaten.
Het meest voorkomende probleem bij het importeren in een game-engine is de filtermethode: Gebruik altijd "Point" als filtermodus, niet "Bilinear". Pixelart heeft geen textuurcompressie nodig. Unity kan de .aseprite-bestanden rechtstreeks importeren met de officiële Aseprite Importer, waardoor de handmatige exportstap wordt overgeslagen.
Er is nog een aanbeveling waar ik het mee eens ben: Identificeer taken die je meer dan tien keer per dag uitvoert en schrijf een klein script van ongeveer 20-30 regels in Lua om deze te automatiseren, één per week. Na een paar maanden bespaar je veel meer tijd dan je denkt.
Een van Raymond Schlitters Pixelblog-tutorials van dit voorjaar gaat over iets wat ik altijd lastig vond: een beurtgebaseerd mechspel in de stijl van Front Mission, getekend op een isometrisch raster. Het is een conceptueel leermiddel, geen echt project, en hij verwijst naar eerdere posts over isometrische projectie.
De mechs worden ongeveer 32x32 pixels groot getekend, kleiner dan de 64x64 of meer die hij gewoonlijk gebruikt, dus details moeten worden teruggebracht tot heel weinig pixels. Zijn methode begint met eenvoudige geometrische vormen voor elk onderdeel en bouwt eerst het lichaam op. De romp moet naar voren steken als de voorkant van een tank, de schouders zijn fors en staan hoger dan het hoofd, en het hoofd blijft laag en gestroomlijnd, met slechts een of twee heldere pixels voor de optiek. De voeten zijn ontworpen voor stabiliteit en lenen van klauwen, scharen en hoeven, want gewone menselijke voeten zien er in deze stijl onhandig uit. Accentstrepen komen als laatste en alleen waar ze de vormen versterken.
Hij schetst drie eenheidstypen: infanterie met ronde vormen, artillerie met een reusachtig kanon dat met het hoofd is versmolten, en jagers met scherpe driehoeken en omgekeerd gebogen poten, elk met een korte tactische notitie.
Het omgevingsdeel is net zo bruikbaar. De basistegel is een kubus van 32x32 waarvan de bovenste ruit hoeken van 2 px heeft, en aangrenzende tegels moeten in een vaste volgorde over elkaar worden gelegd zodat de texturen gelijk aansluiten. Natuurlijke tegels beginnen met een aardetegel met gevarieerde graspatronen erbovenop. Water komt op ongeveer de helft van de hoogte van een gewone kubus, en de animatie loopt in 16 frames door een lijntextuur per frame 1 px naar beneden te schuiven terwijl de highlights afwisselen.
Mijn favoriete zin is de herinnering dat herhalende tegels er goed uit moeten zien wanneer ze over een hele kaart worden herhaald, dus het is de moeite waard de laagopbouw zelf te testen.
De nieuwste Pixelblog van Raymond Schlitter op SLYNYRD is een studie naar 8-bit ninja-platformers, en een goede lezing voor iedereen die graag ziet hoe een complete set game-assets rond één idee wordt opgebouwd. Hij laat zich openlijk inspireren door Ninja Gaiden en werkt de hele tijd met het NES-palet, al houdt hij zich niet strikt aan de hardwarelimieten.
Allereerst de speler. Hij begint met een eenvoudig dummy-sjabloon zodat de animaties vaststaan voordat er ontwerpdetails aan te pas komen, en het felrode pak is gekozen voor de opvallendheid, ook al is het niet erg stealthy. De bewegingen zijn gebaseerd op Ryu Hayabusa: een vlotte sprint, tegen muren klimmen, aan plafonds hangen, een salto en een luchtaanval. Wat ik mooi vond, is de redenering dat het personage stilstaat terwijl het op de grond aanvalt. Dat dwingt tot precisie in gevechten, in plaats van dat je tijdens het rennen op de aanvalknop kunt blijven rammen.
Dan de vijanden: een helikopterkoepel die zijn kanon in vijf richtingen over 180 graden laat zwaaien, een spinnentank die aan muren en plafonds blijft plakken, en een trage cyber-gorilla die als schadesvanger dient. Voor de gorilla gebruikte hij referenties van knokkelloop, tekende hij eerst eenvoudige lichaamsvormen om de beweging goed te krijgen en voegde hij pas daarna de robotdetails toe. Hoofd en lichaam als één onderdeel samenvoegen geeft hem een bewuste stijfheid.
Het omgevingsdeel vond ik het nuttigst. Het gebruikt 16x16-tegels in zes lagen, die elk met hun eigen snelheid scrollen voor het parallax-effect, en een kastprojectie waarbij de diepte-lijnen ongeveer 67,5 graden maken, twee pixels omhoog voor elke pixel opzij, zodat de trappen netjes lopen. Het resultaat wordt getoond in een mockup van 320x180.
Eén ding om te weten: dit is de eerste Pixelblog waarin een van de minitutorials, de volledige frame-uitsplitsing van de ninja, achter een Patreon-betaalmuur staat, terwijl de hoofdles gratis blijft. De assets en bronbestanden worden als apart pakket verkocht. Ik zou graag zien dat iemand deze sprites in een echte spelerscontroller stopt.
Habr heeft een vertaling gepubliceerd van een lang artikel van Karl Svensson over hoe kathodestraalbuizen (CRT's) de pixelart hebben beïnvloed. Het onderwerp is omstreden, en ik vond het goed dat de auteur het niet eens is met de simpele uitleg dat «CRT's alles vervaagden».
Hij begint met een populaire TikTok-video die beweert dat oude kunstenaars rekening hielden met de vervaging van CRT's, waardoor ruwe pixelranden zachter leken. Svensson geeft toe dat dit gedeeltelijk waar is en is het ermee eens dat moderne blokkerige pixelart vaak in onnauwkeurige nostalgie verandert. Maar hij wijst erop dat oude hardware veel meer aspecten heeft om rekening mee te houden. Hij gebruikt zelf nog regelmatig oude CRT's en schakelt daarom de software-CRT-filters in emulators uit, omdat geen enkele volgens hem een echt scherm getrouw weergeeft. Een foto van een Commodore 64 op een Commodore 1084S-monitor laat zien dat ongelijke pixelranden ook op een CRT zichtbaar zijn.
Vervolgens vergelijkt hij twee C64-games. Maniac Mansion (1987) draait op 160×200 en ziet er hoekig uit, terwijl Mayhem in Monsterland (1993) met dezelfde vaste palet van 16 kleuren dithering en afvlakking gebruikt om een hogere resolutie en kleurdiepte na te bootsen. Deze technieken steunen op eigenschappen van de CRT: een lichte vervaging, scanlijnen en een beetje kleurdoorbloeding.
De auteur beschouwt het 16-bittijdperk als de gouden eeuw van de pixelart: Amiga 500, SNES, Atari ST en Mega Drive. De Amiga kon 32 kleuren uit 4096 tonen, en de graphics van games als Silkworm of Ruff'n'Tumble werden geleidelijk beter. Hij behandelt ook de kleurtrucs van CGA en legt uit dat individuele pixels op VGA-schermen met een fijne puntafstand veel beter zichtbaar zijn.
Voor mij was het artikel een goede herinnering: voordat je «retro-vervaging» toevoegt, is het de moeite waard te begrijpen voor welk scherm het origineel is getekend.
In Pixelblog 63 stapt Raymond Schlitter over op de horizontale shoot 'em up en bouwt hij een set assets rond Tweede Wereldoorlog-vliegtuigen die boven een natuurlijk landschap gevechten leveren. Na eerdere stukken over verticale shmups is dit zijn eerste benadering van het horizontale genre, waarbij de kogelpatronen het scherm dwars overgaan in plaats van naar beneden.
Hij begint met het spelersvliegtuig, omdat dat de toon en de resolutie voor al het andere bepaalt. Bij ongeveer 48x32 pixels is er ruimte voor detail zonder dat de animatie duur wordt. Het toestel is gemodelleerd naar de P-51 Mustang. Opvallend vond ik dat hij bij verticale beweging de roll animeert in plaats van de pitch. De neus blijft horizontaal zodat de kogels altijd recht vooruit gaan, en draaien op zo'n lage resolutie geeft toch vaak rommelige pixelclusters. Kortom, roll houdt de sprite schoon en ziet er goed uit.
De animatie gebruikt vijf oriëntaties: één neutraal frame, twee rollstanden omhoog en twee omlaag, plus een propeller die constant draait. Hij geeft ook een ontwerpregel voor hoe het in het spel moet voelen: een tik toont alleen de eerste graad roll, ingedrukt houden toont de volledige helling, en loslaten gaat via de lichte stand terug naar neutraal. Hij raadt aan geen traagheid aan de beweging toe te voegen in een genre dat op precieze reacties draait.
Ook de opties komen aan bod, de kleine capsules die om het schip heen draaien. Naast hun speelfunctie geven ze volgens hem extra aanwezigheid op het scherm, wat helpt om te voelen waar je schip is terwijl je ogen de kogelbanen volgen.
De vijanden zijn Duitse vliegtuigen en een Hummel-artillerievoertuig. Zijn werkwijze begint met een sjabloon in een paar blokkleuren, daarna echte kleuren en basisdetail, dan licht en fijn detail, en de omlijning als laatste. Een palet-wissel maakt het mogelijk de propelleranimatie over vliegtuigen heen te hergebruiken, en hij raadt aan extra frames alleen in te zetten waar het gedrag dat rechtvaardigt. Een praktische les in zuinigheid.
Het Aseprite-team kondigde op 22 juli 2026 aan dat v1.3.18 de nieuwe stabiele versie is. Die bevat bug- en crashfixes, plus de nieuwe functies die sinds v1.3.18-beta1 zijn geïntroduceerd, en is te downloaden via je account op aseprite.org.
De belangrijkste wijzigingen in de hoofdrelease zijn een nieuwe manier om tags binnen groepen op de tijdlijn te scheiden, en een nieuwe optie “spritesheetformaat in een macht van twee” voor het exporteren van spritesheets. Ook zijn er fixes voor het kopiëren van gebruikersdata (kleur en tekst) van tags en slices bij het dupliceren van een sprite, en voor meerdere crashes, zoals het verwijderen van een geplakte selectie of het verbergen van een laag tijdens het verplaatsen van pixels.
De vervolg-puntreleases zijn belangrijk voor wie met tiles werkt. v1.3.18.4 repareerde de uitlijning van Uitlijnen op raster voor kwasten groter dan één pixel en verbeterde het kopiëren en plakken van tiles tussen tilemaplagen. Latere builds repareerden een crash bij het plakken van tilemaps en een crash na het exporteren van een spritesheet als de sprite een selectie had. Geanimeerde GIF-exports gebruiken nu de juiste 89a-header, en grijswaarden-PNG's laden met een grijswaardenpalet.
Voor scripters is er ook nieuws: de Lua-API-versie is naar 41 gegaan, met Dialog:samerow{} en nieuwe sprite-gebeurtenissen voor opslaan (save en beforesave).
Ik hou van release-notes als deze, omdat ze laten zien waar de dagelijkse wrijving zit: rasters, tilemaps en exports. Als je een update uitstelde vanwege een bug bij het kopiëren van tiles, lijkt deze versie de moeite van het proberen waard.
Wie personages in pixelart tekent, komt vroeg of laat de term 'spritesheet' tegen. Ik deel een beginnersuitleg van Keitaro op note, die stap voor stap uitlegt hoe het werkt en die ik nuttig vond.
Een sprite is een 2D-afbeelding die op het spelscherm wordt getoond. Personages, vijanden, items, kogels en effecten vallen hieronder, en een spritesheet is wat je krijgt als je ze in één grote afbeelding verzamelt. Bij een loopanimatie toon je achter elkaar een beeld met de rechtervoet vooruit, een beeld met beide voeten bij elkaar en een beeld met de linkervoet vooruit, en wissel je snel af zodat het eruitziet als lopen. Beweging ontstaat dus door stilstaande beelden te wisselen, niet door video.
Het spel toont de grote afbeelding niet in zijn geheel. Het knipt met coördinaten alleen het frame uit dat nodig is. Als elk frame bijvoorbeeld 128×128 px is en er acht naast elkaar staan, schuift het weergavegebied van 0–127 px naar 128–255 px, enzovoort. Het artikel geeft ook een voorbeeld waarbij de horizontale as 8 richtingen zijn en de verticale as acties (lopen, aanvallen, geraakt worden, verdedigen), dus 8 richtingen × 7 toestanden, in totaal 56 frames.
Bij praktisch gebruik komt het volgens het artikel vooral aan op het uitlijnen van het referentiepunt in elk frame. Als de voeten van beeld naar beeld een paar pixels verschuiven, lijkt het personage tijdens de animatie op en neer te trillen. Een transparante achtergrond is ook onmisbaar.
Tot slot legt het artikel het verschil uit tussen een spritesheet, gewoon een verzameling bijbehorende afbeeldingen, en een spriteatlas, die meerdere afbeeldingen in één textuur verpakt voor een efficiëntere weergave. Wat mij het meest bijbleef, is de conclusie dat het maken van de beelden minder moeilijk is dan ze in een vorm te brengen die het spel correct kan gebruiken. Ik denk dat dit ook pixelartists helpt, vooral bij het exporteren.
In pixelart-achtergronden zijn rotsen een klein maar verrassend tijdrovend onderdeel. In het pixelnieuws van vrijdag introduceerde de schrijver van note おかか容疑者 de Aseprite-extensie «Rock Generator for Aseprite».
De extensie wordt op itch.io gepubliceerd. Het is een productietool die uitsluitend voor rotsen bedoeld is: je haalt rotsen binnen als 3D-meshes en kunt ze vervolgens als pixelart gebruiken. Al op de downloadpagina zie je veel parameters, en het artikel stelt dat juist de focus op rotsen de tool zo fijn instelbaar maakt.
Volgens het artikel zijn er 10 voorgedefinieerde vormen, 21 voorgedefinieerde structuren en 72 looks (uitstraling). Je kunt er ook met mos bedekte en besneeuwde rotsen mee maken, dus het lijkt handig voor het bouwen van achtergronden. De interface ondersteunt 27 talen, waaronder Japans.
Het is een betaalde tool, vanaf 4,99 Amerikaanse dollar (ongeveer 800 yen) in oktober 2026. Onderaan de pagina staat een proefversie, maar volgens het artikel bevat die alleen voorbeeldafbeeldingen van het resultaat. Als je dat wilt controleren voordat je koopt, is het goed om dat te onthouden.
Rotsen modelleren in Blender of een ander programma en ze daarna in Aseprite importeren kon al. Toch lijkt het efficiënt om rotsen grof direct in Aseprite zelf te kunnen maken, en dat kan handig zijn wanneer je veel pixelart-achtergronden moet maken. Ik twijfel altijd over hoe ik verschillende steentexturen moet schilderen, dus nieuws over zulke hulpmiddelen is echt welkom.
Het pixel-artfestival “Pixel Art Park 9 (PAP9)” wordt zondag 11 oktober 2026 gehouden in Pacifico Yokohama. De exposanten van dit jaar worden voorgesteld in een note-artikel van de heer Morita, van het gamebedrijf Ixeal in Nerima.
Ixeal doet mee als sponsor. Het bedrijf toont twee volledig nieuwe, originele games die speciaal voor PAP9 zijn ontwikkeld; in het artikel wordt er één voorgesteld: 『Magical Soup』.
Het idee is om “verborgen smaken” te vangen om soep te maken. Er zijn drie soorten verborgen smaak: “normaal”, “gevaarlijk” en “magisch”. De combinatie bepaalt welke soep je kunt maken. Spelers krijgen ook een sticker van hetzelfde type als de soep die ze hebben gemaakt. Het spel komt van het team achter 『JUST Onigiri』, dat op de vorige PAP8 te zien was.
Het tweede spel en nieuwe pixel-artproducten worden in latere artikelen voorgesteld.
Het klinkt als een leuk evenement voor pixel-artliefhebbers, met dingen om te spelen en vast te houden. Zien hoe pixel art in een game beweegt, en direct met de makers kunnen praten, lijkt een zeldzame kans. Als je in de buurt woont, is het misschien de moeite waard om even langs te gaan.
