Scrolling RPG maps

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Scrolling RPG maps

Post by Pokun »

You shouldn't do the calculations in NMI. You calculate everything outside NMI and only fill a BG buffer with the tile data (including CHR numbers and the nametable start write address) for the tiles that needs to be changed and have a routine in NMI that checks this buffer and only changes the tiles it finds there (the Nerdy Nights sound tutorial shows how this can be done).

Doing a full 32 tile update might not be a bad idea as an RPG probably has the time to spare since they usually don't have that much action going on compared to an action game. I'm pretty sure vblank is more than enough for updating that many tiles as long as you have the BG update buffered.


BTW the official nomenclature of the 4 nametables is actually BG1, BG2, BG3 and BG4 I think, but the homebrew/hacking scene often use nametable 0 to 3 which mimics the number that D0 and D1 of PPUCTRL combines into. Doesn't matter as I think it's clear what everyone meant with their nametable numbering.


I checked the DQ and FF games in Mesen and they all use vertical mirroring just like you. They all indeed has a seam on top and bottom bottom of screen when walking north or south and does nothing to hide it. The DQ games enables the left-edge BG blanking for no apparent reason, but not the FF games. They all also only update the 17ish visible tiles, not the full 32 tile row of both nametables.

DW2 doesn't seem to store the map in RAM, so I'm not sure how it does collision. I remember someone mentioning that both DQ1 and DQ2 actually reads VRAM, so they might be doing that for collision as well. DQ2 does have a bitmap at $0400 that seems to correspond to screen data, but it's all zeroes and only flips to FF for tiles where message boxes pops up (like the menu, dialogue boxes, HP/gold display etc) and turns back to 0 when closing the box. I have no idea what it's for. Seems like a big waste of precious RAM to me.
User avatar
zanto
Posts: 57
Joined: Sun Mar 07, 2021 11:15 pm
Location: Rio de Janeiro, Brazil

Re: Scrolling RPG maps

Post by zanto »

Pokun wrote: Sun Apr 11, 2021 7:02 am You shouldn't do the calculations in NMI. You calculate everything outside NMI and only fill a BG buffer with the tile data (including CHR numbers and the nametable start write address) for the tiles that needs to be changed and have a routine in NMI that checks this buffer and only changes the tiles it finds there (the Nerdy Nights sound tutorial shows how this can be done).
I used the Nerdy Nights tutorial to help me implement left/right scrolling. But I didn't see it showing how to make up/down scrolling while vertical mirroring is enabled. At least, I couldn't find information on it. That's why I wasn't sure whether my suggestion on how to calculate the ppu memory address is correct (or efficient).

Pokun wrote: Sun Apr 11, 2021 7:02 am I checked the DQ and FF games in Mesen and they all use vertical mirroring just like you. They all indeed has a seam on top and bottom bottom of screen when walking north or south and does nothing to hide it. The DQ games enables the left-edge BG blanking for no apparent reason, but not the FF games. They all also only update the 17ish visible tiles, not the full 32 tile row of both nametables.

DW2 doesn't seem to store the map in RAM, so I'm not sure how it does collision. I remember someone mentioning that both DQ1 and DQ2 actually reads VRAM, so they might be doing that for collision as well. DQ2 does have a bitmap at $0400 that seems to correspond to screen data, but it's all zeroes and only flips to FF for tiles where message boxes pops up (like the menu, dialogue boxes, HP/gold display etc) and turns back to 0 when closing the box. I have no idea what it's for. Seems like a big waste of precious RAM to me.
I contacted the person that made the map visualizer and they told me that DW2-4 use cartridge RAM starting at $7400 (DW3) or $7800 (DW2/4) to store the map once it's built. So I guess the games store the uncompressed map in those addresses. The exception is DQ2 (J), because apparently it didn't have cartridge RAM, so it used another map system, according to them.
User avatar
zanto
Posts: 57
Joined: Sun Mar 07, 2021 11:15 pm
Location: Rio de Janeiro, Brazil

Re: Scrolling RPG maps

Post by zanto »

So, since I have to update 18 metatiles when moving up and down (16 + 1 extra metatile on each side of the scroll to avoid graphical glitches moving right and left), I ran into a new issue.

In most cases, updating 18 metatiles in a row isn't any different than what I've discussed previously. I just have to find the address in each nametable that I need to draw the tiles into.
img1.png
img1.png (6.71 KiB) Viewed 4596 times


However, there's one situation in which I have to draw into one of the nametables twice. It happens when the scroll covers exactly one nametable horizontally, as shown below.
img2.png
img2.png (6.6 KiB) Viewed 4596 times
The only solution to this that I can think of is that when scrolling down, I need to detect whether scrollx only covers one nametable and if so, I have to draw on the other nametable twice. Is this the best way to approach this or is there a better solution?
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Scrolling RPG maps

Post by calima »

Only draw the side the player is moving towards.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Scrolling RPG maps

Post by tokumaru »

You don't need to draw 18 metatiles, the screen can show at most 17 at a time. The first metatile should be at scrollX, and the last one at scrollX + 256, that's 17 metatiles.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Scrolling RPG maps

Post by Pokun »

Yeah the camera can only move in one direction at a time no matter what, so no need to waste time drawing tiles on the back end which will be overwritten if you change direction anyway.

The DQ and FF games does seem to draw half of the metatile row on top of screen and the other half on bottom of screen when scrolling north or south (but not when scrolling east or west due to vertical mirroring). But it's just a matter of positioning the seam. This way the chance that the seam is visible on an NTSC TV is as small as it can get. If you used horizontal mirroring you could do the same when scrolling east and west, but since the left-edge blanking only blanks out one character column, only half of the seam would be hidden and the right edge would have visible scrolling artifacts. I guess that's the reason DQ and FF games uses vertical mirroring as the NTSC top and bottom overscan is probably more likely to hide the seam on most TV-sets.
I guess they could still have drawn only one half of the metatile column on the left edge every 8 pixel of scrolling though.

zanto wrote: Sun Apr 11, 2021 9:04 pm I used the Nerdy Nights tutorial to help me implement left/right scrolling. But I didn't see it showing how to make up/down scrolling while vertical mirroring is enabled. At least, I couldn't find information on it
Nerdy Nights scrolling tutorial mainly teaches the very basics of scrolling horizontally, including splitting the screen using sprite 0. The sound tutorial is a bit more advanced and teaches some more things how to structure the program better, besides teaching you how to program the APU.

zanto wrote: Sun Apr 11, 2021 9:04 pm I contacted the person that made the map visualizer and they told me that DW2-4 use cartridge RAM starting at $7400 (DW3) or $7800 (DW2/4) to store the map once it's built. So I guess the games store the uncompressed map in those addresses. The exception is DQ2 (J), because apparently it didn't have cartridge RAM, so it used another map system, according to them.
Yeah I'm mainly talking about DQ1 and DQ2 since neither use SRAM at all, and saves progress using long passwords. The DW versions of them introduced SRAM so they could change things around to work more like DQ3. DQ1 also didn't have shore lines or the bottom part of stone wall tiles, so it gets away with a less advanced tiling system. DQ2 has both though and still uses passwords.
User avatar
zanto
Posts: 57
Joined: Sun Mar 07, 2021 11:15 pm
Location: Rio de Janeiro, Brazil

Re: Scrolling RPG maps

Post by zanto »

The reason I said I'd need to update 18 tiles above or below the scroll when moving up or down is that the game always has one extra column of metatiles to the left and to the right of the visible camera.
tokumaru wrote: Mon Apr 12, 2021 4:31 am You don't need to draw 18 metatiles, the screen can show at most 17 at a time. The first metatile should be at scrollX, and the last one at scrollX + 256, that's 17 metatiles.

If I do only 17, then I'd have an extra column to the right of the visible area which helps me scroll the game to the right without showing any glitches to the right of the screen. But what if the player moves to the left? That's why I also created an extra column to the left, so there'd also be a column buffer that would let me scroll to the left without any glitches. Unless I'm missing something...
Pokun wrote: Mon Apr 12, 2021 7:13 am Yeah the camera can only move in one direction at a time no matter what, so no need to waste time drawing tiles on the back end which will be overwritten if you change direction anyway.
Yes, but if you move once below and then once left, when you move right or left, there'll be a part of the nametable on the bottom right or left that won't have a proper metatile drawn properly, since you didn't draw the extra tile?

I came to this conclusion after watching looking at the PPU while moving around in Dragon Warrior 4.

However, I noticed the Final Fantasy games (at least 1 and 3) do it differently. They don't have the extra metatile columns to the left or to the right of the visible area. When you have the character move left or right, on the first frame the character turns to that direction and nothing happens. Then, on the second frame the column is drawn left or right of the visible screen (with the correct attributes!) and the character starts moving. It also load the entire metatile column (so, 2 tile columns).

If it's possible to do what FF did, it makes me wonder why the DW games have this column buffer to the left and right of the visible screen. I wonder if it's something related to how quickly you can calculate those columns to the left or the right...


Pokun wrote: Mon Apr 12, 2021 7:13 am Yeah I'm mainly talking about DQ1 and DQ2 since neither use SRAM at all, and saves progress using long passwords. The DW versions of them introduced SRAM so they could change things around to work more like DQ3. DQ1 also didn't have shore lines or the bottom part of stone wall tiles, so it gets away with a less advanced tiling system. DQ2 has both though and still uses passwords.
This makes me wonder about RAM consumption... a map that is like 512x480 would take 960 bytes of RAM, if I calculated it correctly. That's a lot of RAM, isn't it?
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Scrolling RPG maps

Post by Pokun »

zanto wrote: Mon Apr 12, 2021 2:41 pm The reason I said I'd need to update 18 tiles above or below the scroll when moving up or down is that the game always has one extra column of metatiles to the left and to the right of the visible camera.
Well if it's outside the visible screen it isn't visible, is it?
The screen is 256x240 dot: 256 / 16 = 16, and 240 / 16 = 15, so that's 16 metatile columns to update when scrolling vertically and 15 metatile rows when scrolling horizontally. I don't get where 17 and 18 metatiles comes from. If you scroll diagonally you of course need to update 16 + 15 = 31 metatiles, +1 in the corner. Unless I'm the one missing something (as I've said before I haven't tried any 4- or 8-way scrolling in practice yet).

If I do only 17, then I'd have an extra column to the right of the visible area which helps me scroll the game to the right without showing any glitches to the right of the screen. But what if the player moves to the left? That's why I also created an extra column to the left, so there'd also be a column buffer that would let me scroll to the left without any glitches. Unless I'm missing something...
Why? If you always sweep the metatiles in front of the viewport no matter what direction it goes in, the metatiles should always be correct when they come into view, no? Metatiles are the same size as the attribute grid so it should always be correct ...I think.

DW4 and FF1 works identically as far as I see it. I only checked the PPU viewer in Mesen, but all DQ and FF games uses vertical mirroring and only draws the 16 or 15 metatiles directly in front of the viewport. If scrolling west or east, it looks like it draws on all rows on both top and bottom nametable, but that is due to the vertical mirroring.

This makes me wonder about RAM consumption... a map that is like 512x480 would take 960 bytes of RAM, if I calculated it correctly. That's a lot of RAM, isn't it?
Yeah that's what I've been saying! It seems to use some more clever programming to get around the lack of RAM. I know that DQ1 does some weird stuff, like checking the hero's coordinate to check if he stands on a chest, and which chest, if he performs the search command. They changed around the chests and forgot about one of them, so it can only be opened from a tile that looks empty.
User avatar
zanto
Posts: 57
Joined: Sun Mar 07, 2021 11:15 pm
Location: Rio de Janeiro, Brazil

Re: Scrolling RPG maps

Post by zanto »

I recorded two videos showing what appears in the PPU viewer when the player walks in DW3 and FF3.

Here's FF3. All the areas updated in the nametable are areas that are visible inside the scroll by the time the player is done moving:
https://www.youtube.com/watch?v=h0wCAq5Q7Fw


Now here's DW3. Notice how the columns to the right and left of the scroll are also updated even though they aren't inside the visible area after the player is done moving? In particular, when the player moves down, it updates not only the bottom 16 metatiles that get displayed, but also 1 metatile to the left and 1 to the right.
https://www.youtube.com/watch?v=tPyFAT1Pnso

At first, I was only looking at DW games, so that's why I thought I HAD to update the nametables like that, but when I saw FF did it differently, I'm not sure anymore. I don't know why those games do it differently.
Last edited by zanto on Tue Apr 13, 2021 7:22 am, edited 1 time in total.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Scrolling RPG maps

Post by Pokun »

You are right, I'm not sure why I missed that before.
Aha I think I understand why it updates 18 metatiles instead of 16 and why FF gets away by not doing it.

The following example I only update the 16 metatiles directly in front of the viewport every step.

Code: Select all

box = viewport (nevermind the resolution)
*   = correctly written metatile
?   = undefined metatile

Start:
???**********????
??*+--------+*???
??*|********|*???
??*|********|*???
??*+--------+*???
???**********????


After moving east 1 metatile:
??**********?????
?**+--------+*???
?**|********|*???
?**|********|*???
?**+--------+*???
??**********?????    <-- an undefined tile creeping in!


After moving east 8 metatiles:
****?????????????
***+--------+*???
***|********|*???
***|********|*???
***+--------+*???
****?????????????    <-- 8 more undefined tiles!
At start I have all adjacent tiles around the viewport correctly defined so that you can move in any direction without encountering an undefined tile.
But if moving east (or any direction) 1 step and only updating 16 tiles, the adjacent rows to the north and south both have an undefined tile. Moving 8 more steps and there are now 8 more undefined tiles at top and bottom. If you move either north or south now, you will have 9 undefined tiles coming into view, but no more after that if you continue to move, as the tile updating happens after moving a step.


But if you do like DQ and update two more tiles at both ends, this undefined tile should never creep up on you.

Code: Select all

Start:
??************???
??*+--------+*???
??*|********|*???
??*|********|*???
??*+--------+*???
??************???


After moving east 1 metatile:
?*************???
?**+--------+*???
?**|********|*???
?**|********|*???
?**+--------+*???
?*************???    <-- no undefined tiles are coming near!
Here I made sure that all adjacent tiles are defined including the corners.
Then when moving forward with are updating an extra tile on both ends, the adjacent bottom and top rows are always defined.

It should only be a problem for going north and south (though my example shows it for east) due to vertical mirroring.


I guess Final Fantasy games instead updates the adjacent tiles in front BEFORE moving a step instead of AFTER like DQ, so it only needs to update the visible row. FF seems more efficient, but on the other hand DQ doesn't need to update all tiles in a single frame as it updates the next step's tiles after taking the step instead of this step's tiles before taking the step like FF. DQ1 indeed seems to only update a few tiles a frame, not all at once.

An interesting and important point that I didn't think about. I'm only guessing though.
Post Reply