Originally posted by Sakuya IzayoiI'm curious though, what would happen if there weren't enough "unused right now on-screen" tiles to house the message graphics? Would it just overwrite a used one and disable other sprite tiles so it wouldn't show?
My slot-assignment loop handles that gracefully, but I don't think the actual uploading code does. I do think, though, that it'll be pretty darn difficult to try to get enough sprites onscreen for there to not be enough slots, but I'll look into addressing the problem if it actually becomes an issue.
Originally posted by AlcaroOriginally posted by WiimeiserWhat surprises me is that there's apparently no way to have it change only part of the Layer 3 tilemap, like that's a limitation of the SNES...
It is. The layers can, and do, scroll; if layer 3 has an 8x8 tile half outside the screen, the message box contents would also be shifted a few pixels (up to 4, both horizontally and vertically), which looks rather weird if
you're alert. (Either that, or layer 3 would need to move while the box is opening, which is even easier to notice.)
The box itself is windowing HDMA and can move independently of the layers, but that doesn't help since the contents would still be L3.
The way one would handle /that/ would be to have 128 different IRQs. You'd run them at the start of the black box onscreen (for max. 8 pixels) and at 8 pixels from the end of the box onscreen (for 8 pixels) for each scanline that contains text tiles.
On the left-side IRQs, you'd enable FBlank, preserve and alter the scroll registers, probably alter your tilemap address (so you can use a completely different tilemap in VRAM), and then turn FBlank off. On the right-side IRQ's, you'd enable FBlank, restore all of that stuff, and then disable it again. This would account for scrolling both normally and from HDMA.
Haven't actually looked into whether or not there'd be some catches with this, or if you could get the IRQ code to run fast enough, but it's the other idea I've had in my head.