Nyligen läste jag Juniper Devs guide till pixelkonst och sammanställde de viktigaste punkterna, från val av program till avancerad färgläggning, till en samling anteckningar som jag vill dela med alla som också vill komma igång.
När det gäller program rekommenderar jag Aseprite: gränssnittet är användarvänligt och funktionerna för animation och tilesets är gjorda för spelutveckling. Vill du inte betala kan du använda LibreSprite, som är öppen källkod, eller webbversionen Piskel som gratisalternativ. Vad gäller färger brydde jag mig inte om färglära i början utan använde färdiga paletter från Lospec direkt, och först efter att ha ritat mycket började jag sätta mig in i det. Förbered minst tre färger per material (grundfärg, skugga och högdager), så får du en grundläggande känsla av volym.
När du ritar linjer, kom ihåg att ta bort överflödiga pixlar; med Pixel Perfect aktiverat i Aseprite blir det mycket renare. Gör pixelsegmentens längder symmetriska i kurvor (till exempel 1-2-3-2-1), så blir linjerna mycket mjukare. När du färglägger, använd närliggande färger på färghjulet till skuggor eller högdagrar, så blir bilden mer livfull; undvik också ”kuddskuggning”: bestäm först ljuskällans riktning och ljussätt sedan allt enhetligt. Dithering och kantutjämning är två mycket praktiska knep: det ena skapar en övergångstextur, det andra gör kanterna jämnare.
Konturlinjer behöver inte vara helt svarta; prova en mörkare version av objektets egen färg. Till sist ett råd till utvecklare: stapla inte för många färger, eftersom fler än tre för samma material lätt blir rörigt. Titta ofta på en förminskad förhandsvisning för att se till att allt fortfarande är tydligt i liten storlek. Det viktigaste är att njuta av processen, och det betyder mer än att fastna i jakten på ”det perfekta resultatet”.
Källa: 32comic
Pixelblog 62 handlar om landskapsbakgrunder, och den gör en poäng som jag håller med om: bakgrunder bör inte hamna längst bak i produktionsprioriteringarna. De etablerar miljön och drar in spelarna i världen, men de måste också tjäna spelupplevelsen. I plattformsspel och shmups kan de behöva dämpas så att sprites är lätta att läsa, medan de i turbaserade rollspel kan vara rika och uppslukande.
För den här lektionen fokuserar Raymond Schlitter på stridsscener i ett påhittat turbaserat JRPG, inspirerat av Dragon Quest och Phantasy Star 4, med utrymme längst ner för hjältar sedda bakifrån. Utmaningen han sätter är att skapa en övertygande känsla av djup med 16 färger eller färre.
Han väljer en duk på 192x144. Den har 4:3-format, ryms inom vanliga upplösningar för 8- och 16-bitarskonsoler och delar sig väl om man senare vill ha pixelperfekt parallaxrullning. Arbetet börjar med heltäckande horisontella band i färg som definierar horisonten, sedan delas mark och himmel upp i fler band. Hans huvudpoäng är att djupet mest kommer från färgvalet, enligt luftperspektiv: det närmaste planet är mest mättat och har starkast kontrast, och varje plan längre bort tappar mättnad, blir ljusare och förskjuter nyansen mot himmelsfärgen. Under en klarblå himmel är det närmaste gräset varmast och de avlägsna planen glider mot blått.
Efter färgplanen lägger han till två bergslager med färger från himmelsbanden och går sedan in på detaljer. Gräset består av många korta vertikala streck på en pixel, och nyckeln är konsekvens i gruppering och skala. Han visar varje steg som en separat bild så att man kan följa i sin egen takt. Det är en användbar läsning om dina paletter känns platta.
Källa: SLYNYRD
På Habr hittade jag en lång artikel om hur Rubiks kub blev ett konstnärligt material, och den har mycket att ge åt den som gillar pixelkonst. Författaren har under flera år gjort mosaiker av kuber och förklarar varför genren ligger så nära digital grafik.
Huvudtanken är enkel: en färgad ruta på sidan av en kub är i praktiken en pixel. Varje sida har nio rutor och paletten har sex färger, så flera kuber tillsammans bildar en bild i låg upplösning, som liknar skärmen på en gammal dator eller en spelautomat. Tidpunkten stämmer också: 8-bitarspelens guldålder med Space Invaders, Pac-Man och Donkey Kong sammanföll med Rubiks kub-febern i början av 1980-talet. Enligt författaren användes termen "pixel art" första gången 1982 av Adele Goldberg och Robert Flegal på Xerox.
Artikeln går sedan igenom genrens historia. De tidigaste experimenten tillskrivs den brittiske konstnären Fred Holly i mitten av 1980-talet. Under 1990-talet dokumenterade programmeraren Jacob Devenport mosaiker av några dussin kuber, däribland den första tvåsidiga. Det verkliga genombrottet kom från den franske gatukonstnären Invader, som 2004 byggde sin rymdinkräktare av nio kuber och kallade stilen Rubikcubism. Hans "Mona Lisa" av 330 kuber såldes på auktion 2020 för 480 200 euro, och 2022–2023 visade museet MIMA i Bryssel över hundra av hans kubverk.
Det jag gillade mest var författarens beskrivning av arbetsgången: först ett pixelschema i sex färger och för de mer komplexa verken Photoshop för att kontrollera färgerna. Det är samma väg som varje pixelkonstnär går, fast här är "pixlarna" plastkuber. För den som arbetar med en begränsad palett är det ett bra skäl att titta på bekanta tekniker från en annan vinkel.
Källa: Habr
Jag har nyligen läst en omfattande guide om Aseprite som beskriver arbetsflödet för pixelbaserade spel i detalj. Jag har noterat de delar som jag tyckte var mest användbara, särskilt de "standardinställningar som minskar risken för fel".
Canvas (arbetsyta): Karaktärer börjar på 32x32 pixlar, fiender, rekvisita och ikoner börjar på 16x16 pixlar, och huvudkaraktären kan förstoras till 64x64 pixlar vid behov. Som standard kan zoomnivån under redigering ställas in på 800%, men i själva spelet ska renderingen vara 1:1. Låt dig inte luras av den förstörda vyn i redigeraren.
Färgpalett: Börja med DB32 från Lospec, bestäm sedan de primära färgerna och utöka vid behov till 48–64 färger. Försök att hålla antalet färger som används i en enskild bild till maximalt 16. Färgpaletten är bara en "uppsättning tillgängliga färger", inte en "uppsättning färger som måste användas". Det är bäst att använda en enda huvudfärgpalett för hela projektet och undvika att byta den under utvecklingen, eftersom det kan leda till att äldre tillgångar får en annan stil.
Animation: 8 FPS för viloläge, 12 FPS för attacker, 24 FPS för speciella förmågor. Olika frames kan ha olika varaktighet genom att använda "Frame Duration" i samma fil.
Export: Sprite sheets ska ordnas radvis och åtföljas av JSON-data. Filnamnen ska para ihop PNG-filer med JSON-filer med namnet "karaktärsnamn_åtgärdsnamn".
Den vanligaste fallgropen när man importerar till en spelmotor är filtreringsmetoden: Använd alltid "Point" som filterläge, använd inte "Bilinear". Pixelbilder behöver inte heller texturkomprimering. Unity kan använda den officiella Aseprite Importer för att importera .aseprite-filer direkt, vilket sparar steget att exportera manuellt.
Det finns också ett förslag som jag håller med om: Identifiera åtgärder som utförs mer än tio gånger om dagen och skriv ett litet skript på cirka 20–30 rader i Lua för att automatisera dem, en gång i veckan. Under några månader sparar du mycket mer tid än du tror.
Du kan börja välja färgpalett här:
https://lospec.com/palette-list
Källa: Xmohe's Independent Game Box.
Ett av Raymond Schlitters Pixelblog-tutorials från i våras tar upp något jag alltid tyckt var knepigt: ett turbaserat mechspel i Front Mission-stil, ritat på ett isometriskt rutnät. Det är ett pedagogiskt koncept, inte ett riktigt projekt, och det hänvisar till hans tidigare inlägg om isometrisk projektion.
Mechen ritas ungefär i 32x32 pixlar, mindre än hans vanliga 64x64 och större, så detaljerna måste förenklas till mycket få pixlar. Hans metod är att börja med enkla geometriska former för varje del och bygga kroppen först. Bålen ska skjuta fram som en stridsvagns front, axlarna är kraftiga och sitter högre än huvudet, och huvudet hålls lågt och slankt med bara en eller två ljusa pixlar för optiken. Fötterna designas för stabilitet och hämtar inspiration från klor, klor och hovar, eftersom vanliga humanoida fötter ser tafatta ut i den här stilen. Accentränder läggs till sist och bara där de förstärker formerna.
Han skissar tre enhetstyper: infanteri med runda former, artilleri med ett gigantiskt kanonrör sammansmält med huvudet och jaktplan med vassa trianglar och omvänt böjda ben, var och en med en kort taktisk notering.
Miljödelen är lika användbar. Grundrutan är en 32x32-kub vars övre romb har 2 px långa hörn, och intilliggande rutor måste läggas på varandra i en konsekvent ordning så att texturerna ligger jämnt. Naturrutor börjar med en jordruta med olika grästexturer ovanpå. Vatten ligger på ungefär halva höjden av en vanlig kub, och dess animation loopar över 16 bildrutor genom att en linjetextur flyttas 1 px nedåt per bildruta medan highlights växlar.
Min favoritrad är påminnelsen om att upprepade rutor måste se bra ut när de upprepas över en hel karta, så det är värt att testa lagringen själv.
Källa: SLYNYRD Pixelblog
Raymond Schlitters senaste Pixelblog på SLYNYRD är en studie av 8-bitars ninjaplattformare, och en bra läsning för alla som gillar att se en hel uppsättning spelgrafik byggas kring en enda idé. Han tar öppet sin inspiration från Ninja Gaiden och arbetar med NES-paletten genom hela processen, även om han inte följer hårdvarubegränsningarna strikt.
Spelarfiguren kommer först. Han börjar med en enkel dockmall så att animationerna blir klara innan några designdetaljer läggs på, och den skarpröda dräkten valdes för att den ska synas, även om den inte är särskilt smygande. Rörelserna bygger på Ryu Hayabusa: snabb löpning, klättring på väggar, hängande i tak, en volt och en luftattack. Det jag gillade är resonemanget att figuren står stilla när den attackerar på marken. Det tvingar fram precision i mötena i stället för att man bara kan trycka på slaget medan man springer.
Sedan kommer fienderna: ett helikopterbeväpnat torn som sveper kanonen över 180 grader i fem riktningar, en spindeltank som klamrar sig fast vid väggar och tak, och en långsam cybergorilla som fungerar som skademagnet. För gorillan utgick han från referenser av knogegång, blockade först ut enkla kroppsformer för att få rörelsen rätt och lade till robotdetaljerna efteråt. Att slå ihop huvud och kropp till en del ger den en avsiktlig stelhet.
Miljödelen var den jag tyckte var mest användbar. Den använder 16x16-rutor i sex lager, där varje lager rullar i sin egen hastighet för parallaxeffekten, och en skåpsprojektion där djupledarna går i cirka 67,5 grader, två pixlar upp för varje pixel åt sidan, så trappstegen blir rena. Resultatet visas i en 320x180-mockup.
Ett till som är värt att veta: det här är första Pixelblogen där en av minilektionerna, den fullständiga bildgenomgången av ninjan, ligger bakom en betalvägg på Patreon, medan huvudlektionen är gratis. Tillgångarna och källfilerna säljs som ett separat paket. Jag skulle gärna se någon lägga in de här spriterna i en riktig spelarkontroller.
Källa: SLYNYRD
Habr har publicerat en översättning av en lång artikel av Karl Svensson om hur katodstrålerör (CRT) påverkade pixelkonsten. Ämnet är omstritt, och jag gillade att författaren inte håller med om den enkla förklaringen att «CRT:er suddade ut allt».
Han börjar med en populär TikTok-video som påstår att äldre konstnärer tog hänsyn till CRT-skärmarnas oskärpa, vilket gjorde grova pixelkanter mjukare. Svensson medger att detta delvis stämmer och håller med om att modern blockig pixelkonst ofta blir till en oprecis nostalgi. Men han påpekar att den gamla hårdvaran har många fler aspekter att ta hänsyn till. Han använder fortfarande gamla CRT-skärmar regelbundet, och stänger därför av programvarufiltren för CRT i emulatorer, eftersom han menar att inget av dem återger en verklig skärm troget. Ett foto av en Commodore 64 på en Commodore 1084S-skärm visar att ojämna pixelkanter syns även på en CRT.
Därefter jämför han två C64-spel. Maniac Mansion (1987) körs i 160×200 och ser kantig ut, medan Mayhem in Monsterland (1993) använder dithering och utjämning med samma fasta 16-färgspalett för att efterlikna högre upplösning och färgdjup. Dessa tekniker bygger på CRT-skärmens egenskaper: en svag oskärpa, bildlinjer och lite färgläckage.
Författaren ser 16-bitarseran som pixelkonstens guldålder: Amiga 500, SNES, Atari ST och Mega Drive. Amigan kunde visa 32 färger av 4096, och grafiken i spel som Silkworm eller Ruff'n'Tumble blev gradvis bättre. Han går också igenom färgknep från CGA och förklarar att enskilda pixlar syns mycket bättre på VGA-skärmar med fin punktavstånd.
För mig var artikeln en bra påminnelse: innan man lägger till en «retrooskärpa» är det värt att förstå vilken skärm originalet ritades för.
Källa: Habr
I Pixelblog 63 vänder sig Raymond Schlitter till det horisontella shoot 'em up-spelet och bygger en uppsättning grafik kring flygplan från andra världskriget som strider över ett naturligt landskap. Efter tidigare artiklar om vertikala shmups är det hans första ansats till den horisontella varianten, där kulmönstren går tvärs över skärmen i stället för nedåt.
Han börjar med spelarens flygplan, eftersom det sätter tonen och upplösningen för allt annat. Med cirka 48x32 pixlar finns det plats för detaljer utan att animationen blir dyr. Planet är modellerat efter P-51 Mustang. Det jag tyckte var intressant är att han animerar rullningen i stället för nickningen när planet rör sig vertikalt. Nosen hålls i våg så att kulorna alltid går rakt fram, och rotation i så låg upplösning ger ändå oftast brusiga pixelklungor. Kort sagt håller rullningen sprite:en ren och den ser bra ut.
Animationen använder fem riktningar: en neutral bildruta, två rullningslägen uppåt och två nedåt, plus en propeller som snurrar hela tiden. Han ger också en designregel för hur det ska kännas i spel: ett kort tryck visar bara första graden av rullning, att hålla inne visar hela lutningen, och när man släpper går det tillbaka genom den lätta posen till neutralt läge. Han avråder från att lägga tröghet i rörelsen i en genre som bygger på exakta reaktioner.
Alternativen, de små kapslarna som kretsar runt skeppet, tas också upp. Utöver deras speluppgift menar han att de ger närvaro på skärmen, vilket hjälper dig att känna var ditt skepp är medan ögonen följer kulbanorna.
Fienderna är tyska flygplan och ett Hummel-artillerifordon. Hans arbetsgång börjar med en mall i några blockfärger, sedan riktiga färger och grundläggande detaljer, därefter ljus och finare detaljer, och konturerna sist. Ett palettbyte gör att propelleranimationen kan återanvändas över flera plan, och han föreslår att man bara lägger extra bildrutor där beteendet motiverar det. Det är en praktisk lektion i sparsamhet.
Källa: SLYNYRD
Aseprite-teamet meddelade den 22 juli 2026 att v1.3.18 är den nya stabila versionen. Den innehåller buggrättningar och krockrättningar samt de nya funktioner som införts sedan v1.3.18-beta1, och kan laddas ned från ditt konto på aseprite.org.
De främsta ändringarna i huvudversionen är en ny separation av taggar inom grupper i tidslinjen och ett nytt alternativ “sheet-storlek i tvåpotens” för export av spritesheets. Det finns också rättningar för kopiering av användardata (färg och text) för taggar och slices när en sprite dupliceras, samt flera krascher, till exempel vid borttagning av en inklistrad markering eller när ett lager döljs medan pixlar flyttas.
De efterföljande punktutgåvorna är viktiga för den som arbetar med tiles. v1.3.18.4 rättade justeringen av Fäst vid rutnät för penslar större än en pixel och förbättrade kopiering och inklistring av tiles mellan tilemap-lager. Senare byggen rättade en krasch vid inklistring av tilemaps och en krasch efter export av ett spritesheet när spriten hade en markering. Exporter av animerade GIF-filer använder nu korrekt 89a-header, och PNG-filer i gråskala laddas med en gråskalepalett.
För skriptskrivare finns också nyheter: Lua-API-versionen har gått upp till 41, med Dialog:samerow{} och nya händelser för att spara sprite (save och beforesave).
Jag gillar releasenoteringar som den här eftersom de visar var det krånglar i vardagen: rutnät, tilemaps och exporter. Om du har skjutit upp en uppdatering på grund av en bugg vid kopiering av tiles verkar den här versionen vara värd att testa.
När man börjar rita figurer i pixelkonst stöter man förr eller senare på begreppet "spritesheet". Jag delar en nybörjarförklaring som Keitaro skrivit på note. Den går igenom hur det fungerar steg för steg, och jag tyckte den var till nytta.
En sprite är en 2D-bild som visas på spelets skärm. Figurer, fiender, föremål, skott och effekter räknas hit, och ett spritesheet är vad man får när man samlar dem i en stor bild. För en gånganimation visar man i tur och ordning en bildruta med högerfoten fram, en med fötterna ihop och en med vänsterfoten fram, och byter snabbt så att det ser ut att gå. Med andra ord kommer rörelsen från att man byter stillbilder, inte från video.
Spelet visar inte hela den stora bilden. Det klipper med koordinater ut bara den bildruta som behövs. Om varje bildruta är 128×128 px och åtta står bredvid varandra, flyttar visningsområdet sig från 0–127 px till 128–255 px och så vidare. Artikeln ger också ett exempel där den vågräta axeln är 8 riktningar och den lodräta är handlingar (gå, attackera, bli träffad, försvara sig), alltså 8 riktningar × 7 tillstånd, totalt 56 bildrutor.
Vid praktisk användning är det enligt artikeln viktigast att samma referenspunkt ligger rätt i varje bildruta. Om fötterna glider några pixlar från bild till bild verkar figuren skaka upp och ner under animationen. Att bakgrunden är transparent är också ett måste.
Till sist förklaras skillnaden mellan ett spritesheet, som bara är en samling relaterade bilder, och en spriteatlas, som packar flera bilder i en enda textur för effektivare rendering. Det som fastnade mest hos mig var slutsatsen att det är lättare att måla bilderna än att få dem i en form som spelet kan använda rätt. Jag tror att det också hjälper pixelkonstnärer, särskilt vid exporten.
Källa: note (Keitaro)
I bakgrunder för pixelkonst är stenar en liten men förvånansvärt tidskrävande del. I fredagens pixelnyheter presenterade skribenten på note おかか容疑者 Aseprite-tillägget «Rock Generator for Aseprite».
Tillägget publiceras på itch.io. Det är ett produktionsverktyg helt inriktat på stenar: det hämtar in stenar som 3D-nät och låter dig använda dem som pixelkonst. Redan på nedladdningssidan syns en mängd parametrar, och artikeln menar att det just är fokuset på stenar som gör att man kan justera dem så detaljerat.
Enligt artikeln finns 10 färdiga former, 21 färdiga strukturer och 72 looks (utseenden). Man kan också skapa mossbeklädda och snötäckta stenar, så det verkar smidigt för att bygga bakgrunder. Gränssnittet stöder 27 språk, bland annat japanska.
Det är ett betalverktyg och kostar från 4,99 US-dollar (cirka 800 yen) i oktober 2026. Längst ner på sidan finns en testversion, men enligt artikeln innehåller den bara exempelbilder av resultatet. Om du vill kontrollera det innan du köper, är det bra att komma ihåg.
Det gick redan tidigare att modellera stenar i Blender eller ett annat program och importera dem till Aseprite. Ändå verkar det effektivt att kunna skissa fram stenar direkt i Aseprite, och det kan vara användbart när man behöver ta fram många pixelkonstbakgrunder. Jag brottas alltid med hur jag ska måla olika stenstrukturer, så nyheter om sådana hjälpverktyg är verkligen välkomna.
Källa: note (おかか容疑者)
Pixelkonstfestivalen “Pixel Art Park 9 (PAP9)” hålls söndagen den 11 oktober 2026 på Pacifico Yokohama. Årets utställare presenteras i en artikel på note av Herr Morita, som arbetar för spelutvecklingsföretaget Ixeal i Nerima.
Ixeal deltar som sponsorföretag. De visar upp två helt nya originalspel som utvecklats för PAP9, och artikeln presenterar ett av dem: 『Magical Soup』.
Tanken är att fånga “dolda smaker” för att koka soppa. Det finns tre sorters dolda smaker, “normal”, “farlig” och “magisk”, och kombinationen avgör vilken soppa man kan göra. Den som spelar får också ett klistermärke av samma typ som soppan de har gjort. Spelet kommer från teamet bakom 『JUST Onigiri』, som ställdes ut på förra PAP8.
Det andra spelet och nya pixelkonstprodukter kommer att presenteras i senare artiklar.
Det låter som ett roligt evenemang för den som älskar pixelkonst, med saker att spela och ta på. Att se hur pixelkonst rör sig i ett spel och kunna prata direkt med skaparna verkar vara ett sällsynt tillfälle. Bor du i närheten kan det vara värt ett besök.
