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

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
User avatar
Ramsis
Posts: 341
Joined: Sun Jul 01, 2012 6:44 am
Location: Lion's den :3
Contact:

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

Post by Ramsis »

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 ...

Image


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

Image

(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/f ... d_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. :mrgreen:
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
Revenant
Posts: 462
Joined: Sat Apr 25, 2015 1:47 pm
Location: FL

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

Post by Revenant »

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?
User avatar
Ramsis
Posts: 341
Joined: Sun Jul 01, 2012 6:44 am
Location: Lion's den :3
Contact:

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

Post by Ramsis »

Revenant wrote: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
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?). :)
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
Revenant
Posts: 462
Joined: Sat Apr 25, 2015 1:47 pm
Location: FL

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

Post by Revenant »

I can try it on my NA 2/1/1 later tonight.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

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

Post by Near »

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.
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

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

Post by 93143 »

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?
Last edited by 93143 on Fri Jun 24, 2016 4:00 pm, edited 3 times in total.
Revenant
Posts: 462
Joined: Sat Apr 25, 2015 1:47 pm
Location: FL

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

Post by Revenant »

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.
ccovell
Posts: 1045
Joined: Sun Mar 19, 2006 9:44 pm
Location: Japan
Contact:

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

Post by ccovell »

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.
User avatar
Ramsis
Posts: 341
Joined: Sun Jul 01, 2012 6:44 am
Location: Lion's den :3
Contact:

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

Post by Ramsis »

byuu wrote: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?
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.

Code: Select all

Search for  : Item............
Replace with: Item\i{0,1,12,0}
("Regular expression" must be checked)
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? :wink:
byuu wrote:No idea what's causing it, but which version of higan are you using? We had some mid-scanline mode change fixes recently.
I'm aware of this (and using v099), but it didn't change much in this case (see Revenant's screenshots). :|
byuu wrote:And of course, the $6,000,000 question ... why are you trying to do this? Because it can be done? :P
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? :wink: Instead, I'm envisaging something like this:

Image
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. ;)
byuu wrote:Try and fill out the screen more so it'll be a more interesting test case to fix, please :D
Here you go:

Image

Image

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/f ... _00265a.7z

Thanks for all the help, guys! :)
Ramsis
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

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

Post by tepples »

Ramsis wrote: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.)
Animal Crossing also uses 16-character names. Perhaps you could use, say, the list of clothes items as placeholders.
Ramsis wrote: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? :wink: Instead, I'm envisaging something like this:

Image
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.
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.
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. ;)
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.
User avatar
Ramsis
Posts: 341
Joined: Sun Jul 01, 2012 6:44 am
Location: Lion's den :3
Contact:

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

Post by Ramsis »

tepples wrote: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! :D
test2.png
test2.png (627 Bytes) Viewed 6707 times
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 ...
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
Post Reply