I think I've seen some Genesis games that overlay tiles or overlap sprites in order to fake objects with more than 16 colors.
I don't think I've seen this in NES games. Why not? Or, am I missing the instances where they do?
I could at least see tile/sprite combinations happening as coarse movement was more acceptable back then.
Did you ever play Mega Man? It's considered the poster child for this technique.
Contra splits sprites into a top and bottom half.
The title screen of Tetris 2 uses a very coarse tile/sprite combination to make the block edges jagged.
NES can't do it with the background because it only has 1 layer.
But several games do it with sprites. The most well known of which is Megaman, which uses a different colored sprite for megaman's face. The portraits in the stage select screen are also often combinations of sprites and the BG in order to get more color usage.
Just Breed does this for the currently "active" players. When active, your players are a combination of blue and red colored sprites which makes them look very colorful, but when inactive it drops the red sprites and they have an overall blue tint.
EDIT: ninja'd!
Mighty Final Fight, another Capcom game, also uses overlapping sprites for more colors.
tepples wrote:
Contra splits sprites into a top and bottom half.
Final Fantasy does this too, for the player sprite on the maps.
Thanks guys. I missed alot of those games that had overlayed tiles/sprites. I never got into MegaMan. Contra may have used two seperate sprites but it didn't seem to be overlapping them. I'll have to look harder.
SMB2(USA) had added sprite overlap to create a effect for white eyes.
the USA version of Journey to Silius uses another sprite color for the Player's head just like Megaman!
The main character in Gargoyle's Quest II looks too colorful for the NES, so there's probably some sprite layering going on.
Many games use part of the background as a huge "sprite." Blaster Master, Super C, and Crystalis do this, among many others. It's pretty typical for these games to place sprites with additional colors on top of the background sprite.
I just fought a boss in Crystalis that used a green palette, with eye sprites on top that used a red palette. May not technically be layered sprites, but it's the same principle.
As far as I remember, Double Dragon 2 (possibly 1 as well) uses this technique a lot for its characters too, which IMO opinion is more noticeable than the Rockman games.
SMB2US (but not the original FDS Doki Doki Panic) may have done this with the characters' eyes too.
The disadvantages with this method are that having overlapping sprites could give more flickers to a game as you can only display 8 sprites each of 8-pixel wide on each line, and that the system only has 4 subpalettes for sprites (and 4 for the background layer; this is in some sense worse in the case of the Mega Drive though), so using more than 1 subpalettes for 1 objects would need the other objects to share colours more often.
The Dragon Warrior games use this technique extensively for the monster graphics. With the larger monsters in DW3 and DW4, the tile and sprite "layers" noticeably desynchronize when the monsters flash when taking damage.
Battletoads does that for cutscenes(Sprites layered on BG).
Fantastic Dizzy also uses sprite layering. The body ("Egg") is Pal0 while Dizzy's hands and legs are Pal1.
Denine wrote:
Battletoads does that for cutscenes(Sprites layered on BG).
The toads obviously use some layering to combine green and yellow parts in game too.
3gengames wrote:
I'd imagine contra does.
Contra has been mentioned in the first reply, but apparently it doesn't overlap the sprites, it just uses different palettes for different parts of the sprite.
tokumaru wrote:
3gengames wrote:
I'd imagine contra does.
Contra has been mentioned in the first reply, but apparently it doesn't overlap the sprites, it just uses different palettes for different parts of the sprite.
Ah, okay. I was just playing it with a friend and just thought of this threads title when I noticed it.
I'd imaging Gimmick overlaps some sprites thinking about it...
Gimmick has a separate sprite for his orange hat.
Actually, something unusual about Gimmick is that it uses the same sprite palette set for the whole game. All sprites are green, orange, black, or pink.
How does it not overlap for SOMETHING? It has 4 colors on it's main body.
Green, darker green, black, and white.
There's no black. Gimmick's pupils are dark green.
rainwarrior wrote:
There's no black. Gimmick's pupils are dark green.
The main character's name is not really Gimmick, It is Yumetaro, at least according to the Japanese version.
Oh really??? I wonder who Mr. Gimmick is...
rainwarrior wrote:
Oh really??? I wonder who Mr. Gimmick is...
I do not know, Sunsoft possibly thought of making fun of it's own games, like Ufouria!
rainwarrior wrote:
Actually, something unusual about Gimmick is that it uses the same sprite palette set for the whole game.
I believe that "Treasure Island Dizzy" does that too.
Treasure Island Dizzy uses a seperate palette on the Status Bar using Sprite 0 also.
Hamtaro126 wrote:
Treasure Island Dizzy uses a seperate palette on the Status Bar using Sprite 0 also.
So do Fantastic Dizzy and Dizzy The Adventrer.
I was thinking about an alternative way to show more colorful sprites (and probably backgrounds) on the NES.
It creates an illusion that a 3-color sprite seems to have 5 (or more) colors without overlapping techniques.
My goal was to make a 5-color Donkey Kong like this:
So I've created two images - both with 3 colors (black, brown and skin color).
Wherever I wanted lighter tones of brown I inserted skin / brown lines. And wherever I wanted darker tones of brown I inserted black / brown lines.
Colors of these lines are different on each image (a brown line on image number 1 is black on number 2 and vice-versa):
If you make both images alternate fast enough you'll have the illusion of a sprite with more colors.
You can see by yourselves downloading a Rom with this Donkey Kong experiment:
http://www.mediafire.com/?3yjs10pvgb94engIt's not the ideal solution (because the colors are always "shaking" and you need two versions of the same image) but maybe someone can make a good use of this.
This ROM was created with NES Image Converter by thefox. Thanks again for this wonderful program!
Flickering looks great on an LCD screen, where screens tend to be slow to refresh, and it looks like the average of the two colors. But on a CRT TV, where the screen can completely refresh at 60FPS without blur, flickering looks terrible. If you have Batman, you can see this for yourself when you watch the intro.
Also, you can post attachments here. No need for mediafire.
Yeah, flickering looks terrible on CRTs, and it also has the disadvantage of slowing the game down to 30fps, since you need objects to be in the same positions for 2 consecutive frames.
Is there a reason you interlaced detail horizontally, like so:
Attachment:
DK2.gif [ 614 Bytes | Viewed 4380 times ]
And not checkerboard dithered, like so:
Attachment:
DK2chk.gif [ 666 Bytes | Viewed 4380 times ]
?
The flickering was a common tech for demo coders on all platforms, and in games made by demo coders. Barely seen in commercial games, because it doesn't look too good.
Batman isn't the best example, though, because it flickers between two completely different pictures, which is the worst case scenario.
It isn't necessary to slow down the gameplay to half of the frame rate, by the way. There was an attempt of SMB unofficial port to ZX Spectrum (Soviet clones, to be exact) that used flickering to increase number of shades from 2 to 3 and it was running at 50 FPS, which is quite an achievement for the platform. It didn't look too bad. Unfortunately, all videos of the game on YouTube aren't represent the game well at all, they all has crazy lag (
example).
Contra looks epic doing the flickering in the 2nd bases boss. Super contra intro I don't like as much. Those are the only place I've really noticed using sprite overlapping being used on even/odd frames.
Project MD does that flickering trick just about, um, everywhere, even in the freaking arrow in menus (and in levels the effect is outright fullscreen) - though instead of using horizontal patterns it uses checkerboard patterns. It works fine as long as the game never slows down (which there never happens, but it could be prone to happen in a NES game, I guess).
EDIT: what's going on with that game in the video Shiru linked?! Things start going seriously crazy in world 1-2 o_O
Shiru wrote:
The flickering was a common tech for demo coders on all platforms, and in games made by demo coders. Barely seen in commercial games, because it doesn't look too good.
Batman isn't the best example, though, because it flickers between two completely different pictures, which is the worst case scenario.
It isn't necessary to slow down the gameplay to half of the frame rate, by the way. There was an attempt of SMB unofficial port to ZX Spectrum (Soviet clones, to be exact) that used flickering to increase number of shades from 2 to 3 and it was running at 50 FPS, which is quite an achievement for the platform. It didn't look too bad. Unfortunately, all videos of the game on YouTube aren't represent the game well at all, they all has crazy lag (
example).
Thanks for this explanation Shiru! I had no idea that flickering sprites were already used in the past.
lidnariq wrote:
Is there a reason you interlaced detail horizontally, like so:
And not checkerboard dithered, like so:
?
The software I'm using sorta creates these lines automatically - but your suggestion was really appreciated, thanks! =)
I tried to do it using checkerboard dither and the results are even better (Simba.NES is attached)!
lidnariq wrote:
Is there a reason you interlaced detail horizontally [...] And not checkerboard dithered
On the NTSC NES, checkerboard is more likely to result in annoying diagonal artifacts. See
rgb121.
As for in-game flicker,
Thwaite is
made of it. All explosions flicker for semi-transparency, and all smoke flickers to allow more smoke to be drawn.
EDIT: link repaired
tepples wrote:
On the NTSC NES, checkerboard is more likely to result in annoying diagonal artifacts.
Use vertical strips then?
I wish I could buy a Powerpak and see (the results of flickering) by myself on my CRT television. I have a PAL-M famiclone - so maybe the interlaced image can look a little different from a NTSC NES.
It's a shame that it may create all these artifacts... I'm making new checkerboards tests and I'm more and more impressed with the results (another Rom is attached).
These pictures are looking very good on my old TFT (25ms response time), I'd say perfect, because the flicker isn't visible at all. However, I seen how flicker looks on a normal CRT TV, and it is nowhere nearly as good, the flickering is easily noticeable, especially on large areas.
The flickering is very subtle in the tests you posted, and the colors don't vary much, so in this case it might work. Still, what you get is the illusion of more shades of the same color, not more colors.
tokumaru wrote:
The flickering is very subtle in the tests you posted, and the colors don't vary much, so in this case it might work. Still, what you get is the illusion of more shades of the same color, not more colors.
Well, different shades are different colors. But I understand what you're saying: when you need completely different colors the good old sprite overlap is still necessary.
I prefer to use this technique in sprites without many color variations - to me it's when it really works. But you can easily mix different colors and the results are nice too.
Download my "4 into 10 colors" test. You see green created from yellow and blue, purple from blue and red, etc.
By the way with this demo I can finally see diagonal artifacts (thanks to the amazing CRT filters found on Nestopia emulator).
I don't know if the artifacts are more evident on a real CRT TV but (judging by what I can see on Nestopia) they're not as annoying as I tought.
Just my $2, but while this kind of flickering usually works great with emulators on modern PC-workstations with LCDs, it tends to look terrible on an authentic system with a CRT, it doesn't look transparent at all and actually looks like flickering.
At least the intro of Batman looks terrible on a true CRT.
Bregalad wrote:
Just my $2, but while this kind of flickering usually works great with emulators on modern PC-workstations with LCDs, it tends to look terrible on an authentic system with a CRT, it doesn't look transparent at all and actually looks like flickering.
At least the intro of Batman looks terrible on a true CRT.
Which is why in Project MD I used the checkerboard pattern. Stripes are
very noticeable because they're very big areas so the eyes can easily spot them out. The checkerboard pattern gives you the smallest area possible and as long as vsync is accurate (i.e. 1 frame = 1 refresh rate) it's practically impossible to tell. This works fine even when with crystal clear output.
And of course, the more similar the two shades, the better the effect works. Middle red vs. light red is more likely to work fine than blue vs. green, for example.
I once got a 120Hz refresh rate on a CRT, it was some kind of VGA mode where it omitted half the scanlines. On that video mode, flickering looked exactly like half transparency.
I think it was Nesticle that had that video mode as an option. You had to turn off the frame limiter, but turn on VSYNC.
But 60Hz is far too slow for flickering to look any good on a CRT.
When I messed with this kind of flickering it was only on CRTs, I don't have any LCD screens around. Unless you mean raw flickering rather than using patterns, then yes, it's going to look horrible at any framerate unless the areas in question are small enough.
Also you need to take into account the ideal refresh rate of the CRT monitor, since this affects for how long the light stays on screen. Computer monitors are generally made for 85Hz (early ones for 70Hz), while TVs are generally made for around 60Hz. This means that the 120Hz mode you mentioned most likely exceeded the ideal refresh rate of the monitor and had such a slow reaction that indeed turned the flickering into real transparency.
The human eye has been proven to be able to distinguish up to 240Hz at least, so I'd expect flickering to be noticeable up to that rate.
Sik wrote:
The human eye has been proven to be able to distinguish up to 240Hz at least, so I'd expect flickering to be noticeable up to that rate.
That's a really tricky assertion; those assertions are talking about two different abilities of human perception.
One is what's called the
flicker fusion threshold, which is a function of ambient light level, but is generally accepted in rigorous experiments and the brightest conditions to be pretty strictly never above 100Hz for humans. If you hear someone complaining about magnetic ballast fluorescent lights, they may well be seeing stroboscopic effects or complaining about color rendering index or sound but they are unequivocally not seeings the 120Hz (US) directly.
The other is the ability to detect phase difference, which can easily go up to this 240Hz, or more accurately, down to 4ms. Detecting phase difference is plausible is other cases, but is entirely different from what you see when you look at a CRT.
The examples look pretty good, too bad I don't have a CRT TV to test them on. Still, I think this method might be a worthwhile tradeoff between more flicker/more detail/less sprites on scanline [and funnily enough, less sprite limitation based flicker because of that] in some cases.
thefox wrote:
The examples look pretty good, too bad I don't have a CRT TV to test them on. Still, I think this method might be a worthwhile tradeoff between more flicker/more detail/less sprites on scanline [and funnily enough, less sprite limitation based flicker because of that] in some cases.
Thanks thefox! By the way Streemerz rules
lidnariq wrote:
Sik wrote:
The human eye has been proven to be able to distinguish up to 240Hz at least, so I'd expect flickering to be noticeable up to that rate.
That's a really tricky assertion; those assertions are talking about two different abilities of human perception.
One is what's called the
flicker fusion threshold, which is a function of ambient light level, but is generally accepted in rigorous experiments and the brightest conditions to be pretty strictly never above 100Hz for humans. If you hear someone complaining about magnetic ballast fluorescent lights, they may well be seeing stroboscopic effects or complaining about color rendering index or sound but they are unequivocally not seeings the 120Hz (US) directly.
The other is the ability to detect phase difference, which can easily go up to this 240Hz, or more accurately, down to 4ms. Detecting phase difference is plausible is other cases, but is entirely different from what you see when you look at a CRT.
It's trickier than that still, how much the perception of light stays depends on how strong it was (and probably which color). I recall once making a game which was mostly dark but had white dots as stars, and when scrolling around they'd leave a trail. Taking into account the length of the trail and the game framerate, those dots lasted like around 1/12th of a second. There's no way a CRT has that much of a latency, so it obviously has to be the eye playing tricks there.
In any case I never received any complaints at all about the flickering trick on a CRT (the only time I did was on an emulator and I doubt the monitor refresh rate was 60Hz), so maybe it looking horrible is specific to the NES hardware or something. The whole dot crawling thing on the NES may affect it possibly. Again, it only works fine when the two colors are relatively similar shades (e.g. not more than 25% away per component in the RGB scale) and if it's a checkerboard pattern (other patterns are just way too noticeable, especially things like stripes).
Hi, I'm new to the site and to NES Dev in general, and I was wondering something... Could you mix the sprite layering thing with the use of meta-sprites to get even more colors? I have an example that I made of what I'm talking about. I took a sprite of link from Zelda 2 for the NES (Which I always thought could use some improvement) and adjusted it to illustrate my point. I am wondering if this could even be done. Has it been done? If so can anyone think of an example? Are there any problems that come up with doing this? If so I assume it would have something to do with sprite limits on the screen or something. It is a pretty significant increase in the number of colors. The original sprite has 3 plus transparency and the new one has 10 plus transparency. That's quite a difference, and I dare say it almost looks like SNES or GBA graphics! I also, have the sprites separated in such a way that if the palette of green were swapped out for the red one or the blue one it changes the color of his clothing. I Assume they would have used some of these techniques but at the time this game was made I bet the tech wasn't good enough or something. I'm thinking if this were at all possible it would probably require the use of some kind of memory mapper chip or something. Am I right by thinking this? Thanks all for your help and comments.
Yep, just remember the NES only has 4x 3 color palettes and also can only display EIGHT 8x8 or 8x16 tiles in one scanline, so layering takes away the sprites available in other objects.
Problems with this idea:
- You'll need either CHR-RAM (which can be slow!) or limit movement to 8-pixel steps
- You can't assign palettes to each individual background tile, only in groups of 2×2
- You'll have to cope with overlapping sprites
- You can only use 256 unique background tiles at a time (mapper raster effects aside)
- You can't flip background tiles
So you'll need to cope with all that if you pretend to use that method. If you think you can, go ahead, but you have been warned.
EDIT: also yes, 4 palettes of 3 colors each... for each layer. So it's four palettes for sprites and four for backgrounds (eight total). Also the transparent color acts as an extra color for background tiles.
Reusing colors is not that hard anyway =P
ZenRyU wrote:
Hi, I'm new to the site and to NES Dev in general, and I was wondering something... Could you mix the sprite layering thing with the use of meta-sprites to get even more colors?
Your use of the term "meta-sprites" is very confusing. That term is usually used to mean that the hardware's 8x8/8x16 sprites are combined to form bigger (meta)sprites (to coincide with the term metatiles -- combining 8x8 background tiles to form bigger (meta)tiles).
So I fail to see what's different about "LAYERED" and "META-SPRITE" in your picture.
Quote:
I fail to see what's different about "LAYERED" and "META-SPRITE" in your picture.
Same here. Aparently, some have assumed that "meta-sprites" means sprites drawn with background tiles, which is not what we usually mean.
If that's indeed the idea, I don't think it's very practical. Moving that sprite will be much more difficult (because of the pattern and name table updates), and you'd have to give up on backgrounds. I see little advantage in having a few SNES-like sprites if that meanshaving dull backgrounds and few palettes available for everything else.
IMO, sprites with a few overlayed details is the best compromise.
I believe "meta sprite" is referring to a sprite that does not have overlapping tiles, but gives many different tiles their own palette. Confusing terminology, but I think that's what it means.
My only comment is that you need to have more than just Link on the screen, obviously. Sprite tiles and palettes are usually worth conserving a bit more than that. It should work fine by itself though.
Perhaps I am using the term meta sprites wrong, but from what I understood it meant large sprites made of a bunch of small sprites that share a common color (Like black). To make the sprite look as though, overall, it has more colors, like in my example. I see now that I have the right idea and I could, hypothetically, do it. However, it would probably be the only thing I could do that way, because it would max out the NES, leaving link a lonely hero with no enemies to fight and no one to save.
I'd like to thank all of you who have commented. It really helped me to figure this stuff out. You guys are great!
There is no "shared color" limit for metasprites. Just the normal 4 palettes of 3 colors. Metasprites don't need to be arranged in a grid either.
ZenRyU wrote:
Perhaps I am using the term meta sprites wrong, but from what I understood it meant large sprites made of a bunch of small sprites that share a common color (Like black). To make the sprite look as though, overall, it has more colors, like in my example. I see now that I have the right idea and I could, hypothetically, do it. However, it would probably be the only thing I could do that way, because it would max out the NES, leaving link a lonely hero with no enemies to fight and no one to save.
I'd like to thank all of you who have commented. It really helped me to figure this stuff out. You guys are great!
I was thinking about this and I think it should be feasible (i.e. you could still have an actual game) if you put a limitation on the graphical style where sprites can only move within a solid color space (color 0) - this would make it much easier to render the dynamic BG tiles containing the extra colors outside of vblank, and prepare a kind of "display list" for the vblank routine so it could make the updates as fast as possible. And you should limit the player's character size to 16x16. Maaaybe 16x24. Additionally, with a very large ROM, the horizontal-shifting part of the process could be pre-calculated, speeding the effect up dramatically.
The solid BG color limitation would be well-suited to a game set in a cave, or underwater, or maybe a piece of copy paper.
sonder wrote:
...if you put a limitation on the graphical style where sprites can only move within a solid color space (color 0)...
Many games do this kind of thing to draw large enemy objects, like here:
http://youtu.be/Z8v_aLnf9Iw?t=5m30sThe background color is not just changing for dramatic effect.
sonder wrote:
...if you put a limitation on the graphical style where sprites can only move within a solid color space (color 0)...
Many games do this kind of thing to draw large enemy objects, like here:
http://youtu.be/Z8v_aLnf9Iw?t=5m34sThe background color is not just changing for dramatic effect.
Movax12 wrote:
sonder wrote:
...if you put a limitation on the graphical style where sprites can only move within a solid color space (color 0)...
Many games do this kind of thing to draw large enemy objects, like here:
http://youtu.be/Z8v_aLnf9Iw?t=5m34sThe background color is not just changing for dramatic effect.
I was more illustrating an idea that sprites (or at least, the player sprite) could only venture onto tiles on the nametable that are blank (color 0).