Hi I'm new here. Came looking about for discussion with folks accustomed to NES game development for a few questions I have regarding a little game project of mine that while not actually for NES (I wouldn't know where to begin making a real NES game and I haven't the time to learn) I'd like it to be fairly authentic to the NES style and limitations.
Anyways this be something that's bugged me for a while now. There seem to be so many different palettes out there claiming to be what the NES uses. I know it's supposedly impossible to say what the 'true' colors are but I was wondering what most people here tend to use and the reasons for doing so.
I've got a screenshot of my game in progress using the NES palette I originally found but I've also recolored the image using other NES palettes I've found and while some colors work better, others do not. I'll post my test shots in a bit but I'd just like to know what people here use.
Thanks
You get up to 25 colors at once out of 52. This comprises one background color for the whole image, four sets of three colors that (along with the background color) can be applied to 16x16 pixel grid spaces in the background (size of a ? block in SMB1 or SMB3), and four sets of three colors that can be applied to 8x8 or 8x16 pixel moving objects ("sprites").
The NES generates a video signal directly in the composite domain. It is up to the TV to decode this into an RGB signal. The actual color values depend on how the knobs on the TV are set: brightness (signal add), contrast (signal multiply), color (saturation), and tint (hue offset). Modern emulators (such as FCEUX, Nestopia, and Nintendulator) attempt to emulate this video decoder, and they include sliders that replicate these knobs.
This NES ROM displays all possible colors at once. Tf you have a PowerPak, you can use this ROM to adjust your emulator's sliders to match what you see on the TV. Then take a screenshot of the ROM and use that as your palette.
You won't find a definitive NES palette, because every TV displays them a bit differently. Most consoles have RGB palettes, so it's easy to just use the RGB values and ignore the difference across different TVs, but not the NES.
Your best bet is to generate the palette dynamically, like some emulators do (Nestopia and Nintendulator, for example), allowing the user to adjust it according to their preference.
If you want an authentic NES feel, be sure to respect the other limitations of the NES video system, like the ones tepples mentioned.
Ok I should have phrased my first post differently. The palettes I have found around the net are laid out like this.
and
And several others I've noticed with slightly different RGB values for each color. I was just curious as to what people here may use and which is thought of as being the best or most commonly used.
Carnivac wrote:
Ok I should have phrased my first post differently.
My answer remains the same: There is no correct palette. If you're gonna go with a static one (instead of allowing the user to adjust it, like some emulators do), you'll just have to pick the one that pleases you the most.
A quick feedback on the images you posted though: both have the last 2 columns completely wrong, because those colors are all black.
tokumaru wrote:
Carnivac wrote:
Ok I should have phrased my first post differently.
My answer remains the same: There is no correct palette. If you're gonna go with a static one (instead of allowing the user to adjust it, like some emulators do), you'll just have to pick the one that pleases you the most.
Yeah I mentioned in my first post I know there's no 'true' palette but I'm simply interested in what people generally use before I put too much work into this project. Due to the fact indexed colors aren't quite so easy to do I have to use a preset palette (though the main dragon sprite can change colors as he's seperated into layers so I can control each of his 3 colors independently, not something really feasible with every other graphic in the game especially the tiles). I'd rather not spend loads of time creating and importing my graphics only to have someone say the palette is not very authentic looking and have to recolor every graphic.
Quote:
A quick feedback on the images you posted though: both have the last 2 columns completely wrong, because those colors are all black.
What do you mean by that? That's the same thing I've seen on every NES palette image I've ever found online. They always have the last 2 columns black.
I think Tokumaru means real, authentic black! Like #FFFFFF if you want.
In these two pictures you showed us in your earlier post, there were different shades of black, not one.
Carnivac wrote:
Due to the fact indexed colors aren't quite so easy to do I have to use a preset palette
I see... I thought you had the option of using indexed colors. Well, this is a tough call then. Personally I use the palette generated by Nestopia by default when drawing my graphics, but that doesn't matter much because they are converted back to NES graphics... For NES programmers the palette is just a helpful reference, it's not the final product.
Carnivac wrote:
What do you mean by that? That's the same thing I've seen on every NES palette image I've ever found online. They always have the last 2 columns black.
I meant that in reality they are black, but both your images have different shades of dark grey.
Nintendulator used to have a broken palette, but now it looks much better than before.
I still like the YY-CHR NES palette, nice and saturated.
Carnivac wrote:
And several others I've noticed with slightly different RGB values for each color. I was just curious as to what people here may use and which is thought of as being the best or most commonly used.
In my experience, Nestopia's palette is the best. It is the closest match to what I get from my NTSC *and* PAL NES on my TV. You can download it here:
http://thefox.aspekt.fi/nestopia-yuv-palette.act (it's a Photoshop palette file, but you can easily take the first 192 bytes with a hex editor to get 64 RGB values).
Nintendulator's NTSC palette is also OK, but the PAL one is way off (in my experience).
Also keep in the back of your mind that some people may choose to utilize the RGB palette (I go back and forth between this and YUV+composite in Nestopia sometimes myself). Colors tend to be more saturated from RGB PPUs, emulated or hardware. Gimme a sec and I'll get comparison screenshots using the ROM that tepples linked to.
Edit: Here we go. First, the standard YUV palette (with composite emulation enabled as well, as you may be able to tell on the horizontal color boundaries):
And here's what it looks like with the RGB palette (looks slightly different in places to the colors seen in the Nintendo Power RGB screens, but they photographed many of those shots off the front of a CRT monitor instead of using video capture):
Also, I made an animated GIF (without using NTSC emulation, so that I could get crisp 256x240 images and not overflow the 256-color index of GIF files) comparing the two palettes:
thefox wrote:
Carnivac wrote:
And several others I've noticed with slightly different RGB values for each color. I was just curious as to what people here may use and which is thought of as being the best or most commonly used.
In my experience, Nestopia's palette is the best. It is the closest match to what I get from my NTSC *and* PAL NES on my TV. You can download it here:
http://thefox.aspekt.fi/nestopia-yuv-palette.act (it's a Photoshop palette file, but you can easily take the first 192 bytes with a hex editor to get 64 RGB values).
Nintendulator's NTSC palette is also OK, but the PAL one is way off (in my experience).
I second this. TVs vary a lot, so I've gotta adjust the chroma knob on mine a bit until I like the colors. When the subjective sweet spot is reached, though, it looks pretty much like the Nestopia palette in terms of hues and hue/brightness differences between colors seem to match.
I use the Nestopia palette in my map editor and for all graphics editing.
Tint settings in practice tend to vary a lot among NTSC TVs. Some people have their tint set such that $28 looks greenish yellow; others have it set such that $28 looks orangeish yellow.
Grumskiz wrote:
I think Tokumaru means real, authentic black! Like #FFFFFF if you want.
In these two pictures you showed us in your earlier post, there were different shades of black, not one.
Ah fair enough. I hadn't noticed those but I wasn't using those columns anyways as I'd already got used to them being somewhat redundant.
Anyways here's a test shot recolored in the various palettes I've been looking at. Most of the color indexes were straightly recolored to the same one's location in the other palette apart from a couple where the color swapped was so different I switched it to a closer match within the palette.
1. This is the original one I did using the palette from
http://www.thealmightyguru.com/Games/Hacking/Wiki/index.php?title=NES_Palette
2. Recolored using what is said to be the 'default' NTSC palette from
http://www.wayofthepixel.net/pixelation/index.php?PHPSESSID=c1i4rimra1oappfe27ao9ko8v5&topic=10784.msg115062#msg115062. Too dingey and mucky looking.
3. Recolored using a palette I found said to be Nintendulator's PAL palette also from
http://www.wayofthepixel.net/pixelation/index.php?PHPSESSID=c1i4rimra1oappfe27ao9ko8v5&topic=10784.msg115062#msg115062. Quite nice and vivd and I like the richer browns in the rock tiles. The greens though might be a bit too bright.
4. Recolored using the YUV palette in Nestopia (I opened up the palette bit in the Video settings and copied the colors over). A bit dark but not too bad. The main problem I have with this one is the two dark browns in the rock tiles are so similar it's hard to tell them apart. Also not keen on the way the nice magenta I had a specific use for is now more purple. The dark purple also blends a bit too much with one of the dark browns.
Let me be the first one to say that these graphics look amazing! You seem to be breaking some coloring rules though.
tokumaru wrote:
Let me be the first one to say that these graphics look amazing! You seem to be breaking some coloring rules though.
Thanks!
That's something else I was going to ask about. What rules am I breaking in that image so I can fix them in the game? Some bits like the enemies here I had in mind two layers of sprites to get an extra couple colors if it was a real NES game.
There are a lot of background areas that do not respect the attribute boundaries, such as the shaded trees, the grass in front of the trees and the bridge. Each 16x16-pixel area can only use 1 palette, but you are mixing palettes inside these areas. The bridge could actually be made using a special mode of the MMC5 mapper, but not the rest.
The sprites have way too many colors, but like you said, they can be layered for extra colors, but even if that's the case I'm seeing more than 4 unique 3-color palettes. Also, the NES can only show 8 sprites in a row, and with all the sprites and layering you have that limit would be reached fairly quickly.
tokumaru wrote:
There are a lot of background areas that do not respect the attribute boundaries, such as the shaded trees, the grass in front of the trees and the bridge. Each 16x16-pixel area can only use 1 palette, but you are mixing palettes inside these areas. The bridge could actually be made using a special mode of the MMC5 mapper, but not the rest.
Yeah that's the sort of thing I wasn't sure about. I don't mind taking the sky out if that helps (or at least removing the clouds so that the sky is more block colored and working more in 16x16). Then if I remove the dark blue secondary light on the right side of the brown trees changing it to dark brown that'll eliminate that color which I can perhaps switch that color index to the sky color so that the 'gothrough branch platforms of the the tree can use the sky color as part of their 16x16 palette? Am I on the right lines here?
The grass in front of the darker tree tiles can stay though can't it as it uses the same dark blue/green and black the trees do.
Quote:
The sprites have way too many colors, but like you said, they can be layered for extra colors, but even if that's the case I'm seeing more than 4 unique 3-color palettes. Also, the NES can only show 8 sprites in a row, and with all the sprites and layering you have that limit would be reached fairly quickly.
Oh that's ok. I don't mean to have too many sprites in a row. They're just like that here for show. They'll be more scattered in-game and I'm just pixelling a couple more smaller enemies right now that use only one layer and can be used a bit more often. The leaves on the branches would be sprites that fall when walked over (though I might just take them out completely), the flowers overlaid on the grass would be sprites that could be destroyed as the dragon's fireball or flame (think Dhalsim from Street Fighter, hehe) passes through them but again I won't have many per row especially in areas where enemies would walk along there.
The smaller palettes thing is something I'm not quite sure about. How's that work?
Anyways this be the kind of advice I've been looking for, thanks
These sorts of graphics would be at home on a PC Engine, called TurboGrafx-16 in many markets outside Japan. It's too bad the TG16 never took off in the United States to the point where used ones are affordable.
I assume the little dragons are your player characters. If you have two palettes for player characters, you're going to have to make a lot of other stuff on the screen use the same palette as the player characters, such as using the red dragon's palette for the flames. If you freeze-frame Contra, for example, take a look at how many moving objects share the same palette as player 1 or player 2.
You may have to dynamically allocate the third and fourth palettes, much as the first Super Mario Bros. does, and restrict enemies with incompatible palettes from entering the same area. Notice, for example, the lack of Red Koopas and Green Koopas anywhere near each other, and the fact that Lakitu and Spiny usually get a level (e.g. 4-1) or big part of a level (e.g. first few screens of 8-2) to themselves.
Try mocking up an actual screenshot with only those things that'll be in a single area at once, and I'll point out where your coloring errors are.
Carnivac wrote:
I don't mind taking the sky out if that help
I don't see anything wrong with the sky.
Quote:
Then if I remove the dark blue secondary light on the right side of the brown trees changing it to dark brown
You don't have to remove it, you can just make the brown part 16 pixels wide, and then put the dark blue part, which can share the attribute block with the sky since it's the same palette.
Quote:
The grass in front of the darker tree tiles can stay though can't it as it uses the same dark blue/green and black the trees do.
Yes, as long as it's the same palette.
Quote:
The smaller palettes thing is something I'm not quite sure about. How's that work?
NES tiles have 4 colors, and since sprites need transparency one of the colors is always transparent, which leaves you with only 3 colors per sprite palette. Your mockup appears to be using more than 4 palettes. Each dragon uses 1 palette, the coins need another one, what you have left is simply not enough to represent the ghosts, diamonds, chests, barrels, candles and flames.
Ok I'm halfway through reworking the test shot.
What is the maximum amount of 4 color palettes I can have at any one time? And if a sprite uses the same palette as a background tile, can the sprite choose which of the 4 colors is transparent or does that become transparent for anything using the same 4 color palette?
On the previous page, tepples wrote:
You get up to 25 colors at once out of 52. This comprises one background color for the whole image, four sets of three colors that (along with the background color) can be applied to 16x16 pixel grid spaces in the background (size of a ? block in SMB1 or SMB3), and four sets of three colors that can be applied to 8x8 or 8x16 pixel moving objects ("sprites").
You get black and eight sets of three colors.
Each 16x16 pixel area of the background can use four colors: black and either set 0, set 1, set 2, or set 3. They cannot use sets 4 through 7.
Sprites can use set 4, set 5, set 6, or set 7. They cannot use sets 0 through 3, and they can't use black unless it's one of the colors in the set.
tepples wrote:
These sorts of graphics would be at home on a PC Engine, called TurboGrafx-16 in many markets outside Japan. It's too bad the TG16 never took off in the United States to the point where used ones are affordable.
I assume the little dragons are your player characters. If you have two palettes for player characters, you're going to have to make a lot of other stuff on the screen use the same palette as the player characters, such as using the red dragon's palette for the flames. If you freeze-frame Contra, for example, take a look at how many moving objects share the same palette as player 1 or player 2.
You may have to dynamically allocate the third and fourth palettes, much as the first Super Mario Bros. does, and restrict enemies with incompatible palettes from entering the same area. Notice, for example, the lack of Red Koopas and Green Koopas anywhere near each other, and the fact that Lakitu and Spiny usually get a level (e.g. 4-1) or big part of a level (e.g. first few screens of 8-2) to themselves.
Try mocking up an actual screenshot with only those things that'll be in a single area at once, and I'll point out where your coloring errors are.
I thought SMB uses these palettes:
sprites
palette 1: Mario or Luigi
palette 2: goomba, bullet bill, buzzy beatle, hammers
palette 3: red koopa, powerup mushroom, spiney, fireballs
palette 4: green koopa, 1up mushroom, pirhana plant, lakitu, bowser, hammer bros
background
palette 1: ground, brick blocks
palette 2: ? blocks, coins (animated palette)
palette 3: grass, trees, mountains
palette 4: clouds
psycopathicteen wrote:
I thought SMB uses these palettes:
sprites
palette 1: Mario or Luigi
palette 2: goomba, bullet bill, buzzy beatle, hammers
palette 3: red koopa, powerup mushroom, spiney, fireballs
palette 4: green koopa, 1up mushroom, pirhana plant, lakitu, bowser, hammer bros
So where's the Starman and the Fire Flower?
Carnivac wrote:
What is the maximum amount of 4 color palettes I can have at any one time?
The NES has 4 background palettes and 4 sprite palettes. Sprites can't use background palettes and backgrounds can't use sprite palettes.
You seem to have defined black as the background color, so all 4 background palettes will have black as their first color. The remaining 3 colors of each palette can be anything you want.
The first color of every sprite is always transparent, the remaining 3 can be anything you want. If you want to use black on the sprites, one of the 3 colors of the palette must be set to black.
Except for the attribute clashes, your use of the background palettes looks OK, it's the sprites I'm worried about. Each dragon needs one palette, and the coins also need one. That only leaves you with 1 palette to work with for everything else.
If I were you I would redraw the red dragon and all the fire to use the same palette. Coins and barrels could probably share a palette too. The last palette could be cyan-ish and used for the ghosts and chests. The clothes of the floating enemies could use the palettes of the dragons or the coins (although they have no black). Flowers and diamonds will have to use the existing palettes, which should have enough variety of colors. The falling leaves could use the green dragon's palette. I'd do something like this:
palette 0: green dragon, green egg, leaves;
palette 1: red dragon, flames, red diamonds, flowers;
palette 2: coins, barrels, candles, flowers;
palette 3: ghosts/enemies, gray diamonds, chests, spikes;
Although the spikes would probably work better as background, unless they are supposed to move.
tokumaru wrote:
Let me be the first one to say that these graphics look amazing! You seem to be breaking some coloring rules though.
I agree, looks great! If you ever feel like doing graphics for an actual NES game, contact me.
I have a NES game engine in good shape, but finding somebody to do the graphics is proving tough. Unfortunately I also don't have any kind of design documents done at this point.
EDIT: 1 year later it's time to fix a typo.
thefox wrote:
tokumaru wrote:
Let me be the first one to say that these graphics look amazing! You seem to be breaking some coloring rules though.
I agree, looks great! If you ever feel like doing graphics for an actual NES game, contact me.
I have a NES game engine in good shape, but finding somebody to do the graphics is proving though. Unfortunately I also don't have any kind of design documents done at this point.
I also agree.Too bad these graphics are impossible to run on real nes(like Tokumaru said earlier).Besides that, it's excellent work
tepples wrote:
psycopathicteen wrote:
I thought SMB uses these palettes:
sprites
palette 1: Mario or Luigi
palette 2: goomba, bullet bill, buzzy beatle, hammers
palette 3: red koopa, powerup mushroom, spiney, fireballs
palette 4: green koopa, 1up mushroom, pirhana plant, lakitu, bowser, hammer bros
So where's the Starman and the Fire Flower?
Doesn't the Starman and the Fire Flower just rotate through all 4 palettes?
Denine wrote:
Too bad these graphics are impossible to run on real nes(like Tokumaru said earlier).
This is not such a big deal... The background is almost correct, and the sprites are probably easy to change (even if they'll look slightly less colorful). Personally I'd love to see something like this running on a real NES.
Ok does this work (uses the global palette of my first screenshot)?
Have I got this whole palette thing right or did I misunderstand it?
(I took out the clouds but I can add them back in later using palette 3)
Carnivac wrote:
Ok does this work (uses the global palette of my first screenshot)?
Have I got this whole palette thing right or did I misunderstand it?
(I took out the clouds but I can add them back in later using palette 3)
Wow, this is some terrific stuff! Thought I was looking at a 16-bit game for a few seconds there.
Except you seem to be disregarding the 8-sprite limit (only eight 8-pixel wide sprites can be on the same scanline at a time, the rest are discarded). Games shuffle the order of sprites every frame so they flicker instead of disappear.
Might want to see what these graphics look like after running them through an NTSC filter, because stuff can look completely different.
So each sprite is actually made up of 8x8 pixel tiles? Oh ok. Well this is just a test shot anyways. I'll take that into consideration when doing the levels.
By the way are animated tiles allowed? Say if I wanted to have a hidden room with a solid color background could I then have a tile version of the coin in that room repeated a lot for crazy money collecting or would that have to be static (as in the coin doesn't spin)?
Sprites are either 8x8 or 8x16. You use 8x8 if you need to make different pieces of a big sprite different colors more easily, and you use 8x16 if you are hitting the 64 total sprite limit and want to draw more. (8x16 sprites also require slightly less processing time because there are half as many on a screen) But you can only use one type of sprite for the entire screen, you can't mix the two. Your screen is either dedicated to 8x8 or 8x16 sprites.
You can animate tiles either by changing graphics for the tiles in video memory, or by writing new tiles to the name table. Or you can temporarily "promote" a background tile to a sprite, you erase it from the background, animate it for a short time, then turn it back into a background tile, Mario 1 did this for the question blocks when you hit them.
Tiny Toon Adventures, Super Mario Bros 2, and Super Mario Bros 3 are good examples of animated tiles done by switching CHR-ROM pages. Some games animate tiles by changing contents of CHR-RAM, but that is more limited.
Wow, this look incredible. It really does take a while to realize it's an 8-bit game.
Carnivac wrote:
So each sprite is actually made up of 8x8 pixel tiles?
Sprites can be either 8x8 or 8x16 pixels, and you can display up to 64 of them at any given time. What Dwedit meant is that the NES can only show 8 sprites in a row/scanline, if you try to put more than that the ones with lower priority won't appear. Commercial NES games handled this by cycling the priority of the sprites every frame, causing different sprites to disappear each frame, creating the effect popularly known as "flickering".
Quote:
Well this is just a test shot anyways. I'll take that into consideration when doing the levels.
Just avoid having too many sprites horizontally aligned. For example, in one row you have two diamonds, an enemy, two coins, a barrel and a chest, which would need a total of 14 sprites horizontally. That's almost twice the limit, so you should avoid situations like these.
Quote:
By the way are animated tiles allowed?
You mean background tiles? Yes, they are allowed. In real NES games, the hardware inside the cart has an influence on how animated backgrounds work, but you don't have to care about this.
Quote:
Say if I wanted to have a hidden room with a solid color background could I then have a tile version of the coin in that room repeated a lot for crazy money collecting or would that have to be static (as in the coin doesn't spin)?
They can spin, but they would have to use one of the background palettes. The closest one you have to the coins is palette 0, which I think is similar enough.
If this was an actual NES game (which unfortunately isn't the case...
), we would have to talk about the HUD. It doesn't appear to be using the background palettes, and because of the 8 sprites per scanline limit you obviously can't draw it using only sprites.
Also, it's too close to the edge of the screen, which is bad because TVs usually crop part of the image. Important information should always be a few pixels (at least 12 or so) away from the edges of the screen, or else the chances that the player won't be able to see them are very high.
You may chose to take this into consideration or not, since this is not an actual NES program.
You know, the quality of the graphics really looks incredible.
Ok,
some slight changes.
Had to lose the font being in the players colors as those are sprites and I guess the font has to be background tiles and I've moved it down as suggested. I chose to use the background font of the rocks as I'm also using that for wood on other level tilesets (particularly the castle tiles I started before this forest set) so the font shouldn't change colors on other levels. I may have to rethink the hearts as they don't really fit any of the background palettes on this level and have ended up a bit green to stand out which isn't so bad in itself but that particular background palette is likely to change on other levels so might need to just replace it with something simple. I removed the seperator line as not sure if that is easily doable or not.
I've made a candle on wall tile which (while resulting in green candlesticks but that's not a big deal) eases off on the sprites per line. The candle flames can fit in one 8x8 sprite.
I've also added a version of the chest as a background tile. Figure this one can be used commonly and the blue/white sprite version is much less common and filled with greater treasure.
SMB1 World 1-1 palette layout:
BG: Hills / Ground / Sky / ? blocks (animated)
OBJ: Mario / GreenWhiteSkin / RedWhiteSkin / Goomba
But in World 1-2 it switches to
OBJ: Mario / BlueLightDark / RedWhiteSkin / BlueGoomba
The BlueLightDark appears to be a muted version of GreenWhiteSkin.
psycopathicteen wrote:
Doesn't the Starman and the Fire Flower just rotate through all 4 palettes?
On second thought, you're right. The leaves use GreenWhiteSkin, and the inflorescence switches among all palettes. Coins and flames use the RedWhiteSkin palette, and broken bricks use the Goomba palette. Starman switches between the Goomba and RedWhiteSkin palette.
Now back to our regularly scheduled topic:
Carnivac wrote:
Ok,
some slight changes.
Very impressive. Another test would be to pixel the background for a whole level.
As for the HUD: You can learn the theory behind what the TV cuts off in our
wiki article about overscan.
Carnivac wrote:
Ok,
some slight changes.
All decisions you made were good. The dragons in the HUD will probably be cut off, but I guess they are not essential.
It's a very good thing that you are thinking about the other levels, because since some items are present in every level, their palettes can't change.
How my (old) TV cuts off stuff. Approximation.
Just gonna throw this out there: am I the only one who's wondering what the point of this thread is given that the game in question (assuming there even is a game -- an artist-drawn shot doesn't really indicate there's a game) **will not** be on the NES?
For example, if I was doing a 320x200 DOS game, I really wouldn't care to "mimic the NES" given that you're entitled to a 256-colour palette where you can use any of those colours for any pixel anywhere in 320x200 space.
Same applies to things like overscan and other whatnots (assuming it's a PC title).
I guess you could say I'm trying to figure out what the purpose is, given that the system its intended for is not the NES. If it's "I want it to look authentic" then make it look authentic per limits and specification of the system its intended for.
There is nothing wrong with making authentic retro-looking graphics or games for modern platforms. Not everyone are able or interested in taking challenges of making of actual NES game, some people just want to recreate the feel.
koitsu wrote:
For example, if I was doing a 320x200 DOS game, I really wouldn't care to "mimic the NES" given that you're entitled to a 256-colour palette where you can use any of those colours for any pixel anywhere in 320x200 space.
To expand on what Shiru said: Mega Man 9 and 10 mostly adhere to NES restrictions.
Quote:
Same applies to things like overscan and other whatnots (assuming it's a PC title).
Overscan still applies to home theater PCs and modded game consoles.
I don't see anything wrong about mimicking the feel of another machine... Do I prefer the real deal? Sure, but not everyone can spend years trying to learn how to code for their favorite systems just because they want to make a few games in the spirit of those systems...
The limitations of each system is what makes them unique, and that creates a certain "style" for the software of each console. With time, that style becomes more than just a consequence of those limitations and becomes an actual entity that people learn to like (or hate!).
Nowadays, computers can be used to render photorealistic images, but some people still use them for traditional hand-drawn animation. Those people are mimicking something that used to be done on paper in order to create something in a style they like, instead of making "better use" of the machine and generating the most complex thing it has to offer.
Except the author isn't mimicking the feel of another machine. The attribute table limitations are obviously not being considered, amongst other things.
I have no problem with someone wanting to make a "NES-like" game for another platform -- totally awesome, no qualms -- but there's a point where the degree one mimics something becomes unnecessary/superfluous. I mean really, overscan? Curved corners due to trapezoidal and CRT (electron gun)-specific aspects? Come on guys, seriously.
koitsu wrote:
The attribute table limitations are obviously not being considered, amongst other things.
You haven't really read the thread, have you? The first screen he posted had attribute clashes, but when those were pointed out he fixed it. If it still looks like these limitations are not being considered, it's just because the graphics are really really good, since as far as I can tell, the latest screens are respecting the attribute grid.
Quote:
I mean really, overscan? Curved corners due to trapezoidal and CRT (electron gun)-specific aspects? Come on guys, seriously.
I don't think this was ever considered... The very few times things like these were discussed in this thread were just to tell the OP to be careful about the information he's placing near the edges of the screen. PCs obviously don't crop the image, but since NES games always had some "breathing room" around the image it would be a good idea to include that in his game too.
Safe area on TVs always had influence to game stats and messages placement and size.
TV screen imitation added a lot of feel in
this project.
Again: what indication is there that this is a game to be played on a television screen? And no, I didn't read the full thread because people are already getting totally wild and crazy over "NES focus" despite from the get-go the OP stating it's not a NES game. Again: it's just an artist mock-up of an in-game screenshot and he wanted an "accurate NES palette" (as we know there is no such thing). No other information has been given.
Settle down, bud!
Quote:
Again: it's just an artist mock-up of an in-game screenshot and he wanted an "accurate NES palette" (as we know there is no such thing).
I did state that the original image was an actual screenshot from the game, not a mock up. The later images are then edited with advice from here to help me get a better idea of how to make it truly NES-compatible so I can now go back and edit the game to match.
Ok, to be clear it's a real playable game. Yes it's on PC but I'm a bit of a retro nut when it comes to pixelling and I find limited palettes and low resolutions far more fascinating to work with than ridiculous amounts of colors and 'HD' (I loathe HD 2D games such as the awful remake graphics in games like Super Street Fighter II Turbo HD Remix which completely miss the point as to why the pixel sprites worked so well). Despite any issues I have with Nintendo these days (or ever since I wasted money on the N64) I'm still a fan of their old school stuff like the NES, SNES and Gameboy and still play the games of those systems on emulators for my laptop and PSP (damn I love having thousands of roms on me to play at any time) and I like to homage that era of gaming.
Now the point of me coming here and asking for help with the palette and learning about this whole attribute thing is that I thought if I'm trying to make it feel NES-like I may as well go the extra mile and try to design it as if it really was a NES game. If I finish this and people like it enough that a NES game coder wants to take a shot at programming a real NES rom of it to be played on emulators or even possibly putting onto a cartridge to be played on a real NES, then the game should be easy enough to do as there shouldn't be anything in it going on that the NES can't actually do. I'd quite happily pass on to them all the extra graphics and NSF music and game notes and everything.
Anyways I'm still not quite happy with the status bar. And wondering if I can rework one of the background palettes to make room for a general background palette with some lighter colors in to take care of the status panel and any ingame menus and stuff. I've nothing else to do today as class has been cancelled this week so I may as well give it a shot.
Ya know what's weird though? I spent so much time sorting the attributes thing yesterday that it even affected my dreams last night. I recall walking about a city full of people and with some strange ability I was able to visually condense all their color groups into a bunch of small reusable palettes. Very bizarre...
If it's a PC game, then have fun implementing limitations that you really don't need to implement (re: sprite limitations, palette/attribute limitations, etc.). There is absolutely nothing "NES compatible" about the PC, so porting from a more advanced platform to a platform made 25 years ago is fairly nonsensical. Remember: we're just talking about pixels and colours here, there's so much else to consider that it's not even worth considering (IMO).
And FWIW, I don't care for excessive 3D crap these days either. But I also would not want to play a PC game that acts and behaves exactly like a NES game (with all of the NES's architectural limitations, particularly with regards to the PPU). Sometimes it's best to make sacrifices and be appreciative of the advancements PC architecture provides. And this statement comes from someone who really despises x86 architecture.
I don't get what it is you seem to be trying to achieve with this arguing. I simply want to make a NES-like game on my laptop here as a hobby project. I want to keep it to NES limitations as best as possible so that someone who can actually make NES games can have a go at producing it for NES emulators. The advantage of that being the rom could then just run on any system that already can emulate the NES. I also like the challenge of limitations and also using them to keep control of a project (no incentive to let things spiral out of control and never get the darn thing finished like I've had happen so many times in the past).
Think of the PC version as being a NES prototype if nothing else. The reason there's a PC version at all is that's the only system I know how to make a game on. I've no real interest in PC gaming other than using my laptop as an emulation machine.
I just don't know why you seem intent on pushing your negative views onto my personal project in that way. I came here looking for advice on NES limitations which is what I have been getting from the other much more helpful members. Everything you've said pretty much goes against the reason I came here looking for help and makes me wonder why you're even posting in this topic.
koitsu wrote:
Again: what indication is there that this is a game to be played on a television screen?
I'm of the opinion that all PC games should support a mode for a home theater PC.
Carnivac wrote:
I want to keep it to NES limitations as best as possible so that someone who can actually make NES games can have a go at producing it for NES emulators.
Translation: We might get the next Battle Kid or Super Bat Puncher out of this if, after the PC prototype is done, someone decides to join the project as the NES port programmer.
So in other words, as you said:
koitsu wrote:
Settle down, bud!
You shouldn't get it too personal but people here on nesdev are quite vocal and may have strong opinion on some subject so don't let it get to you
We are quite a "colorful" community. Once you pass that stage, you won't mind that much anymore. It may be a shock at the begining
I love retro style and it's going well. It there is a chance that someone port it to the nes, even better. So staying by those "limitations" will help that process since the nes has a lot of them, and some of them are quite a pain.
As for 2D in "HD", most maker don't know what the hell they are making but Arc System, the makers of Blaze Blue, Hard Corps, Guilty gear etc knows what they are doing. This is the rare exception where it actually looks good.
Ok, fairly huge edit this time. An all new level layout to display it too. The purple sky is gone but the benefit of that is I could optimize the background palettes better and free up a whole palette for use as the status panel palette and also use that to do a new chest tile coloring.
The palette optimization actually inspired me to dig out some old unused background forestry tiles I did years ago and put them here to give a nice sense of depth and atmosphere.
The status panel has been overhauled totally and uses a framed look for each player's status stuff that was inspired by the NES port of the Turtles arcade game. Added dragon portraits in their colors too which can be sprites up there and the hearts have been relegated to 8x8 tiles. Hopefully the more compact format of the status bar allows it to be seen on any TV without the sides getting chopped off.
I've added a crate tile using the rock/wood background palette and this can be used like a basic chest, being able to be smashed to reveal a coin or gem would then is counted as collected and disappears (in a similar way to how a coin is bumped out of a ? block in SMB and disappears quickly so it doesn't stick around)
I'm really liking how this is looking now. Somewhat more unified in color scheme and much more NES-like without sacrificing too much of my original graphics.
tepples wrote:
koitsu wrote:
Again: what indication is there that this is a game to be played on a television screen?
I'm of the opinion that all PC games should support a mode for a home theater PC.
Are we talking about HTPCs connected to flat screens or CRTs? Most flat screens have the ability to turn overscan off and in every occasion I have connected a PC to a TV there has been the ability to compensate for overscan within the GFX card's drivers.
Anyhoow, Im loving what I'm seeing here, just if you are going to run the images thrugh a NTSC filter to guage the final result I only ask that you do the same for PAL.
I love the new HUD. You are a really talented artist!
My only complaint is the green dragon... I mean, his side of the HUD is not mirrored from the other half, so to me it doesn't make sense to mirror just the dragon, it just causes his right side be cropped by nothing. I think it would look much cooler if he was simply facing right too.
Hojo_Norem wrote:
just if you are going to run the images thrugh a NTSC filter to guage the final result I only ask that you do the same for PAL.
I'm not sure what that means.
tokumaru wrote:
My only complaint is the green dragon... I mean, his side of the HUD is not mirrored from the other half, so to me it doesn't make sense to mirror just the dragon, it just causes his right side be cropped by nothing. I think it would look much cooler if he was simply facing right too.
Ok I flipped it. They were originally mirrored but some of it wasn't working right so put them both the same way but I had originally left the green one facing left cos it just looked a bit more dynamic. I suppose him facing right now makes it easier to spot the differences in the portrait as the dragons are meant to be twins but male and female so have subtle differences.
Carnivac wrote:
Hojo_Norem wrote:
just if you are going to run the images thrugh a NTSC filter to guage the final result I only ask that you do the same for PAL.
I'm not sure what that means.
The NES and Super NES PPUs take shortcuts when generating the composite video signals. Blargg wrote a program called "snes_ntsc" that applies a filter to a 256x240 pixel image to simulate the artifacts that these shortcuts cause. Do you want me to run it on your latest mock-up?
tepples wrote:
The NES and Super NES PPUs take shortcuts when generating the composite video signals. Blargg wrote a program called "snes_ntsc" that applies a filter to a 256x240 pixel image to simulate the artifacts that these shortcuts cause. Do you want me to run it on your latest mock-up?
If you like. I still don't quite get it.
Anyways I've done some more tinkering with palettes and stuff. Mainly I wanted to see if there was a way I could bring back the fire and ice dragon idea I originally wanted where a power up would give the dragon the fire ability in the same way as Mario (though with more uses such as a quick small fireball, a more concentrated short range flame and it affecting certain things) and also an ice power up used to freeze and shatter things (like freezing an enemy to stand on, or freezing an airborne enemy to have them crashing down, frozen 16x16 enemies turning into a generic ice block with eyes much the way that in Bubble Bobble enemies in a bubble would have visible eyes which I felt added some charm) but the way I had it before, the palettes wouldn't allow a physical sign that the dragons had one or the other. I've now swiched things about a bit so that the 2nd player dragon is more of an orange and now both can go red/yellow when they obtain a fire power up and also the other sprite palette has now an icy blue scheme so they can turn blue when they have ice power. Ok the downside of the color switching is that the coins now have a bit of a reddish look but then NES graphics are all about compromise and I think I can get used to them looking like that.
Also I added some more edited stuff from past abandoned projects I felt fit well here. Things like 16x16 3 color enemies and lil fairy thing.
I was wondering if I could flicker the fire objects between the palettes 5 and 6 for a subtle firey flicker look.
Also regarding projectiles. How did various shooters on the NES that fired horizontally deal with the 8 sprites on a row limit?
How flickering works:
Here's Megaman 2 with a bunch of sprites in the same row. Everything is flickery.
Whenever the NES draws sprites, it takes the first 8 sprites it finds in that scanline, and discards the rest.
So the game has to put the sprites in a different order, so a different group of sprites gets discarded instead. So instead of sprites missing, you get flickering. This is called "OAM Cycling".
Here it is again in super slow motion, so you can see that sprites are clearly disappearing.
If a game has 8 sprites and projectiles, it needs to flicker the sprites so projectiles or sprites don't disappear.
Carnivac wrote:
I was wondering if I could flicker the fire objects between the palettes 5 and 6 for a subtle firey flicker look.
Absolutely; also you're allowed to change palette entries every vsync.
Quote:
Also regarding projectiles. How did various shooters on the NES that fired horizontally deal with the 8 sprites on a row limit?
Flicker gets you to 16 (and uncomfortably higher) -- I've seen at least one game where the bullets always flicker, making it less obvious when the limitation's been hit; making the projectiles move so fast as to never exceed the limitation; placing the projectiles into the background tiles; and raster effects allow you to replace any number of scanlines with a different valid background.
Still looks awesome! (but I kinda miss the C64-like appearance of the earlier previews ;p)
lidnariq wrote:
I've seen at least one game where the bullets always flicker, making it less obvious when the limitation's been hit
For examples the explosions and smoke particles in my game
Thwaite.
Quote:
making the projectiles move so fast as to never exceed the limitation
Let me guess: Recca. It flickers, but it's not as noticeable because everything's so dang fast.
Quote:
placing the projectiles into the background tiles
How does that get rendered fast enough?
Anyway, about the latest mock-up, here's what it might look like through an NES PPU. Notice the jagged edges at the sides of the trees and the somewhat broken appearance of the empty hearts in the status bar.
And about palette changes to reflect power-ups: Super Mario Bros. 3 shows the hero's tailed form by changing the shape with the same palette. Super Mario Land 2 and the Wario Land series show powerups as hats.
I'm not a big fan of the fire/ice thing. The powers are OK, it's the palettes that I don't like.
The orange palette is too similar to the fire palette, so the overall impression is that you gave up on a lot of collors just for this effect. Also, because of the subtle difference, it will be hard to tell whether the orange dragon has the fire power-up or not.
Another problem with this color scheme is that when both dragons have the same power-up it will be really hard to tell them apart, since they aren't that different from each other.
tepples wrote:
And about palette changes to reflect power-ups: Super Mario Bros. 3 shows the hero's tailed form by changing the shape with the same palette. Super Mario Land 2 and the Wario Land series show powerups as hats.
I believe these are better options to indicate power-ups. Or icons in the status bar, like in
Kirby's Adventure.
Quote:
Still looks awesome! (but I kinda miss the C64-like appearance of the earlier previews ;p)
Ugh, C64-like? I sure hope not. Was one of the few 8 bits I never could stand the graphics of mainly due to the drab palette.
tokumaru wrote:
I'm not a big fan of the fire/ice thing. The powers are OK, it's the palettes that I don't like.
The orange palette is too similar to the fire palette, so the overall impression is that you gave up on a lot of collors just for this effect. Also, because of the subtle difference, it will be hard to tell whether the orange dragon has the fire power-up or not.
I was knackered and didn't explain properly before (and the image is a bit misleading with the dragons rendered in all three palettes). The green dragon would turn blue and use ice and the orange one would turn deep red to use fire. They would be selectable at the start as to which one Player 1 would want to be. If both are playing then, like LittleBigPlanet, there would be small areas that both players have to co-operate to gain access to and often do it by combining their abilities. Such as setting fire to a particular obstacle and then using ice to put out the flames and clear the path. So niether dragon would ever be the same color as each other. And I didn't waste colors like you say, I needed a sort of orange range for sprites that could be 'woody' or 'rocky' but still needed the red/yellow for fire effects and to me they certainly look different enough to be clearly recognisible while being just similar enough that I can flicker between the two for the flames to give them a nice effect.
tepples wrote:
And about palette changes to reflect power-ups: Super Mario Bros. 3 shows the hero's tailed form by changing the shape with the same palette. Super Mario Land 2 and the Wario Land series show powerups as hats.
I believe these are better options to indicate power-ups. Or icons in the status bar, like in
Kirby's Adventure.[/quote]
I always found the hats to just look tacky and icons in the status panel is boring (in Kirby I only liked the power ups that gave him something fun to use such as the sword). As for 'changing the shape' there isn't much room in a 16x16 sprite to do a lot to it and I've no idea what fire or ice powers would do to a dragon's shape that could work in that small an area or make any sense.
I'll have to think about it but I'm pretty busy with training and rehearsals for the next week or two so won't be about much. By the way that TV-like filtered image seems alright. I prefer sharp clean pixels (with or without scanlines) but yeah it's nice to see how it might have looked on a real NES plugged into TV.
Anyways seeya sometime
Thanks for all the help.
Just a lil post before I head off to say I've tinkered more with the Player 2 palette and after using light brown (which worked fine on wood but made the dragon look like a turd) I've gone a different route and used pink which seems fitting for a girl dragon and looks significantly different to the fire palette so she clearly upgrades. Also it gives a bit more color to the levels too with the pink gems and flowers and enemies.
Because of the new pink some of the things had to be removed from that palette such as the chicken but then it hit me that because of the use of black added from using those dark faraway trees I can swap more things from sprites to background tiles. For example the chicken is now a tile using the wood/rock browns and has a solid black background which means I can put it anywhere which would be black or mostly black anyways. Can do the same when I want to add lots of coins as background tiles.
Ok I'm gone. Seeya soon, folks
Just FYI, if you're ever worried about the status bar tiles taking up valuable CHR space, most decent memory mappers will allow you to swap CHR banks mid-screen. Super Mario Bros. 3 (MMC3) does this with its status bar, as do many RPGs.
You can also change some palette colors, but AFAIK this can cause glitches if not done properly.
Here's a minor suggestion, you don't need to take it...
In Super Mario 1, if Luigi gets a fire flower, he is indistinguishable from firey Mario. I always thought that was annoying to no end.
So if you are going to change which palette a character is using, I would suggest that you make it blink between their normal colors and the "I have fire" palette, so you can still tell which character is which.
Here is how it looks like with a resolution of 341x224, which is 2 pixels for every color cycle.
Dwedit wrote:
Here's a minor suggestion, you don't need to take it...
In Super Mario 1, if Luigi gets a fire flower, he is indistinguishable from firey Mario. I always thought that was annoying to no end.
So if you are going to change which palette a character is using, I would suggest that you make it blink between their normal colors and the "I have fire" palette, so you can still tell which character is which.
Just discovered this neat old thread.
I know it probably doesn't matter in a concrete sense now, but alternatively he could have switched palettes on the boxes around the dragon statuses at the top to show "Has Fire Power". That would be highly visible and yet not detrimental to identifying and locating the dragons on the playfield.
Old thread is old o_o
But since the topic has been brought up, maybe a better idea would be to just give Luigi his current colors (basically green Mario) and then leave his old ones as the fire version.