Thank you for the discussion re: the title screen. I have decided to agree that the amount of stuff on the title screen must be reduced.
I don't like the idea of a splash screen before the title screen, but pressing Select to view a Credits screen seems like a compromise that wouldn't make the purists too angry.
I agree with this idea. But I would add it on the title screen rather than on the main menu screen. Whether it's a scroll-down to view the version information; whether it shows/hides the version information on the same screen; whether it brings another screen totally; that is up to more planning. I do not like splash screens, so a mandatory splash screen will never happen with this patch.
The purpose of the listing of the patch options along with the version number is twofold:
-- When given a bug report, provide a possibility to identify the exact version with which the bug happens.
-- To avoid the problem of someone passing a stripped-down or otherwise encumbered version as "the" translation release.
The data for the title screen tile layout; does it ever get shifted around? Same for the menu screen.
You probably are referring to the tiles, i.e. VROM content for those particular screens.
They might, but if that happens, it is very rarely. I don't think I'm going to move the Konami logo and the game title graphics around within those VROM pages, but the alphabet may be subject to some rearrangements. The version number string just uses whatever tiles remain otherwise unused. The list of tiles used by the version box is currently hardcoded as this:
$tiles = Array(
Although, if I change the version information to a hotkey-only display, this is going to change in some ways that I haven't decided yet.
As for the nametable/attribute/palette data for the title screen -- yes, that is subject to random placement within the ROM. It can be placed anywhere in the allowed banks by the linker. You cannot rely on it being at some particular location. It is not intentionally
randomized, but the binpacking algorithm can put it anywhere within the constraints of bank numbers. Any time the number of blobs changes or the length of any of them changes, the binpacker can produce a totally different organization for them. You can only know the location of some particular blob by reading the pointers that refer to it. IIRC the location of those pointers is constant (but still different for NTSC versus PAL).
This is the theme for all the data that I modify. Instead of modifying the data in place, I capture the entire data, remember where it is referred from, mark its old location as "free space", and at link-time, place the (now possibly modified) data in some free nook, and update the pointers to the data. Some of those pointers can even be within blobs that are themselves relocated.
By the way, a reminder, even though I haven't so far released the full insertor nor the patch source code, if anyone has questions on its implementation, I will gladly answer any well-defined questions and can also share parts of the source code.