NES Styled Pixel Art

[ShaneLite]

A friend and I are working on NES style content in our spare time (though we don't have the talent to make it an actual NES rom) in the vein of Shovel Knight, but more faithful to the hardware. I figured the least best we could do is try to get feedback on the artwork and sprites we have made;




These are some of the level tiles we have been working on so far. I figured NESdev would be the best place to go for critique to NES accuracy. Using a good looking color palette has also been an issue, but currently we use a palette someone posted here:



This was a quick comparison I did of the palette my friend was using:


We're both still reading and trying to understand how NES hardware works, so any tips and suggestions would be useful.

[ccovell]

Your artwork looks really nice, and it seems to fit into an average NROM / UNROM limitation.

[OneCrudeDude]

This looks pretty accurate, though I'd say that the caterpillar might pose an issue. It looks like it has four segmets, each of which being a 16*16 block. The Player character is also 16 pixels wide. The NES can display up to 8 sprites in a row without flicker, and sprite in this case means a graphical object that's either 8*8 or 8*16 in size. What you might think of as a sprite, in this case the entire character, is referred to as a meta sprite, which is a group of sprites. If the player and the caterpillar were on the same level, there would be flicker, but seeing that they're on different levels, there's little chance for flicker to be truly noticeable.

Also, it's been widely regarded as a good idea to design and flesh out your game in a higher level language while adhering to the NES limitations, and then converting your completed game for use on the NES. Whether you will port it or someone else is entirely on the wall.

[rainwarrior]

Hmm, I see 5 colours in your status bar: Black, white, red, blue, grey.

Would you be doing one of these with sprites?

As a tip, I'm not sure if you're doing this, but it may be a good idea to avoid the D column greys, as there's a few problems that come up when using them. 0D generates a too-black colour that is out of spec and will cause some televisions to lose the picture. Using column D colours requires special treatment during fadeout to avoid 0D. On some emulators 3D/2D might have the same colour as 10/00, and 1D might be black, so you may want to avoid using column 0 and column D colours side by side, if you're not avoiding them altogether.

[Alp]

Woah! This tile-work is gorgeous, guy!

Very reminiscent of Castlevania! Though, the level layouts, and presence of multiple characters, seem to suggest a Mario 2 style progression?

Aside from the mentioned hud colour issues, the only problem I could potentially see with this, is that the rope tiles seem to use the same colours as the wall high-lights, with an extra grey colour. Causing an entire palette to be used for practically the same colours.

Perhaps you could find a way to merge the rope index, and the wall index and save those colours for something else? (Assuming you would want to stick to the 4-BG palette per area limit.)

Nit-picks aside, great work so far!

[tokumaru]

Hmm, I see 5 colours in your status bar: Black, white, red, blue, grey.

Would you be doing one of these with sprites?

It's probably not a coincidence that there are 4 hearts and 4 spheres... although only one of those groups has to be made out of sprites, so he could even have more hearts if he wanted to.

Using column D colours requires special treatment during fadeout to avoid 0D.

I can't speak for everyone, but my fade routines are always table-driven, in one way or another, because the straightforward "increment or decrement the high nibble" technique looks extremely choppy. It can look good if your fade animations are really quick, but if for some reason you need them to take a little longer, you should look into less obvious techniques.

the only problem I could potentially see with this, is that the rope tiles seem to use the same colours as the wall high-lights, with an extra grey colour. Causing an entire palette to be used for practically the same colours.

Perhaps you could find a way to merge the rope index, and the wall index and save those colours for something else?

You know, I always dislike when people make this suggestion after someone posts good looking art. I agree that repeating 3/4 of a palette is a huge waste of colors, but the solution you propose would make the game look flatter, and not as great as originally drawn. I propose the exact opposite: keep using separate palettes for the different objects, but have them differ by more than 1 color (even if they're just slightly different and not completely different hues), so that you have MORE colors on screen. If both palettes can be reused for other objects, even better!

[rainwarrior]

Ah, I forgot to say that it looks pretty good!

Another tip: test things with an NTSC filter. Some patterns, especially when dithering, will manifest poorly on the NES' NTSC signal. A pixel isn't really a pixel anymore when you're dealing with the real output of the NES.

There is a program to try this available here: http://forums.nesdev.com/viewtopic.php?f=21&t=11947

[ShaneLite]

Thanks for the feedback so far everyone!

This looks pretty accurate, though I'd say that the caterpillar might pose an issue. It looks like it has four segmets, each of which being a 16*16 block. The Player character is also 16 pixels wide. The NES can display up to 8 sprites in a row without flicker, and sprite in this case means a graphical object that's either 8*8 or 8*16 in size. What you might think of as a sprite, in this case the entire character, is referred to as a meta sprite, which is a group of sprites. If the player and the caterpillar were on the same level, there would be flicker, but seeing that they're on different levels, there's little chance for flicker to be truly noticeable.

Also, it's been widely regarded as a good idea to design and flesh out your game in a higher level language while adhering to the NES limitations, and then converting your completed game for use on the NES. Whether you will port it or someone else is entirely on the wall.

Good to know about the way sprites work; do NES games use one or both? The caterpillar was meant to walk in segments, but that could be too complex.

This alone would have 16 8x8s or 8 8x16s, which would go up more to give the lower half of the sprites their second walking frame. Some fat would seriously have to be trimmed it seems.

Some of the engine has already been made, but it's in alpha stages.

We recently got feedback on it so far, and the general conclusion is that the controls are too loose, even looser than Super Mario World, so the controls are being tightened. I don't know if the gif shows it enough, but sprites coming on screen also have a deliberate delay before appearing. The gif also shows a more recent HUD, which dials back on the colors used.

Woah! This tile-work is gorgeous, guy!

Very reminiscent of Castlevania! Though, the level layouts, and presence of multiple characters, seem to suggest a Mario 2 style progression?

Aside from the mentioned hud colour issues, the only problem I could potentially see with this, is that the rope tiles seem to use the same colours as the wall high-lights, with an extra grey colour. Causing an entire palette to be used for practically the same colours.

Perhaps you could find a way to merge the rope index, and the wall index and save those colours for something else? (Assuming you would want to stick to the 4-BG palette per area limit.)

Nit-picks aside, great work so far!

Right now, the game is set to have most sprites at a greyscale, and then converts the greyscale to a set palette. Here's what the rope would look like with the player palette (but then the rope changes color when playing as a different character).

Ah, I forgot to say that it looks pretty good!

Another tip: test things with an NTSC filter. Some patterns, especially when dithering, will manifest poorly on the NES' NTSC signal. A pixel isn't really a pixel anymore when you're dealing with the real output of the NES.

There is a program to try this available here: http://forums.nesdev.com/viewtopic.php?f=21&t=11947

Now this is a tool that will come in handy! Thanks for the recommendation. Here's some quick tests using the screens posted before:

[OneCrudeDude]

Regarding 8*8 or 8*16 sprites, it's only one or the other. Whether this is global or can change per screen is something I don't know yet. I do know that there's advantages and disadvantages to each method, but seeing how your graphics look, I'd say that 8*16 would work better. In short, the advantage of 8*16 is that you can display more with the same limitations, the disadvantage is that it's rather clumsy, especially if you wish to have Megaman/Mr. Gimmick like sprite overlaying for more colors. With 8*8, a single tile over Megaman's face would have a smaller chance of causing flicker than if it was 8*16, since the sprite is now taller, and the sprites can overlap.

Think of it this way. If you had 9 8*16 sprites lined up so that they rose one pixel each but they have one line in common, they would all flicker. Think of how Hogan's Alley or Challenger writes Congratulations on screen.



The letters don't flicker because they're 8*8, and each letter is moved up one pixel each. You can have eight letters in a row without flicker, and the next letters would be unaffected by this. But if those were 8*16 sprites, you couldn't do it this way, the sprites would have to be spaced two pixels taller.

[lidnariq]

Regarding 8*8 or 8*16 sprites, it's only one or the other. Whether this is global or can change per screen is something I don't know yet.

It can even be switched after any given scanline, but that's a mess to keep straight. (Which numbers refer to which sprite graphics vary depending on whether you're using 8×16 or 8×8 sprites)

[Sik]

Also, it's been widely regarded as a good idea to design and flesh out your game in a higher level language while adhering to the NES limitations, and then converting your completed game for use on the NES. Whether you will port it or someone else is entirely on the wall.

I think the comment was to understand the hardware to adhere to its limitations, not to make the game for it.

Aside from the mentioned hud colour issues, the only problem I could potentially see with this, is that the rope tiles seem to use the same colours as the wall high-lights, with an extra grey colour. Causing an entire palette to be used for practically the same colours.

But there's like only three palettes in use despite that...

[tepples]

Good job on the artwork in the playfield. As for the status bar, some glyphs in the font are difficult to tell apart at a distance: O vs. D, R vs. B vs. A vs. 8. If you could post all the letter and number tiles as an attached image, I'm willing to suggest some fixes.

Different TVs at different settings (and with different proprietary skin tone enhancement algorithms) will produce different palettes, so don't worry about that. If you have a PowerPak, I have a tool to let you view your backgrounds on your NES and TV.

it may be a good idea to avoid the D column greys

In addition, on an NES-compatible system with an RGB PPU (PlayChoice, Famicom Titler, Sharp C1, 2C03/2C05-modded NES), all D column colors are exactly black. The safest grays are these:

• 0F: black
• 00: lightness close to 11-1C
• 10: lightness close to 20-2C
• 20: white

Good to know about the way sprites work; do NES games use one or both? The caterpillar was meant to walk in segments, but that could be too complex.

A scene can contain 8x8 or 8x16 sprites. A larger sprite is made out of multiple sprites: Super Mario is eight 8x8s in Super Mario Bros. or four 8x16s in Super Mario Bros. 3. Most of the time, an entire picture uses one size of sprite, but you should be able to use 8x8 for the status bar and 8x16 for the playfield without problems, as the write to $2000 to set the high bit of the X scroll position also changes the sprite size. Use 8x8 rules above the split and 8x16 rules below and there shouldn't be problems.

In any case, your Wiggler expies can probably get away with a 16x16 head and four 8x16 segments, for a total of 6 out of 8 sprite slivers (a sliver is 8x1 pixels), leaving 2 for the player character. Flicker when using your weapon can be expected.

[Sik]

Looking at the catterpillar again, another alternative would be to make it out of three pieces instead of four (automatically reducing the sprite count to six), then spacing apart the pieces more than in the pic (so it remains at the same length overall). The catterpillar in that mock-up already has lots of overlap between its pieces, so it's not like it's gonna leave some important gaps.

[DragonDePlatino]

It's commendable that you're going after NES restrictions, but since this isn't intended to run on NES hardware I think all of this streamlining is pointless. Most people don't like the sprite flickering and if you're going to be designing your characters around sprite flickering, you'll be watering them down. If I were playing this game and knew nothing about NES restrictions (about 90% of the people who play these games) I really could care less. As long as the game is fun and the atmosphere is nice, that's all that matters.

And since you're going to be modelling your game after Shovel Knight, this might be worth a read.

But regardless, I think these are some great mockups. Your foreground and background have great contrast and it's really cool how you separated your foreground/background using warm/cool colors. Your character designs are pretty crisp and I'm a big fan of how you dithered your waterfalls to lower their contrast. I'll have to give that a shot later...

[Sik]

Dunno, whenever I see somebody claim to be using art recreating old systems and then they break limitations like nothing mattered it irks me like hell. May as well just go with no limitations in the first place.