Driving home Sik's question even more: the question "does the NES even have these colours?" is valid, and should be followed by "if so, are the colours you're using actually decent-looking on an actual NES vs. an emulator?" Things do tend to look a bit different on an actual television (NTSC known for being called "never the same colour" for a reason), but more importantly some of those colours might not actually visually "mix" well on an actual screen (i.e. they might look fine in an emulator with a specific palette but might look like an ugly mess on actual hardware).

I don't think the question is really going to break anything, though. As NES art is more or less always simple, tweaking or even completely re-doing a palette doesn't ruin a project or take a huge amount of time compared to any modern platform. The colors I used were completely made up with ones I thought would be reasonable for the NES to produce, knowing they'd have to be later replaced with appropriate ones. In this sort of situation my solution is to make the art as I'd like to see it, then quantize the colors to what the NES palette can produce, and see how the results are. If it's no good, try other palettes.

Here, I edited it to use palette colors pulled from a rendition of the NES palette;

The skin shading tone isn't perfect, but it's not far off enough that I'm upset by it. The loss of definition from its removal would necessitate different art.

EDIT: I think I prefer this version now, actually - the skin tones don't turn from yellow-ish to pink-ish as much.

tepples wrote:

One question every graphic designer for a 2D game should ask herself: What is a meter? I can think of a few things that are close:

A number of pixels that should be consistent at the same depth level of any given scene

I think this question is important in some contexts, but not all. In a game that is attempting to convey a sense of realism in other areas, be it physics, plot, or anything else, the artist will likely wish to continue this theme in the art. So, relative proportions for most of the art is important in keeping the theme believable.

In most (nearly all?) games for the NES, designers opted to abstract things like character designs and the appearance of the worlds they create. It could be to better respect and utilize the limitations of the system, or be just a stylistic choice. As a result, many games have a more "cartoonish" look - charracters have extra large heads to allow a larger canvas for facial expression, doors might be exactly the same height as the player, the vegetables in Mario 2 are huge compared to Mario (despite the Nintendo Power Mario 2 cover depicting them as something that fits easily in his hand). These 'inaccuracies of scale' are perfectly acceptable because they represent an idea that is supposed to be fleshed out in the mind of the player.

Well this is an interesting subject, I hope the project goes well for everyone involved!

@Mike: I think it'd be better for you to say "a good chunk" as opposed to "most" or "nearly all", regarding stylized graphics being used to compensate for the NES' limitations. For example, Konami's NES characters have been jokingly referred to as being "faceless" because they were mostly going for a realistic look with some stylization thrown in. Ironically enough, their faceless characters even went as far as MGS1 for the PS1, where Snake barely even had a face. Then there's the various Japanese mystery games that like to use realistic portraits of people, and Power Blade being a well known example of "Americanizing" a Japanese game, right down to using realistic graphics compared to the original's anime like graphics.

In short, realistic graphical styles were somewhat present on the NES, but the stylized style works much better for most games due to the console's restrictions. Conveniently enough, the more "chibi-ish" designs look more "infantile", and as such used when the technology was also considered to be "infantile". If nothing else, I dare say console hardware becoming sufficient enough for realistic graphics around 6th gen was the reason why most 3D games stopped being stylized collectathons, and expanded into new, uncharted territories.

Well this is an interesting subject, I hope the project goes well for everyone involved!

@Mike: I think it'd be better for you to say "a good chunk" as opposed to "most" or "nearly all", regarding stylized graphics being used to compensate for the NES' limitations. For example, Konami's NES characters have been jokingly referred to as being "faceless" because they were mostly going for a realistic look with some stylization thrown in. Ironically enough, their faceless characters even went as far as MGS1 for the PS1, where Snake barely even had a face. Then there's the various Japanese mystery games that like to use realistic portraits of people, and Power Blade being a well known example of "Americanizing" a Japanese game, right down to using realistic graphics compared to the original's anime like graphics.

I think I may have been unclear in what I was talking about. I am referring to action sprites in common genres like platforming, top-down adventure, arcade-type maze games, etc. Larger portaits in story scenes or RPG panes are totally fair game, and I hadn't thought of those.

Some people are fans of CHR ROM because it allows rapid switching of tiles for smooth animation of the player character. But in Kirby's Adventure, it ends up causing a lot of duplication because all frames of all enemies on screen at once need to fit in the same 2K bank of enemy tiles. So instead, I'm a fan of the Battletoads technique of loading sprite tiles into video memory as they're needed. I've already described how this works on Game Boy Advance, but the NES has far less video memory bandwidth and thus needs a bit more clever technique.

The engine I'm developing for this project has four object slots in video memory: one for the hero and three for enemies. These occupy CHR RAM $1800-$19FF, $1A00-$1BFF, $1C00-$1DFF, and $1E00-$1FFF. Each slot is divided into a pair of 16-tile buffers, plus several variables in main RAM:

Current cel: The cel ID currently being displayed in this slot.

Next cel: The cel ID whose tile data needs to be loaded into the back buffer of this slot.

Current buffer: Whether the slot's first or second buffer is its front buffer.

Information about what data has been loaded into each buffer of each slot.

In addition, a set of request flags controls which sprites should be switched to the next cel as soon as they are completely loaded.

On each frame that doesn't have any updates to tiles or map caused by scrolling, the sprite cel loader finds pieces of a cel to load. It prioritizes slots whose request bit is set, switching buffers and clearing the request bit if the cel is ready and loading a piece into the VRAM transfer buffer if not. Up to 8 tiles can be copied in each frame (NTSC without extended blanking). If a particular frame uses all 16 tiles, its update is split across two frames.

If there is still no scheduled VRAM transfer after the loader has processed all request bits, it loads pieces of the next cel speculatively. Speculative loading sets the next cel to the frame most likely to follow a slot's current cel, such as the next cel of a walk cycle. I count about five mispredicts per second on average, usually when an enemy spawns or when the player takes an unpredicted action, such as jumping, stopping a walk, beginning a punch combo, allowing a punch combo to expire, or taking a hit. A mispredict may delay loading a cel for a frame or two But otherwise, speculative loading puts a cel into VRAM just when it is needed, allowing the player and enemies to be animated at an acceptable frame rate.

The metasprite drawing code uses values $00-$7F normally for constant tiles. It uses $80-$8F for these switchable slots, ORing in the start tile of current buffer of the slot being drawn.

Any idea how long this project may take? Is there a timeline? I'm curious what the process is for plotting out such a project. I'm assuming you already had experience from previous side-scrolling engines, so you weren't starting from scratch.

This was my first side-scrolling platformer engine. The game was finished on Sunday, leaving cut scenes (me) and music engine replacement (someone else). I have about one night left of cut scene work. Finally there is light at the end of this tunnel.

Looks interesting. Maybe this will be the alternative to "Ghoul School" that doesn't suck.(I like the setup of "Ghoul School" with monsters and demons in a modern-day setting, but the gameplay sucks ass.)

Who is online

Users browsing this forum: No registered users and 7 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum