Accurate NES swatch for Photoshop, etc

Photoshop is great if you want to construct sprite overlays to your NES backgrounds or draw cutscenes and make use of layers or drawing tools while doing so.

Here’s a complete NES master palette swatch (each named after its NES colour ID)  so you don’t have to construct it from scratch.

Note that the two white swatches are there to remind you that the NES does have two identical whites in the 0 column, which can be used for preserving text whiteness while dimming the rest of screen, for example. It also helps to keep the colours tidy and easy to navigate in the swatch bar. While there are many black definitions (some with a minute difference in actual darkness) in the NES master palette, this one only keeps the one which is regarded ”safe to use” on all monitors and setups.

Tip: It is also possible to load the swatch as a palette index definition in indexed colour mode, which is often very useful and generally safer / less tedious to be in when doing NES graphics in photoshop.

Regrettably, adobe never thought to combine indexed mode with layering functionality, so i usually keep two work files side by side for carrying out actions in whatever mode is more suitable, and thereby preserve layers.

The swatch is modelled after Firebrandx ”classic nes” palette, which offers a great accuracy/neutrality while also maintaining the blues and greens identifiable, which is sometimes a problem with some palettes for some emulators and drawing tools out there.

For using the same palette in NESST 2.4, download firebrandx:s classic master palette here, and put the .pal file in your NESST root folder.

Firebrandx:s homepage with several additional palette captures can be found here.


Original Project Blue concept recovered

I was combing through my drive for materials for the upcoming Kickstarter campaign – oh that’s right, it’s coming this month just in time for Portland Retro Gaming expo! – and found the original concept art for the first zone in Project Blue, which i thought was long gone in a disk failure.
At the time, i had just read Cixin Lius’ Three Body Problem and was under heavy inspiration from its description of a fictional high-end, heavily computerized military-governed science base in rural 70s China. Maybe attributable to Liu being a plant engineer for a living, his descriptions felt so vivid and accurate i could almost touch them, even through the curtain of translation practicalities. This concept, of which most ended up in the game, is of course heavily sci-fied and cartoonized, and therefore somewhat remote from the source of inspiration. What the narrative of the game would be (which is pretty simple, NES style) was still fairly up in the air.  Little did i know at that point that we would situate the rest of the game in a not too remote location – a fictional, future version of Hong Kong called Neo Hong Kong.

Level design wise, Project Blue quickly took a sharp turn from a meandering doom-inspired metroidvania (you’d flick switches and find passkeys to open ways to new areas) to a more action-oriented pacing that worked better with the flick-screen handling of the ”camera” – with just a few alternate routes sprinkled here. Similarly, the original idea for the nesdev compo idea was to infiltrate the base and stop some computer maniac, but we eventually changed it to being a test subject escaping the clutches of a mega corporations’ shadier side of business.

Good news for backers around the world

Project Blue, the full version, will be manufactured and shipped from both the US and the EU. In addition to fewer backers being hit by customs fees, double VAT and other nasty things, it also means a handful of countries outside these regions will have a better shipping rate estimate than if shipped from the US solely!

finalArtboard 1.png

For more frequent updates, visit my twitter account!

The PAL luma mystery

On a NES PAL sytem, stylized horizontal gradient lines of the same brightness will blend into each other and create a richer colour presence, whether intended or unintended.

If two colours above/below each other are of opposite phase and equal brightness, the resulting colour should be gray.

However, i encountered a display quirk the other day – instead of a gray line, i got a black and white ripple. It seems as if *something* is causing the luma channel to oscillate between high and low.


before/after resolving the problematic effect

After a little experimentation, it turned out that this may be trigged or avoided depending on whether the change of colour is on an even or odd scanline.

I haven’t ruled out hardware deviance just yet, but simply nudging the border upwards solved the problematic effect.

PAL gamers will experience more colours in the sky for the ending scene of Project Blue. It wasn’t intended at first, but i think it looks quite nice.

Update before Campaign

Good news! All the programming is done, and the feature set thereby locked in. My next update will be in a new thread, and it will contain campaign and release info for sure.

We’re still working hard on level design and campaign materials, but it’s a downhill slide from here.

Here’s some sneak peeks (click for a slightly better view):

The following are from the level editors’ view from some screens i’m currently working on. The thin blue line on the first one is the bounding box for the inWater property, and is not shown in game.

Special Features

There’s normal and hard mode. Hard mode actually changes the layout of the levels a bit, not just makes enemies generically harder. It’s all about terrain and positions.

-but wait, there is more! There’s also a ”custom” game mode slot which loads in a user-created set of up to 4 levels, provided you’ve patched one such mod in to the ROM file or cartridge. We will release a level editor with a built-in patcher for your convenience.  

That’s all for now.

I think we’ve got a clear picture on how we want to structure the campaign already, but let me know if there’s any add-ons, tiers or whatever that you’d really like to see. I won’t promise anything on that front (while we have some things in mind already, the game itself and its viability is the most important thing) but input is always welcome.

Contact me directly or write in the appropriate nesdev or nintendoage threads.

Inherent Smile behind the scenes

Last years’ NESdev compo, i drew and animated the title, ending and battle modes for calima’s ”Inherent Smile”.


The game has the technical merit of being the first functional 3d maze game to be released for the NES. It also included two vastly different and ambitious subgames – a somewhat fully fledged RPG battle system with a hint of punch-out type timing mechanics, and a character dressing game. More on that later.

As it turned out, i was a tad naïve both when it came to available time and just about how much animation and inventory data we could fit into the compos’ mapper restrictions along with the game, and so some things had to get trimmed or cut out altogether while some other things were left a bit unfinished. The files are sitting in a dark corner of my project folder so i thought it may be time for a little show and tell. I honestly don’t remember exactly what made the cut and in what shape, but here’s some highlights and design-wise points of interest regardless whether they made it or not:

Most famously the final boss was missing (on strike, as the end text would tell you). It was to be animated on the background layer with the help of scrolling. The player would stand on a cliff on the sprite layer. I thought i had a mockup of that but can’t find it at the moment. So here’s just the background layer.
Note that the tail goes missing in a few frames – it’s not for any technical reason, but rather that i never got it completely finished. The punch out nature of these RPG battles would’ve become apparent in this battle if not earlier, since the minotaur is literally finting and punching as its standard attack.

Given the amount of time i spent on it, don’t be surprised if i recycle it into another project.

Here’s a snapshot from my workspace including the cliff. It also shows the spriteset in some state. To fit it all, i opted to reuse some tiles from the cube enemy in another palette as part of the cliff. worskpace


blobjump sneezing
The sneezoid had a bit more detail to its jump as i recall it, but it still was fully functional.

The possessed lantern would have three subtly different patterns to hint at actions and when to time a block. It was made with position animation. of just 4 tiles, which helped:
I don’t recall if all of it made it, or just a subset.

I don’t think this lightning spell got into the game quite this way, but either way i’m not terribly proud of how it turned out – it was a bit of a rushjob towards the end, iirc. Compare it to the mockup of electric arcs in Project Blue, which looks and feel more natural:

On the other hand, the electric attack in Inherent Smile was made using only a a couple of tiles thanks to the help of mirror bits, so it’s resources are well justified. I didn’t get the animation pattern quite right though.

Here’s a funny one. The bat didn’t make it into gameplay at all iirc, because we simply didn’t have more room to spare for animations. It was a blessing in disguise because i wouldn’t have had time to fix that very pelvic nature of its attack. You can still find the tiles in the ROM, i believe.

The ghost was to use this wavy pattern when preparing spells – it’s a little bit cheap but works okay. It did make it into the game in some form, but not quite as was planned iirc.

I originally had fantasies about animating this molten iron river, but quickly realized there were more important priorities.

One thing i’m particularily proud of was the paper doll dressing subgame – equipping different items would visibly alter the character. There were even colour coded set items. It worked because of careful placement of enemies and player on the battle scenes.
Here’s the basic unequipped player running.

And here’s a still frame of the player attacking with equipment.

He’re some of the possible combinations of gear – the player would pick and experiment freely. Unfortunately, we didn’t find the time (or space) to balance it against the general difficulty scheme. The easiest way to beat the game is to find the exit quickly, rather than taking time experimenting. It’s sort of hard to describe, but there litterally wasn’t even a handful of bytes left to make it more nuanced.

All of these items and more were in the game iirc. Again, the bat didn’t make it.

Here’s the rat taunting you. I remember that was in the game.

The vines on the title screen, just like the general theme of the game was inspired by greek mythology, was inspired from a classic-time greek ornament. They were put on the sprite layer:
For those who’re interested in the game, it was part of NESdev compo 2017 and combines realtime 3d maze crawling with said paper doll system and RPG battles with a little nice touch of timing attacks and blocks. The game is part of the next action 53 multigame cartridge, once it is released. Thanks to calima for having me along the adventure of making it, and for angelic patience towards the end.




Say hi!

Just introducing the proposed heroine for a game i’m designing for a museum. The setting is this: A few hundred hears from now, the swedish westcoast needs to be sanitized, badly. Armed with her wits and protected by her trusty yellow raincoat, how much trash can she sanitize before the sun sets and the coastal, flooded ruins of our time become too dangerous? She might even find some rare collectibles among the floating scrap.


Some of the game objects you may encounter. Do not trust the seagull. items

ca65 programming tricks: Trimming and merging tileset assets

Don’t want to copy, paste, trim, split or concatenate binary files (such as tilesets and other rodata, or precompiled programs) manually in your NES project?

if using ca65, you’ll be happy to know that the .incbin directive is rather versatile. You can add an offset and a specified length of bytes you want to use, like so:

.incbin ”myTileset.chr”, 0, 3328
.incbin ”myOtherTileset.chr”, $D0 * $10, 768

Since tilesheets are a common target for the .incbin directive, it may be easier to multiply any parameter by $10 if you’re counting tiles, rather than bytes. (one tile = 16 bytes = $10 bytes in hexadecimal).

Here, it was used to provide a reusable method to paste 3 rows of HUD elements from one level sheet and the rest of the other level sheet, making a new one.

Okay, so the practical example is a bit unwarranted since you can achieve the same in one line in bash on linux or powershell on windows.. But it is still convenient to know how to do this inside a project, and you can of course replace these magic numbers with defined constants, make the cc suite compile assets for you from smaller modules, and so on.

You can download the zip here, containing the .bat, .cfg and .s files that make up the example. The graphics have been replaced with something that’s just there to make it work. Naturally, you need to edit paths to fit your environment/preference.


HALCYON: Position animation and tile reusage

Happy new year! Here’s some dog- and bird-friendly fireworks

Most explosion type animations on classic NES games keep to a 16×16 pixel pattern (that is, 2 by 2 8×8 pixel sprites). There are some ramifications that encourage this, but it’s not a hard limit. The main one being the famed sprites per scanline limit, which means only 8 sprites can be shown at the same horizontal line at any one time, leading to sprite cancellation (or flickering if the programmer has seen to it that the PPU takes turns showing up to 8 at a time). Another is that some game engines limit how an objects’ sprites may be positioned in a compromise between simplicity and utility. And sometimes, that’s what you want.

A bit on the technical side, but for HALCYON i’m simply exporting raw chunks of Object Attribute Memory (OAM) data for each animation cel, which is in a way the simplest and most versatile way to handle metasprite animation. Positions can be made relative by adding object position to the OAM position. Additionally, you can hard-code palette, layer priority and mirror-flip attributes into them to be manipulated (or not), and used (or mask-ignored at will) by the object handler. One way to know where one metasprite ends and another starts is to include a terminator message in the form of a byte after all the metasprite data of an object or animation cel is done. For example, a value of 128 will set off the signed math flag which can be used to determine this, or if you really need bigger offsets than 127, you could let $FF be the terminating value. INC, INX or INY it once, and test the zero bit. The rationale for this is that the first byte is the Y position, and you’re completely unlikely to give any sprite an Y axis offset so great that the metasprite component will be be put offscreen or wrap around to the other side. A metasprite handler like that could use the same object handler for sprite overlays on title screens and the like, aswell as gameplay objects (at the same time even), but i’m getting way off topic.

Anyway, this allows objects to be position animated.

I want the explosion to be 1)big, 2)use no more than 4 sprites at any one time 3)clear itself out of the way to not cause clutter. The first goal is in order to have a satisfying impression on the player after defeating an adversary and to make ”more” than was traditionally done for the console. The second and 3rd goals work together to minimize sprites per scanline over time. Since the 4 sprites spiral outward in a diagonal pattern, they clear themselves away from any frontal position the player character might be likely to have, ie. avoiding taxing the scanlines as fast as possible.

In the video, i’m stepping through some of the animation cels to give a better insight into how i move the sprites.

Since quite a hefty percentage of the total tilespace is used to do smooth main movement animations of the main player character, tile recycling is helpful. The explosion is mostly reusing the same tiles with the help of tile mirroring. Note that the NES PPU can’t properly rotate sprites (not even in 90 degrees), but sometimes mirror-flipping is good enough, as shown in the video. I also figured the 4 first cels of the explosion may be good for for energy obtainables or the like.


The one of the right is made out of 4 sprites, but is only using as many tiles as the one to the right (which is one sprite) thanks to the mirroring bits.

I’m using similar tricks for the pie chart-type meter i posted about earlier.

Here’s the explosion with a more didactic timing, a grid and sprite boundaries, to show what is happening. A nice thing is that the twirly movement lets it expand while not taxing any more than 2 sprites per scanline From the moment it expands into four sprites, it takes 12 frames before it starts clearing up scanlines from clutter to an extent that is lesser than the classical 2-sprite-width explosion. Lastly, you see that sprites are removed from the list. That’s another nice thing with variable metasprite sizes and termination bytes – you don’t need to use more sprites than necessary.

Not shown here is that the four first cels take 2 frames each in realtime, and the twirl outward goes at a rate of 1 frame per cel, but eventually slowing down gradually to 4 frames per cel as the last ember flades in a floating state.

Looking at it frame for frame, you can spot plenty of beauty faults. The gap between the 1 initial sprite and the 4 following them is one – but given how fast the explosion goes, you can get away with it and save some tilespace.

One thing that i changed from the first iteration (you’ll notice that the gif is named explosion4) is to stagger the changes from one tile to the next on each sprite. That helped it look a bit more naturally chaotic. The same goes for the sprites being deleted off the metasprite list in the end.

Now, a variable total sprite usage during gameplay might not be that useful in itself, apart from the obvious advantage of having somewhat leaner object representations on any one scanline. You could seemingly get away with more action on-screen in something like a hectic shoot em up this way since you might be more efficient before reaching the 64 sprite hardware cap. But having an action game run smoothly with that much stuff going on would be the bigger challenge. And for the hardware cap, that’s just another occasion where you hypothetically can use priority flickering again if you get to that point of unusual sprite density.

HALCYON december update

Just taking some time cleaning up the main sprite sheet and made a new move for the player character. Now it can crawl though tight spaces. Falling flat on the ground may also be good for avoiding dangers, but you’re less agile while crawling. Another change is that while the player throws bombs in an arc while standing, ze is planned to roll them on the ground while ducking.


While i’m at it. Here’s a look at how sprites are organized when running. NES sprites are 8×8 pixels (unless the PPU – picture processing unit is in 8×16 mode, which is sometimes useful but not always). So mostly, you have to piece several sprites together to make a decently large and detailed character. For example, little mario is 2 by 2 sprites, side by side, and big mario is 2 by 4. But there’s no rule that states that sprites must be side by side. You’re entitled to free placement if your own code permits it.

I’m exploiting this fact to two effects:

  1. make the running animation smoother than most NES era games
  2.  sometimes have the character be fewer sprites in total.

The second point is sort of important because on the NES you have a sprite bandwidth of 8 sprites per scanline (that’s a horizontal line on the screen). If there are more than 8 sprites, the 9th and so on won’t show. Programmers quickly figured out that they could hack their way around the limitation by rotating the priority of sprites. That’s why you see flicker in a lot of NES games – which is still better than sprites being invisible.

Slimming the need for sprites on the same scanline means less flicker – and there will be flicker, because the player controls both a vehicle and a character, and then there’s projectiles, other actors, and so on. A side by side/mario style animation would in this case be a constant 2×3=6 sprites at any one cel, but instead in oscillating between using 5 and 3.

Tilespace-wise, it’s not very effective – the running alone is using 30 tiles if i remember correctly, though some of it can be reused for other actions. You can have 256 sprite tiles loaded in at the same time and that space has to be shared by enemies, items, HUD components and so on. Given that we’re using one quite agile player character and two vehicles ze can ride, that takes up some space. Luckily we can swap strips of it between rooms and areas so we can load in different enemies and items according to need, since the cartridge is using CHR RAM instead of ROM.


Sprite boundaries shown in slomo. Individual movement of tiles lowers the need for unique ones and also sometimes helps keep the sprite count down occasionally. 


The animation is slightly dated. Nathan, the programmer, found that the engine would be more effective if all objects were anchored from the bottom left corner, and this animation has it’s origin at the center-bottom. That’s a quick fix for me, though.