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.
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.
- Perhaps MMC5 (mapper 5) games? That's the only one I can mention.
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.
Klax uses scrolling trickery to reduce 16x16 pixel attribute cells to 16x8 so that the 16x8 pixel playfield objects can be individually colored.
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.
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.
Quote:
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.