Sprite identification in mapper for rotation, etc. purposes

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

Post Reply
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Sprite identification in mapper for rotation, etc. purposes

Post by Myask »

Been toying with ideas (link) of using unused sprite attribute bits, but I'm not sure if there's a cheap way to identify when sprite slot X is getting its tile fetched.

It's simple if each sprite has a unique tile, but that clashes with the benefits of having a tile-based system.

The naïve method of duplicating sprite evaluation so one knows which sprites are fetched in what order seems like it would be expensive, but I'm not yet seeing a way that can avoid it. Does anyone see something I'm missing?
User avatar
NovaSquirrel
Posts: 483
Joined: Fri Feb 27, 2009 2:35 pm
Location: Fort Wayne, Indiana
Contact:

Re: Sprite identification in mapper for rotation, etc. purpo

Post by NovaSquirrel »

Giving each sprite a unique tile isn't necessarily that bad. It'll cost block RAM, but you can have a separate list of what tile each OAM entry actually uses (where the PPU's own OAM just has increasing values).

While the OAM DMA is happening, the mapper could either lie to the NES to put increasing values in the PPU while keeping track of the actual values, or you could take advantage of this opportunity to feed in bigger tile numbers through some separate mechanism to let you assign any tile to any sprite (like how MMC5 is with background tiles).
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: Sprite identification in mapper for rotation, etc. purpo

Post by Myask »

--

hmm, forcing use of PRG-RAM [so the mapper can disable reads and substitute reads inthe OAM DMA when desired] would mean not having to ID them. Good thinking.

Catch is, you then need to do copies from the PT to your blockRAM to have them rotated. That's 64*32 operations, unless there's some arcane way to configure it to allow you to write bytes orthogonally, you're buffering eight writes in rotation registers and then writing them into the RAM.

Lessee…DMA is gonna be 8 CPU cycles per sprite, or 24 PPU cycles. That's not enough to do a complete copy and rotate. However, if you are writing into the buffer in the same direction you're reading out the rotated (/not) sprite, it doesn't matter if you still have 8 reads from buffer left when you start the next cycle of 16 writes. (But is anything showing the cart that oscillation? Do PPU/RD/WE oscillate during DMA?)

This requires the rotation bit causing the mux to flip or not rather than set/unset.
Post Reply