Mid-scanline BG mode changing in practice (attn: byuu)

So I'm currently working on the item sub-menu for my WIP RPG, featuring a mid-scanline BG mode change from mode 5 to mode 1 using H-IRQ.

Unfortunately, the right "half" of the screen sort of jiggles around on higan ...




... but is rock-solid on real hardware.



(Don't bother about the partly-visible sprite on the upper right, it's a known issue.)

Here's the ROM so you can try it out for yourself:
http://manuloewe.de/snestuff/projects/furryrpg_build_00265.7z

Am I just lucky with my hardware (1-Chip SNES Jr.), or is this something emulator-related?

Thanks!
Ramsis

PS: Yes, the thread title is meant to contribute to that fancy new "attn: byuu" trend.

From what I understand, DRAM refresh on most versions of the hardware doesn't happen at exactly the same time on every scanline, hence the "wiggling" in higan - my guess is that on your hardware, it's still happening early enough in the scanline not to affect any of what you're currently displaying on screen.

What happens on your hardware if you shift the text to the left and then do the mode change a bit earlier?

Interesting, thanks for the info.

Just having arrived back at Lion's den (i.e. my home, where I have all SNES hardware revisions available to test my code on), I can report that the picture is also rock-solid both on my PAL (2/1/3 non-1-Chip but SuperCIC-enhanced) unit and on my treasured (1/1/1, unmodified) Super Famicom -- further tests on North American 2/1/X consoles (where X < 3) will follow. Until then, I don't see a reason to change my carefully-crafted, known-working code yet again (for worse?).

I can try it on my NA 2/1/1 later tonight.

That's a whole lot of zeroes on the item number. Sounds like you're gonna have a whole lot of items in this game, eh?

No idea what's causing it, but which version of higan are you using? We had some mid-scanline mode change fixes recently. If it's broken in v099, then I'm honestly not sure why.

Try and fill out the screen more so it'll be a more interesting test case to fix, please :D
And of course, the $6,000,000 question ... why are you trying to do this? Because it can be done? :P
I'll be a lot more interested if there's something to be gained from doing a mode 5->1 vertical split.

I doubt DRAM refresh has much to do with the wiggling. An IRQ won't reliably fall within one dot even if the CPU is in WAI, which means that unless you're using timed code your writes will exhibit some jitter regardless.

It does look like you might be dangerously close to DRAM refresh, which could make the switch range much wider than it otherwise would be (though there's no evidence of this in the screens you posted; the wiggle looks pretty compact). The Anthrox demo seems to fall afoul of this, depending on boot alignment, but the giant 64-dot-wide sprite mask mostly hides it; you can only tell because of the pattern of black flecks that shows through the sprite layer. On the other hand, switching from Mode 5 to Mode 1 might involve less visible garbage than a switch from Mode 7 to Mode 2...

EDIT: I wonder if the problem in higan might be because pixels aren't the same size on both sides of the split. Could that be throwing off the scroll calculation?

Looks stable on my hardware too, but is similarly wobbly in both higan v099 and current bsnes-plus.

Here's a comparison in bsnes-plus before and after the commit that fixed the vertical split in that Anthrox intro (I assume higan would behave similarly). Although it's not noticeable in the screenshot, the rightmost one or two columns of pixels on the high-res text are also affected in the second ("after") screenshot.

You should fill the rest of the screen with test text as well, just to make sure your status screen is viable all the way down with the same trick.

Nah, 256 at most (and probably less). The many zeroes result from me quickly setting up a list of test item names by simply copying a base string, ItemXXXXXXXXXXXX, 256 times and replacing the Xs with ascending numbers using TextPad, the only text editor I know that offers such a feature.


There are two reasons for this: 1) All possible 16 characters of an item name are printed on the menu screen, which would not be the case with generic placeholder item names like "Potion__________" or "Heavy Shield____" (i.e., the trailing spaces wouldn't be visible.) 2) Items printed to the screen are distinguishable. I can immediately check whether my item selection handler (to be written, ahem) works because I know exactly which of the 256 items is being printed.

See what I did there?


I'm aware of this (and using v099), but it didn't change much in this case (see Revenant's screenshots).


In short, it's a visual design choice.

To elaborate, I don't want to annoy players with abbreviated item names in my game, hence the generous 16-character limit. I experimented with an easy-to-implement Mode 1 sub menu like you've seen a hundred times before. There wouldn't be much room on the screen, save for the item list. Yes, I could just go with HDMA and/or a V-IRQ and have my hi-res description/misc. info on the top or bottom of the screen. But how generic and boring is that? Instead, I'm envisaging something like this:


Unfortunately, this specific patch (CT Finnish with an 8×8 menu VWF) only works on ZSNES because (AFAIK) it tries to write to VRAM outside of Vblank. The only other option to achieve a similar effect would be to use static rendering for item names, as you once described. In fact, I'd probably do it if my game wasn't multi-language, and if I had any clue on how to do the static rendering work efficiently without having to spend weeks on manually pixelling it all together. Not to mention that I'd have to start from scratch should I ever decide to change the font.


Here you go:





Turns out there's still a palette issue to be fixed for Mode 5 ... oh well. And also, the first line of As flickers on real hardware too, but since I just fill the entire BG3 tile map for this test instead of properly aligning the text, this is nothing to worry about.

ROM:
http://manuloewe.de/snestuff/projects/furryrpg_build_00265a.7z

Thanks for all the help, guys!
Ramsis

Animal Crossing also uses 16-character names. Perhaps you could use, say, the list of clothes items as placeholders.


Or make a VWF renderer whose transfer does fit into vblank. It's been done for the Action 53 menu, RHDE, the 2-player version of robotfindskitten, the NES port of 240p test suite, and Nova the Squirrel. And if it's possible on NES, it ought to be possible on Super NES. The one drawback is that the game has to be designed around it, with a buffer of about 160 bytes or so in main RAM for a rendered line of text. It may not be ideal for adding to an existing proprietary game whose publisher is hostile to amateur derivatives, as the publisher of Chrono Trigger is known to be.


If you do decide to go the route of a separate ROM per language, I've made a bitmap font renderer in Python. You open it, pass it a font description file that references a PNG, enter text, and it will send a PNG of the rendered text to the screen, to a file, or to GIMP. It's here, but the package uploaded there does not include a standalone executable for Microsoft Windows.

Thanks a lot, tepples, great work!

Edit: Indeed, your tool is no less than awesome! I could even have the item sub-menu display two columns of items without it looking too cluttered, and go with a vertical split screen setup for descriptions/misc. info. Fantastic!

Now with that major hurdle (i.e., creating an image out of plain text) out of the way, I might actually consider scrapping the vertical split screen altogether and taking the static rendering route instead, especially since the former does have drawbacks of its own ... hmmm ...