NESST 2.5 is out

Shiru has pushed another version of the perhaps most essential tool for making nes graphics, NESST. You can get it here. As a side note, the nifty tool NES space checker has been updated too.

So what are the differences? There are actually a lot of features added; too many to go over here. Some very useful, some occasionally useful and one that is perplexing to me.

Perhaps of most importance, there are several new import options, especially for converting PC bitmaps (bmp:s) to nametables and character tables. For instance, you now have the option to offset the imput 0-8 pixels, which can save you a lot of time searching for the leanest tile count.. this bodes well for drawing freehand, rather than tile-for-tile, in a tool more suitable for that sort of work (think cutscenes and such).

Another new feature i’m foreseeing i’ll be using quite a bit is palette copy/paste. It basically allows you to move-copy all 4 palettes between slots A, B, C and D. Practically, this means that you can quickly make a temporary backup of your preferred palettes, edit one of the copies, and A/B test them quickly against your background or metasprite.

This is something i’d normally do from time to time, but now it’s even more convenient. Thanks, shiru!

There is also a ”reset” option which restores all palettes to some preset slot. I’m imagining these are user configurable, but the readme won’t say how. The ”factory” presets aren’t too useful; being monochromatic within each subpalette.

Better documentation

The readme file has gotten some extra attention too. For example, a feature that was always there was the right-click drag and drop-sorting of tiles, but now it is properly documented! To check the two readme versions side to side, go here:

The new readme is to the right.

The meta sprite editor has become more user friendly, and versatile. It provides you a basic instruction for selecting and moving individual sprite tiles, which i suppose is one of the thresholds for starting to use this side of the tool. There’s also a snap to grid option now, which could be useful for games that imply sprite positions on an x8 basis, such as SMB and many others did. There’s also a new offset tool that lets you move around the metasprite as a whole entity relative to its anchorpoint. You could achieve the same end result before, but it has been made more convenient in this version!

Among the the many feature updates, one stands out as pretty odd: ”generate 4×4 chunks”. The readme describes it as follows:

”Generates a set of 4×4 chunks that contain all possible color combinations.
A very specific function that may come handy for some effects or blocky

In practice, it just replaces your CHR file with a set pattern that would be best provided as a .chr file separate to the program. I know it said specific, but this feels way too specific! The patterns themselves actually seem to be based on 2×4 chunks (a bug, maybe?). I can’t think of any use for it, and it adds to the drop down menu clutter, which has started to get a little encumbering in total.


not quite sure how this new pattern generation could be useful

Nitpicks aside, there are several more minor additions to NESST, so be sure to go over the readme to find something that you think could be useful to your process!

Let’s end with a few quick NESST tricks. These aren’t new, but maybe not widely known either.

Nametable quick swaps
This isn’t new, but probably not widely known either.
Say you have several nametables using the same tiles and want to switch quickly between them. Maybe they’re cutscene keyframes or static levels or something.

In windows explorer, name them like so: myNametable_NNN.nam, where NNN is a three-digit ID.

In NESST, press ctrl + three digits on your numpad to call the nametable up directly.

Merge CHR tables
If you load a CHR file smaller than 4kB, it will start loading in from the position of your currently selected CHR tile. AFAIK, the size can’t be arbitrary – it must be at 1kB (quarter of a CHR table) or 2kB (half a CHR table). If you need finer control over cutting and merging binaries, i recommend looking at my ca65 example in this post.

Paint more fluidly.
Painting one tile at the time can be very resource efficient; which is something you need to be most of the time when drawing for the NES in the context of making an actual game. But sometimes you want to draw a bit more freeform-like.

To do that, click-drag on the tileset a square, empty portion of it. Ctrl+C. Then shift-click on the nametable, so one square is marked. Ctrl-V. Now an area corresponds to the marked tiles in your CHR table.

In the CHR editor, draw as usual and click on the sides of the upscaled tile to move to the next neighboring tile. You’ll see your result on the nametable directly, almost as if drawing free-hand.

That’s about all for now. If you’d like to support Shiru’s contributions to the nesdev scene, there’s a patreon where you can get news and details more frequently.

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.