By horizontally, I meant that bit2 of $2000 was 0. After looking at that PPU Registers wiki page again, it says that bit determines how the CPU writes to VRAM. So writing to VRAM is filling that buffer with info and then the PPU reads that RAM buffer while drawing a screen? If so, I'm sorry for my mistake. But mistakes are ok.lidnariq wrote:No. Screens are drawn from top to bottom. The range of 192<=x<256 is when, within any given scanline, you have to turn off rendering, IF you do, in order for sprites to not be broken the next time rendering turns on.unregistered wrote:disable rendering when x>=192 (while each screen is drawn horizontally... right?)
There's no restriction on which scanline number (Y) you turn off rendering, but it will produce a solid-colored bar at the bottom of the screen.
Ahh! So that's much better! We just have to disable rendering when the PPU is drawing pixels, from pixel 192 to pixel 255, on any scanline! Sigh , I thought your 'x' was just a variable name, but it also was specifying that the limit you were trying to teach is a horizontal limit. So, that is only necessary to protect sprite locations? Thought you said it also affected the attribute tables...
A solid bar at the bottom of the screen has never appeared for me.
My code is now 16536 cycles; it's plenty quick for just updating the screen.lidnariq wrote:The entire amount of time the CPU has per redraw, regardless of whether the PPU is drawing, is 341*262/3 ~~ 29780. Your code needs to be a lot faster for "only letting the PPU draw part of the time" to be an adequate solution.unregistered wrote:and my screen drawing currently takes 16,832 cycles,
Thank you for your recomendation! I'll definitly think about this... time for lunch.lidnariq wrote:I'd strongly recommend figuring out how to divide uploads across multiple refreshes. You're going to need it anyway.