Having hacked around the nigori (dakuten/handakuten) code in Demon's Blazon, I now have some extra space to work with (the space that was previously available for the nigori).

I talked to Gemini about it, and he said I would want to move the tilemap to take advantage of the new space. DaMarsMan says otherwise. Does anyone actually KNOW what I'd want to try to do?

Here's a picture for an example:



See all that empty space above each line of text? I want to use that for extra text (effectively giving me about 2+ extra lines per dialogue box).

~DS

Thanks, I'll give that a shot when I get home. Definitely need to read more about SNES hardware, though. ^_^

~DS

Might as well use this as an excuse to explain a little about tilemaps.

Basically, the screen is built with tiles. You knew that. The tilemap is what says which tile to display in which particular location, whether it needs to be flipped or rotated, and what palette gets assigned to it. If you think of the SNES's screen as a grid containing 16x16 tiles (although that's not *strictly* correct it'll work for our example) the tilemap is the grid itself, with each 2-byte entry representing a single tile. Thus since each row is 16 tiles, it contains 32 bytes. When your game ADC #$40 or ADC #$0040 it's moving the write cursor past the current #$20 byte line, then leaving the *next* #$20 byte line blank.

What DaMarsMan says about the dualline hack is mostly correct, except in this case doing something like this is a whole lot simpler. Dualline hacks (at least the way I do them) require that you write your own linebreak routine specifically for an item list that doesn't normally *have* a linebreak command, then making sure that it doesn't muck up where the next item afterwards goes. For your game, you're just modifying existing code, not rolling your own from scratch. It's a whole lot easier

Once you've successfully located the tilemap, either in wram or in vram, try playing around with the values and seeing what happens to the stuff on-screen. Best way to learn!

I try to stay away from the kind of hack you're proposing, though. It tends to make the screen a little busier than it ought to be, and it's something I'd like to keep a definite leash on from here out.

Yes.. there is GREAT significance to the number. Did you not read the information? Re-read it again and tell us why he suggested 40.

In all seriousness, if you can answer that question, you'll understand why 7 is most likely not going to be correct.

Gideon provided an example of horizontal logic. Another alternative the game may have with it's tilemap is vertical logic with the tilemap. It may have a y coordinate for the line it draws one which gets incremented by 2 to skip a blank line. Or it may get incremented by one. That 'virtual' coordinate will then be run through a few lines of code to turn into the actual tilemap address to start writing on.

We're also assuming here the font is just a straight tile mapped font (full font is permanently stored in VRAM) Did you verify that to be correct? I don't like to make assumptions in ROMhacking. I've been tricked before assuming a game did something a certain way, pounding my head not finding the answer because I wasn't open minded enough that it was doing something different. It's easy to fall into the assumption trap.

Instead, I approach things with an idea of what I may find, however I still keep the mentality that I have no clue until something concrete in the code or ROM/RAM/VRAM tells me otherwise. Facts only basis.

Because you're putting the breakpoint in the wrong place, perhaps?

Set a read breakpoint for the first line of text in the ROM (use a tool like Lunar Address to convert the PC address to the SNES address) and step through the code. See if it actually goes through your print routine.