Why does having a bigger tilemap matter?

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

Re: Why does having a bigger tilemap matter?

Post by iNCEPTIONAL »

Pokun wrote: Fri Jul 15, 2022 3:21 pm
Myself086 wrote: Fri Jul 15, 2022 2:03 pm You don't need to do scrolling updates on the exact frame, you can delay low priority tasks when the CPU is too busy. Having a large 512x256 pixel layer allows you to have a lot of tiles prepared in advance. This applies to updating the tilemap as well as the tileset while the level progresses.
Oh I see, with a larger tilemap you can have a larger margin to the scroll seam so that the new tiles will appear later and you therefore have more time to upload new tiles to the tileset or to do other things, like decompressing data or calculating what tiles should appear etc. Tilemap updates can also be spread out over several frames to save more time for other things.

As a summary, you can basically have a wider scroll seam with a larger tilemap which gives more time to do more things.
So a larger tilemap is a good thing after all.
So, any examples of where a full screen width of tiles offscreen is not going to be enough time to update whatever you want to update before the new part of the level appears onscreen then?

And, how is that affected when you can have the on-paper max of 4096 unique tiles [in Mode 0] already in VRAM vs the on-paper max of 2048 in the other case?

I'm asking about Mode 0 because that's the mode I'm using and therefore I have far more tiles able to be already loaded into VRAM to begin with than is the case in the other examples.

Am I actually in danger of running out of time to update what I need to update in a typical shmup?
Last edited by iNCEPTIONAL on Fri Jul 15, 2022 4:10 pm, edited 1 time in total.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Why does having a bigger tilemap matter?

Post by Pokun »

I have no idea of any examples, but it's easy to think that when a game is very busy and has much to do (maybe there are a lot of enemies and lasers on screen that must all be processed before it's time to draw the next frame) it may suffer slowdown or the programmer must make sacrifices to avoid that. If you have a larger off-screen margin you can make more delays to updates of the scroll seam meaning you can save time for all those enemies and lasers that needs to be attended to, because it will be a longer time before the updates comes into the viewport.

I don't understand your second question. It seems unrelated how many tiles you have in the tileset.
iNCEPTIONAL

Re: Why does having a bigger tilemap matter?

Post by iNCEPTIONAL »

Pokun wrote: Fri Jul 15, 2022 4:07 pm I don't understand your second question. It seems unrelated how many tiles you have in the tileset.
Well, I thought part of the time that extra screen is moving into view and you have to update whatever tiles offscreen and so on is used to update the tilemap and put various tiles in whatever place and maybe even swap in new tiles, but, if you already have potentially twice as many tiles in VRAM as any other mode, literally going from typical 2048 to 4096 (max on-paper numbers), surely you could at least avoid having to load new tiles so often and by quite some margin, if even at all with so many unique tiles to play with, which would free up some loading/processing/updating/whatever time in that way, no?

And, unless I'm wrong, isn't the main purpose of this whole extra screen outside the screen to update the tilemap and the like for scrolling, far more so than it being used for extra time to process laser fire or whatever, which is surely done more during the likes of V-Blank, no?

Isn't the main thing to consider with the size of the tilemap the background tiles, not sprites and code for lasers and collisions and the like?
Last edited by iNCEPTIONAL on Fri Jul 15, 2022 4:21 pm, edited 3 times in total.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Why does having a bigger tilemap matter?

Post by psycopathicteen »

Doing the collumns in the BG of Sonic 3 looks a lot easier than doing the bridges. The collumns in Sonic 3 only need 64 frames, and they can be made with 8 versions of the tile map, and 8 versions of the tile set.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Why does having a bigger tilemap matter?

Post by Pokun »

Ah yeah as I think I said you can of course use this extra time to load up new tile data to the tileset. Considering this is more time consuming than switching tiles on the tilemap, having a larger tilemap is probably very beneficial for this.
iNCEPTIONAL

Re: Why does having a bigger tilemap matter?

Post by iNCEPTIONAL »

Pokun wrote: Fri Jul 15, 2022 4:19 pm Ah yeah as I think I said you can of course use this extra time to load up new tile data to the tileset. Considering this is more time consuming than switching tiles on the tilemap, having a larger tilemap is probably very beneficial for this.
And, if you already have 2048 extra unique tiles loaded into VRAM in Mode 0 (on-paper max additional unique tiles over the standard 2048 on-paper max unique tiles in other cases), could that, in some way, compensate for having the smaller tilemap size (including possibly never having to even load new tiles in at all, for example, so much less time taken potentially doing so otherwise)?
Last edited by iNCEPTIONAL on Fri Jul 15, 2022 4:26 pm, edited 1 time in total.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Why does having a bigger tilemap matter?

Post by Pokun »

iNCEPTIONAL wrote: Fri Jul 15, 2022 4:14 pm
Pokun wrote: Fri Jul 15, 2022 4:07 pm I don't understand your second question. It seems unrelated how many tiles you have in the tileset.
And, unless I'm wrong, isn't the main purpose of this whole extra screen outside the screen to update the tilemap and the like for scrolling, far more so than it being used for extra time to process laser fire or whatever, which is surely done more during the likes of V-Blank, no?

Isn't the main thing to consider with the size of the tilemap the background tiles, not sprites and code for lasers and collisions and the like?
No the lasers and collision logic must be done before vblank. You want to reserve the short vblank time only for ordering the PPU to do whatever graphic updates you want for the next frame. These updates are of course dependant on the logic's results, but you want to calculate the logic before vblank happens and do the actual dirty graphic update work during vblank.
iNCEPTIONAL

Re: Why does having a bigger tilemap matter?

Post by iNCEPTIONAL »

Pokun wrote: Fri Jul 15, 2022 4:25 pm
iNCEPTIONAL wrote: Fri Jul 15, 2022 4:14 pm
Pokun wrote: Fri Jul 15, 2022 4:07 pm I don't understand your second question. It seems unrelated how many tiles you have in the tileset.
And, unless I'm wrong, isn't the main purpose of this whole extra screen outside the screen to update the tilemap and the like for scrolling, far more so than it being used for extra time to process laser fire or whatever, which is surely done more during the likes of V-Blank, no?

Isn't the main thing to consider with the size of the tilemap the background tiles, not sprites and code for lasers and collisions and the like?
No the lasers and collision logic must be done before vblank. You want to reserve the short vblank time only for ordering the PPU to do whatever graphic updates you want for the next frame. These updates are of course dependant on the logic's results, but you want to calculate the logic before vblank happens and do the actual dirty graphic update work during vblank.
I thought basically everything that runs in the code is done during either V-Blank (once each frame) or H-Blank (however many times each frame), in between scanlines, or F-Blank if that's being used?

How is that stuff related to how big the tilemap is vs maybe the blank time that apparently also happens offscreen to the left and right for a moment too?

I might be getting this all wrong but that's kinda how I remember Retro Game Mechanics explaining it, where there's also some time as the beam goes off the screen to the right and a little before the screen to the left, but I never recall him saying that size is variable or related to the tilemap size in any way.
Last edited by iNCEPTIONAL on Fri Jul 15, 2022 4:34 pm, edited 4 times in total.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Why does having a bigger tilemap matter?

Post by Pokun »

iNCEPTIONAL wrote: Fri Jul 15, 2022 4:23 pm
Pokun wrote: Fri Jul 15, 2022 4:19 pm Ah yeah as I think I said you can of course use this extra time to load up new tile data to the tileset. Considering this is more time consuming than switching tiles on the tilemap, having a larger tilemap is probably very beneficial for this.
And, if you already have 2048 extra unique tiles loaded into VRAM in Mode 0 (on-paper max additional unique tiles over the standard 2048 on-paper max unique tiles in other cases), could that, in some way, compensate for having the smaller tilemap size (including possibly never having to even load new tiles in at all, for example, so much less time taken potentially doing so otherwise)?
Ah you mean if having a larger tileset can compensate for not having a larger tilemap?
Yes if you have a larger tileset you have more unique tiles to work with, so you probably don't need to update it as often depending on your game's needs. I'm not really speaking from experience or anything though.
iNCEPTIONAL

Re: Why does having a bigger tilemap matter?

Post by iNCEPTIONAL »

Pokun wrote: Fri Jul 15, 2022 4:29 pm
iNCEPTIONAL wrote: Fri Jul 15, 2022 4:23 pm
Pokun wrote: Fri Jul 15, 2022 4:19 pm Ah yeah as I think I said you can of course use this extra time to load up new tile data to the tileset. Considering this is more time consuming than switching tiles on the tilemap, having a larger tilemap is probably very beneficial for this.
And, if you already have 2048 extra unique tiles loaded into VRAM in Mode 0 (on-paper max additional unique tiles over the standard 2048 on-paper max unique tiles in other cases), could that, in some way, compensate for having the smaller tilemap size (including possibly never having to even load new tiles in at all, for example, so much less time taken potentially doing so otherwise)?
Ah you mean if having a larger tileset can compensate for not having a larger tilemap?
Yes if you have a larger tileset you have more unique tiles to work with, so you probably don't need to update it as often depending on your game's needs. I'm not really speaking from experience or anything though.
Yes, that' what I was meaning.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Why does having a bigger tilemap matter?

Post by Pokun »

iNCEPTIONAL wrote: Fri Jul 15, 2022 4:28 pm
Pokun wrote: Fri Jul 15, 2022 4:25 pm
iNCEPTIONAL wrote: Fri Jul 15, 2022 4:14 pm And, unless I'm wrong, isn't the main purpose of this whole extra screen outside the screen to update the tilemap and the like for scrolling, far more so than it being used for extra time to process laser fire or whatever, which is surely done more during the likes of V-Blank, no?

Isn't the main thing to consider with the size of the tilemap the background tiles, not sprites and code for lasers and collisions and the like?
No the lasers and collision logic must be done before vblank. You want to reserve the short vblank time only for ordering the PPU to do whatever graphic updates you want for the next frame. These updates are of course dependant on the logic's results, but you want to calculate the logic before vblank happens and do the actual dirty graphic update work during vblank.
I thought basically everything that runs in the code around that kind of stuff is done during either V-Blank (once each frame) or H-Blank (however many times each frame), or F-Blank if that's being used?

How is that stuff related to how big the tilemap is vs maybe the blank time that apparently also happens offscreen to the left and right for a moment too?

I might be getting this all wrong but that's kinda how I remember Retro Game Mechanics explaining it.
No not on the NES, SNES and many other systems of the time at least (the Atari 2600 is different though, logic must be done during vblank).
The PPU can only take orders during blanking (vblank, hblank or fblank) because during the active display period (the time when it's not blanking) it's busy telling the TV how to draw the frame and can't listen to the CPU (you). But the CPU can work all the time, so you should use the active display period (which is also once per frame but is much longer than vblank) to do all the planning and calculations, where are the player and enemies, did that laser hit the ship or not and so on, then you save the results in WRAM. When vblank starts all these should ideally be done, or else you will have slowdown because you can't tell the PPU to draw these updates if all the planning for the frame is not finished yet. In vblank you use the results you saved in WRAM so that you can tell the PPU what to draw next frame. It's too late to do any calculations at this point or else your game will not be able to do many graphic updates each frame.

And how is this logic and planning related to tilemap updates outside the screen? Simple, the tilemap updates can also be considered game logic and must also be calculated and saved in WRAM before doing the actual graphic updates by yelling at the PPU. A larger tilemap means we have more frames until the new tiles will come into view so we don't have to finish it in a single frame.
iNCEPTIONAL

Re: Why does having a bigger tilemap matter?

Post by iNCEPTIONAL »

Pokun wrote: Fri Jul 15, 2022 4:47 pm
iNCEPTIONAL wrote: Fri Jul 15, 2022 4:28 pm
Pokun wrote: Fri Jul 15, 2022 4:25 pm
No the lasers and collision logic must be done before vblank. You want to reserve the short vblank time only for ordering the PPU to do whatever graphic updates you want for the next frame. These updates are of course dependant on the logic's results, but you want to calculate the logic before vblank happens and do the actual dirty graphic update work during vblank.
I thought basically everything that runs in the code around that kind of stuff is done during either V-Blank (once each frame) or H-Blank (however many times each frame), or F-Blank if that's being used?

How is that stuff related to how big the tilemap is vs maybe the blank time that apparently also happens offscreen to the left and right for a moment too?

I might be getting this all wrong but that's kinda how I remember Retro Game Mechanics explaining it.
No not on the NES, SNES and many other systems of the time at least (the Atari 2600 is different though, logic must be done during vblank).
The PPU can only take orders during blanking (vblank, hblank or fblank) because during the active display period (the time when it's not blanking) it's busy telling the TV how to draw the frame and can't listen to the CPU (you). But the CPU can work all the time, so you should use the active display period (which is also once per frame but is much longer than vblank) to do all the planning and calculations, where are the player and enemies, did that laser hit the ship or not and so on, then you save the results in WRAM. When vblank starts all these should ideally be done, or else you will have slowdown because you can't tell the PPU to draw these updates if all the planning for the frame is not finished yet. In vblank you use the results you saved in WRAM so that you can tell the PPU what to draw next frame. It's too late to do any calculations at this point or else your game will not be able to do many graphic updates each frame.

And how is this logic and planning related to tilemap updates outside the screen? Simple, the tilemap updates can also be considered game logic and must also be calculated and saved in WRAM before doing the actual graphic updates by yelling at the PPU. A larger tilemap means we have more frames until the new tiles will come into view so we don't have to finish it in a single frame.
Cool, cool.

I should probably go watch that Retro Game Mechanic Explained video again. Lol
iNCEPTIONAL

Re: Why does having a bigger tilemap matter?

Post by iNCEPTIONAL »

Now, I'm curious, if I have a 64x64 tilemap, could that effectively act as if the extra tilemap area above the screen was just even more tilemap area off the to right of the screen (via whatever coding magic), so still allowing that additional time to do whatever updates and checks and so on?

And, I'm thinking about it specifically in the scenario where the game is only scrolling horizontally like in my shmup and never actually scrolling vertically.

Like, we've established having a larger tilemap can have a benefit when having to update tiles, load in new tiles, and even ready the code to be run during V-Blank and such, but does that extra tilemap area necessarily have to be in the direction you're just about to scroll vs just anywhere around the screen (not that I honestly think most games are ever going to run out of time normally with just one extra screen to the right to do whatever, so I honestly don't think this is something that really needs to be seriously worried about anyway, but just curious)?

I hope that makes sense.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Why does having a bigger tilemap matter?

Post by dougeff »

No.

If you only scroll horizontally, there is no benefit to having a taller tile map
nesdoug.com -- blog/tutorial on programming for the NES
TrekkiesUnite118
Posts: 92
Joined: Fri Mar 08, 2013 5:56 pm

Re: Why does having a bigger tilemap matter?

Post by TrekkiesUnite118 »

psycopathicteen wrote: Fri Jul 15, 2022 4:16 pm Doing the collumns in the BG of Sonic 3 looks a lot easier than doing the bridges. The collumns in Sonic 3 only need 64 frames, and they can be made with 8 versions of the tile map, and 8 versions of the tile set.
Well when you really look at the bridges and the buildings they overlap, the windows, grid between the windows, and the cables on the bridges themselves are all just single pixels. So you could probably get away with using some palette trickery to significantly reduce the amount of unique frames and tiles necessary. The low color depth could allow you to set something up where you have multiple frames in one tile and you cycle through palettes to get different frames of animation. While the 2BPP limit of Mode 0 wouldn't be as feasible for this, being in 4BPP color or higher could make this more workable. Also certain parts of the bridge wouldn't have to be animated as you could just get away with moving those parts with line scrolling. So it would really just need to be the parts of the cables/pillars that overlap with the buildings that would need to be updated.
Locked