Buffering graphics updates.

DoNotWantDoNotWant
in The Brewery
Hello!

I have been thinking about how to draw my background;

http://web.archive.org/web/20090714010738/http://nesdevhandbook.googlepages.com/theframe.html



This document suggest that you have a set buffer in RAM for the data to copy.

Would there be any disadvantages if I instead just provide a pointer to somewhere in the ROM,

and copy to the PPU in the NMI from there? Then the data could be terminated with $FF in the ROM, and I could have a counter in the PPU write loop of the NMI so I can copy a set amount of bytes every NMI to the PPU.



Would this be a good way to make sure that you don't write to the PPU outside NMI, and also save some RAM?



Thanks!

Comments

  • removed04092017removed04092017
    Yep, the buffer it's self provides overhead. It's much better to have a buffer in the $100 area. Or $200 area. If possibly unroll the loop as much as possible. And watch out, you may need the $FF for something, haha. And you should have enough RAM, this is an application where RAM is very valuable to get more CPU time, as CPU time > RAM in the NMI.
  • thefoxthefox
    The disadvantage would be that your updates can't be dynamic anymore (anything you want to upload has to be pre-defined in the ROM). Also the indirect indexing (through a pointer) is slower than if the buffer was at a static address in RAM.



    Personally I would just go with the RAM buffer, you're going to need the flexibility at some point.
  • Mario's Right NutMario's Right Nut
    It's not really difficult to set up. MetalSlime did it in one of his tutorials in NN.
  • DoNotWantDoNotWant
    Yeah, I see which way to go now, thanks guys!
Sign In or Register to comment.