NES hsync tricks

You can talk about almost anything that you want to on this board.

Moderator: Moderators

Post Reply
tomaitheous
Posts: 592
Joined: Thu Aug 28, 2008 1:17 am
Contact:

NES hsync tricks

Post by tomaitheous » Mon Dec 29, 2008 1:46 am

Just wondering if any demos or games used the hsync tilemap repositioning trick to overcome the colors per tile limitation? That or for limited transparency effects.

User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Post by kyuusaku » Mon Dec 29, 2008 2:01 am

Care to elaborate?

tomaitheous
Posts: 592
Joined: Thu Aug 28, 2008 1:17 am
Contact:

Post by tomaitheous » Mon Dec 29, 2008 2:28 am

Well, say you have a tile map that can hold 4 screens (since I mentioned NES - lets assume 4 separate nametable mode). If on every 2nd scanline you reposition the X/Y regs to point to a different section of the 4 tilemaps, you can create 16x2 pseudo tiles - thus lessening the color requires per tile. Basically you're reassigning a new palette per 2pixel row within a single tile. I hope that helps explain it.

I've not had any experience with the MMC5 (or is it 6) in which the BG tiles are given 1x1 cell palette association instead of 4x4 cell, but it would be nice to able to combine that with the above method for an 8x2 pseudo tile setup.


The transparency effect works in a similar way. For NES, divide the BG palettes into 2 or 4 sections. During an hsync interrupt, you position the tilemap to another section. Dividing the subpalettes into two sections only needs one hsync map repositioning, but you have two sets of 8(7) colors. Divide the subpalettes into 4 sections and have 4 sets of colors - less colors per scanline but 4 levels give more of a gradient option at the cost of more hsync changes and a more complex map buffering system. You don't need to have the screen map duplicated 4 times, just one or so horizontal row for each change. I mean, unless you plan on doing something more complex.

User avatar
Zepper
Formerly Fx3
Posts: 3192
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Post by Zepper » Mon Dec 29, 2008 5:23 am

- Perhaps MMC5 (mapper 5) games? That's the only one I can mention. :|

User avatar
Bregalad
Posts: 7814
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Mon Dec 29, 2008 6:17 am

I'm not sure what you mean, but yeah it's possible to overcome the color limitation because attributes tables are fetched each scanline.
However, to get such effects it wastes most CPU times during the effect, so it's hard to have such an effect that takes the whole screen. However if it only takes a part of the screen this seems doable, altough I haven't understood everything.
Life is complex: it has both real and imaginary components.

tepples
Posts: 21888
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon Dec 29, 2008 9:02 am

Klax uses scrolling trickery to reduce 16x16 pixel attribute cells to 16x8 so that the 16x8 pixel playfield objects can be individually colored.

User avatar
Memblers
Site Admin
Posts: 3801
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers » Mon Dec 29, 2008 3:36 pm

I did one make one demo that does something as ridiculous as changing a palette byte and attribute byte (but only one or the other, each scanline). All that PPU handing required turning the screen off early (on every scanline!). The demo itself is not much to look at, and the timing barely even works.

Definitely changing the selected nametable is simpler. It's easy to get 4 nametables, so you could have 16x4 attributes that way.

tomaitheous
Posts: 592
Joined: Thu Aug 28, 2008 1:17 am
Contact:

Post by tomaitheous » Tue Dec 30, 2008 11:27 pm

tepples wrote:Klax uses scrolling trickery to reduce 16x16 pixel attribute cells to 16x8 so that the 16x8 pixel playfield objects can be individually colored.
Awesome! Thanks for the bit of info. It's the first that I know.
Definitely changing the selected nametable is simpler. It's easy to get 4 nametables, so you could have 16x4 attributes that way.
Oh, correct. I was stilling thinking in terms of 8x8 when I wrote 16x2. And I was referring to full screen. 16x2 for a smaller window, sure.

Post Reply