nesdev.org

Espozo wrote:The bigger question to me, is how the game is calculating the collision for this: https://www.youtube.com/watch?v=djW3WTE ... 285#t=3m5s I mean, granted, it slows down through almost the whole segment.

Theoretically it doesn't have to calculate anything at runtime, just store the boundaries in ROM for each degree of rotation.

psycopathicteen wrote:I see DMA overload at 9:20. I don't see that happen in too many games.

It'd probably be in the TV's overscan area anyway.

creaothceann wrote:Theoretically it doesn't have to calculate anything at runtime, just store the boundaries in ROM for each degree of rotation.

I doubt that's what it's doing though. It does this in three different areas, and they all last a good while.

creaothceann wrote:It'd probably be in the TV's overscan area anyway.

It's not, well, on my TV anyway. However, my TV is a flatscreen CRT from the 2000's, so I don't know how representative it would be of TVs from the time.

I thought about how to do the background blocking.

Use 2 tables that are 224 bytes long, with each byte corresponding to a scanline:
-layer number
-next chunk

Jump through the tables for a chunk that overlap with the beginning of the new layer, and another that overlap the end of the new layer. The chunk that overlaps the end, copy the "layer number" and "next chunk" bytes to the end of the new layer's chunk. Then change the "next chunk" byte on the chunk that overlaps the beginning (this is done afterwards in case the same chunk overlaps both of the new layer's ends). Now add the new layer's "layer number" and "next chunk" bytes to the tables.