User talk:Myask/Myapper thoughts

From NESdev Wiki
Jump to navigationJump to search

Textbox Bank

I'm confused by what you mean when you say "might need to use sprites to mark the corners" ... I assumed you mean visually, except that "otherwise you need extra viable start- and end-tile designations" is incongruous? After all, the NES fetches 34 background tiles, then 8 sprite tiles, and the address bus doesn't give any hint as to the sprite X coordinate, and so I don't see how using using sprites to mark corners helps. —Lidnariq (talk) 11:54, 14 October 2016 (MDT)

Just visually, yes. Supposing you had simple rectangular[ish] boxes like in Dragon Warrior, you'd need top corner, side edge, bottom corner for start and stop tiles; one could allow there to be three different tiles each of "select bank X" to allow for this (in the mapper design; as this hasn't passed the stage where the mapper is incorrigible). I think it's a bad idea, but one could do it. Alternately, if one leaves the top and bottom edges in a/the not-inside-box bank, so you don't have to switch those lines in, then you don't get the 'free' breaking in half of the 16-pixel attribute, be it for opening/closing of the box or just so you don't have to align on those boundaries for top/bottom.
I'd think to go for four to eight options, with one being "what the rest of the mapper thinks".
Though, now you mention it, the sprite fetches could trigger it, too, [just at scanline bounds] which leads to the handy fallout that is fire-and-forget, no-interrupt, no-spinning on sprite0, no cycle timing scanline-triggered banking. (I suppose you still have to set scroll registers for, say, a status bar, so it's not a miracle.)
Of course, in the Omniscient Mapper case where we've spied on and saved a copy of OAMDMA to cartside, you could use that sort of thing, but you might as well just allow arbitrary X/Y-specified banking then, and take out the sprite middleman. Myask (talk) 19:29, 14 October 2016 (MDT)