It is currently Thu Nov 23, 2017 1:03 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 27 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Wed Nov 30, 2011 2:26 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2366
Using an in-cart chip to render silhouettes or outlines of sprites onto the background layer, so sprites can use 4 colors as opposed to the usual 3.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2011 2:29 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7273
Location: Chexbres, VD, Switzerland
Never throught about this, but yeah sounds interesting. However wouldn't it requires --terribly-- complex logic on the cart ? Something something even more than the MMC5 ?

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2011 3:19 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2366
Maybe there can be dual 256x32x8-bit buffers, with the 6502 buffering the "shadow image" on one buffer while the other is being superimposed over the background layer by the chip.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2011 3:23 pm 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 348
Yeah, this idea has popped into my mind a few times. But like Bregalad said, it'd require some fairly advanced logic, probably an FPGA with internal RAM.

The most straightforward way I could think of would be to basically have a duplicated sprite renderer in the chip, which would be able to logically AND the CHR data bus before the PPU receives it, based on screen positions and 1-bit CHR patterns in this extra SPR-RAM.

Would need quite a bit of redundant hardware and CHR memory though, for just one extra color...


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2011 4:58 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19252
Location: NE Indiana, USA (NTSC)
And now for "Taking the limit as x increases without bound", with your friend Pino:

Someone needs to make a TV tuner circuit for the NES. I've described before how it would work: decode NTSC, put luma on tile data, and put average chroma over 8x1 pixels on attribute. Then we can put all this enhancement chip garbage to rest with "Just plug your Xbox 360 into your NES."


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2011 5:01 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2366
Bananmos wrote:
Yeah, this idea has popped into my mind a few times. But like Bregalad said, it'd require some fairly advanced logic, probably an FPGA with internal RAM.

The most straightforward way I could think of would be to basically have a duplicated sprite renderer in the chip, which would be able to logically AND the CHR data bus before the PPU receives it, based on screen positions and 1-bit CHR patterns in this extra SPR-RAM.

Would need quite a bit of redundant hardware and CHR memory though, for just one extra color...


In the post above, I stated that the 6502 can software render the sprite shadows to a buffer, so it doesn't need a duplicated sprite renderer.

It just needs to be able to calculate the current screen position, fetch the next 8 needed pixels from the buffer, and barrel shift them with the previous 8 pixels.


Top
 Profile  
 
 Post subject: Sounds speccy
PostPosted: Wed Nov 30, 2011 5:16 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19252
Location: NE Indiana, USA (NTSC)
So in other words, sort of how sprites were drawn back on the ZX Spectrum.


Top
 Profile  
 
 Post subject: Re: Sounds speccy
PostPosted: Wed Nov 30, 2011 5:42 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2366
tepples wrote:
So in other words, sort of how sprites were drawn back on the ZX Spectrum.


Not really. The background will be drawn the same way it allways is. The chip will just super-impose silhouettes ontop of the bg patterns being fetched. Then the PPU renders sprites ontop of the silhouettes to acheive 4-color sprites.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2011 5:58 pm 
Offline

Joined: Sun Mar 19, 2006 9:44 pm
Posts: 920
Location: Japan
But.... that means the silhouettes will all be square-shaped, or they will still need tile colour 0 to be transparent so the silhouettes can have a shape of their own, thus making tiles 3 colours only again!

Think about it and you'll see it's a problem that can't be corrected through "chip magic"

_________________
http://www.chrismcovell.com


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2011 6:22 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 2:13 pm
Posts: 1667
Location: .ma.us
A mapper can replace the BG attribute and pattern table fetches to give *4* more colors (one being the BG color) from any BG palette. So 7 colors + transparency = pseudo 3 bpp. If this is done it should be highly hardware accelerated (preemptively masking sprite pattern fetches) otherwise it'll be hell to program and slow. If someone's going this far they should also enhance the BG too. I think it'd be nice to allow each tile to select any 4 colors of the 13. Oh an a programmable MMC2-like feature to expand past 256 tiles. And individual tile auto-animation like the Neo Geo.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2011 10:28 pm 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2803
While we are at it, how bout a second 6502 core running at a faster clock rate so you can process more calculations each frame to avoid slowdowns and have even more going on at once in your game.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2011 11:22 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3951
Worked for Super Mario RPG.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 01, 2011 10:09 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7273
Location: Chexbres, VD, Switzerland
Sooooo,
Doing it with CHR-RAM + software mapping would work but be really slow to upload, it might work if done only on the hero's sprite and if this sprite is fairly small (something like 16x16) so you have at worse something like 6 tiles to upload, so why not. One more color can be very significant, and doing it with two-layered sprites will eat some of the precious 8 sprites per scanline.

Doing it with a chip sounds nice, but the chip would have to be complicated. In addition to the normal CHR ROM/RAM, an additional layer of CHR-ROM/RAM of at least 1BP should be present in the mapper, and the mapper should be able to logically AND the normal BG with it's internal "sprite shadow rednering" as Bananmos said.
While you're doing something as complex, why not extend it to more BP so you can allow other BG colors to be used in your sprites too ? That way you could get for example if you have one color in common in all BG palettes, 5 color sprites (transparent color + shared color + normal 3) without eating some of the precious 8 sprites per limitation.
However, again this would require a crazy complex FPGA based mapper.


For really large sprites (probably more than 24x24), it's possible to do this for the middle of the sprite manually, by just using solid colors on the nametable and change them as the player advances, this way the transparent color in the middle of the sprites becomes this "solid" color, while the transparent colors of the border of the sprites are really transparent.
I think this is common on some older computers, but on the NES it's not practical due to the 16x16 attribute limitation, so I guess again a shared color between all the palettes is more suitable for this.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 01, 2011 11:23 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Quote:
it's possible to do this for the middle of the sprite manually, by just using solid colors on the nametable and change them as the player advances, this way the transparent color in the middle of the sprites becomes this "solid" color, while the transparent colors of the border of the sprites are really transparent.


This would only work if the sprite is aligned perfectly with the current fine X scroll, and if it only moves in blocks of 8 pixels at a time. Otherwise the "solid" pixels will scroll over the BG tile and become transparent (and vice versa with the actually transparent pixels).

And there's also that fundamental attribute limitation with the PPU. At best, each 8x1 block has to use the same attribute data. So the only way to make a silouette/outline that could be freely moved like a sprite would be to have all 4 BG palettes share the same color -- so basically you'd have to use $3F00 as the extra color unless you want to waste a good chunk of your palette.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 01, 2011 11:42 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2366
Bregalad wrote:

While you're doing something as complex, why not extend it to more BP so you can allow other BG colors to be used in your sprites too ? That way you could get for example if you have one color in common in all BG palettes, 5 color sprites (transparent color + shared color + normal 3) without eating some of the precious 8 sprites per limitation.
However, again this would require a crazy complex FPGA based mapper.



...and maybe you can designate a palette for tiles that the sprites don't cross, so you can still use that extra color.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 27 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 15 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group