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?Pokun wrote: ↑Fri Jul 15, 2022 3:21 pmOh 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.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.
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.
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?