It is currently Thu Oct 19, 2017 2:16 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 3 posts ] 
Author Message
PostPosted: Mon Aug 14, 2017 9:50 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 936
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?


Top
 Profile  
 
PostPosted: Fri Aug 18, 2017 11:21 pm 
Offline
User avatar

Joined: Fri Feb 27, 2009 2:35 pm
Posts: 211
Location: Fort Wayne, Indiana
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).


Top
 Profile  
 
PostPosted: Sat Aug 19, 2017 11:22 am 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 936
--

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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 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