The logic behind NTSC distortion and graphic limits

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

Post Reply
GL|Hcktrox
Posts: 3
Joined: Fri Oct 30, 2015 12:00 pm

The logic behind NTSC distortion and graphic limits

Post by GL|Hcktrox »

Hello.

I'm working on a project I have for the SegaCD videogame console, named "Alphaomega". It's about the character Miles "Tails" Prower being caught inside a graphical, artificial dimension and what has to do in order to go back to real world. The gameplay and level map style is meant to be similar as the old 16-bit Sonic the hedgehog games, but it has a bunch of ideas and concepts that doesn't fit to a Sonic the Hedgehog game, so Sonic isn't present for this game :P

I'm doing some drafts for a new level I'll get started with really soon, which for now I named as "Bitfield Zone". The goal here is to keep it, somehow, with a NES vibe to it.
Of course the Sega Genesis' video chip couldn't apply any post-processing effects to the final image (other than scanline-specific tweaks), but the least I can do is to implement this new art in such a way that looks visually accurate on screen, not only taking the color limts into account (which I need to be aware of yet!), but I'd also like to represent stuff such as a fake sprite limit, the color distortion (i.e. when some shading seem to appear like diagonal bar), etc.

What do I need to know?
Thank you!
EDIT: Grammar/Redaction
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: The logic behind NTSC distortion and graphic limits

Post by tokumaru »

I think that NTSC artifacts would be difficult to simulate accurately, considering that the Genesis VDP has its own set of peculiarities that affect the video it generates.

But you could certainly make the video more similar to that of the NES by using the 256-pixel video mode, instead of the 320-pixel one. Use only 1 background layer, and try to approximate the colors that are available in the NES palette. You can even have real sprite flickering, if you place dummy high-priority sprites across the whole height of the screen to reduce the number of sprites you can actually use on each scanline.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: The logic behind NTSC distortion and graphic limits

Post by tepples »

The Genesis VDP can show 16 sprites and 32 slivers per line in 256 pixel mode or 20 sprites and 40 slivers per line in 320 pixel mode. The NES can show only 8 sprites and 8 slivers. So I'd guess the sprite limits can be simulated by putting six high-priority 32x32 pixel transparent sprites on each line with more than 8 sprites in order to eat up 24 of the 32 slivers, though that would also eat up most of your OAM. (The sprite display list in Genesis 256px mode has only 64 entries, as on the Master System and NES.)

But you probably won't be able to pull off a convincing diagonal bar distortion on a Genesis VDP. Its color burst lines up vertically, not diagonally, like the Master System screenshot at ccovell's page. Both a Genesis VDP in 256px mode and the NES/SNES PPU use the TMS9918 pixel rate of three pixels per two color burst periods. But the Genesis VDP keeps the 342 pixels per line of the TMS9918, compared to 341 for the Nintendo parts.

SG-1000, CreatiVision, ColecoVision, Master System, Genesis:
342 pixels per line * 2/3 color burst periods per pixel = 228 color burst periods per line
Because this is an integer, color artifacts line up directly below each other.

NES, Super NES:
341 pixels per line * 2/3 color burst periods per pixel = 227.33 color burst periods per line
Because this is not an integer, color artifacts line up diagonally.

Standard TV, by contrast, has 227.5 color burst periods per line, which produces an even checkerboard. If the NES or Super NES PPU added an extra master clock (1/4 pixel) to each line's horizontal blanking, it would produce a standard scanline period and thus artifacts closer to those of standard TV.
GL|Hcktrox
Posts: 3
Joined: Fri Oct 30, 2015 12:00 pm

Re: The logic behind NTSC distortion and graphic limits

Post by GL|Hcktrox »

Great. Also just checked, and from FCEUX' PPU viewer it seems like each of "tiles/cells" could use any of the 8 palettes out there, worth 4 colors each.
I THINK I can "purposely" make the sprites to blink here through software (in case a virtual sprite limit is reached), and I THINK I can achieve NTSC distortion by animating the necessary tiles according to the plane/sprite's vertical position and to each pair/unpair "frame number".
Is there any available NES color chart out there?
And finally, what's the maximum sprite size? (leaving alone the obvious possibility of mapping them)
Last edited by GL|Hcktrox on Fri Oct 30, 2015 1:41 pm, edited 1 time in total.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: The logic behind NTSC distortion and graphic limits

Post by tokumaru »

GL|Hcktrox wrote:And finally, what's the maximum sprite size?
Same as the Master System: sprites are either 8x8 or 8x16, globally (it's not a per-sprite setting).
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: The logic behind NTSC distortion and graphic limits

Post by tepples »

GL|Hcktrox wrote:Great. Also just checked, and from FCEUX' PPU viewer it seems like each of "tiles/cells" could use any of the 8 palettes out there, worth 4 colors each.
The background uses only the first four palettes, and the sprites use only the last four. Background palettes are assigned not to 8x8 pixel areas but to 16x16 pixel areas (2 cells by 2 cells).
Is there any available NES color chart out there?
Image
Why you won't see Fifty Shades of Grey on the NES

And finally, what's the maximum sprite size? (leaving alone the obvious possibility of mapping them)
All single sprites in a scene are 8x8 or 8x16.
GL|Hcktrox
Posts: 3
Joined: Fri Oct 30, 2015 12:00 pm

Re: The logic behind NTSC distortion and graphic limits

Post by GL|Hcktrox »

Thank you so much!
I'll update this post once I get a part of this level added and working within game.
tepples wrote: Why you won't see Fifty Shades of Grey on the NES
XD. This made my day.
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: The logic behind NTSC distortion and graphic limits

Post by TmEE »

tepples wrote:The Genesis VDP can show 16 sprites and 32 slivers per line in 256 pixel mode or 20 sprites and 40 slivers per line in 320 pixel mode. The NES can show only 8 sprites and 8 slivers. So I'd guess the sprite limits can be simulated by putting six high-priority 32x32 pixel transparent sprites on each line with more than 8 sprites in order to eat up 24 of the 32 slivers, though that would also eat up most of your OAM. (The sprite display list in Genesis 256px mode has only 64 entries, as on the Master System and NES.)
Sprite list has always 128 entries, just that only first 64 (or 80) sprites are parsed before cycles run out on that line (order only determined by the 7bit link value in sprite definition).
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: The logic behind NTSC distortion and graphic limits

Post by tokumaru »

So there are more entries than the VDP can parse per scanline, and you choose which ones will be parsed by creating a linked list? Interesting... I can't see much benefit in having sprite entries that won't be used though...
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: The logic behind NTSC distortion and graphic limits

Post by tepples »

tokumaru wrote:I can't see much benefit in having sprite entries that won't be used though
I guess it allows static allocation of display list entries to particular actor slots even if different frames of animation take more or fewer sprites. This frees the CPU from having to rerun the allocation every frame the way it is done on the NES.
Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: The logic behind NTSC distortion and graphic limits

Post by Sik »

TmEE wrote:Sprite list has always 128 entries, just that only first 64 (or 80) sprites are parsed before cycles run out on that line (order only determined by the 7bit link value in sprite definition).
Er no, only 80 entries, the VDP explicitly cuts the list the moment you try to use entries 80~127 (don't forget that those entries don't have room in the sprite cache). Also apparently it cuts sprites after 63 in H32 mode (though 64~79 are still usable if they were cached before... albeit it wasn't stable if I recall correctly).
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: The logic behind NTSC distortion and graphic limits

Post by TmEE »

I don't recall link values higher than 79 or 63 cutting out the rendering...

EDIT: Just did a quick test. Sprite at 0 and one at 127, and both display... buuuuut there's a peculiarity. The second sprite doesn't seem to have the Y coord I supplied on the hardware (it is positioned correctly in the emulator), rest is correct though.
EDIT2: Sprites from 80 to 127 seem to fix the Y coord at my first sprites one.
EDIT3: I added a second sprite, aaaaand the sprites in 80 to 127 are totally messed up in vertical direction. I can make out the GFX as it flickers line by line between the two normal sprites. How fun.
EDIT4: Any sprites coming back from 80...127 to the 0...79 range will not be rendered it seems.
So I will have to eat my words. Stay away from 80...127 and stick some GFX into those bytes instead !

http://www.tmeeco.eu/BitShit/SpriteFunTest.jpg
Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: The logic behind NTSC distortion and graphic limits

Post by Sik »

OK so in other words the VDP just sees high impedance from the sprite cache and whether something works or not (and how) depends entirely on whatever noise it happened to read. ¯\(º_o)/¯

Well, the warning stands, I guess.
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: The logic behind NTSC distortion and graphic limits

Post by TmEE »

Rather there is something weird going on in the sprite evaluation circuit, the line buffer does store stuff properly, but where exactly the GFX ends up is all barfed.
Post Reply