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.
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.
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.
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.
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!
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=5m30s
The 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=5m34s
The 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=5m34s
The 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).
I'd like to thank all of you who have commented. It really helped me to figure this stuff out. You guys are great!
