Thank you, it's really good to have this answer. I like to know these things, because think the best approach is some middle ground between the old ways, and just wasting resources using modern hardware, in case you ever have to push it to the point performance becomes an issue. So in the old days, the VRAM was always a bit bigger than the screen, and in modern 2D engines like Tilengine it's pretty normal to have a giant 2D surface that you scroll around in.
If you were to ever push this size (eg. maybe a mobile game, or a stupidly huge 2D game), then I suppose you could start breaking the level up into chunks using your own methods.
In my Jump n Bump game, each level is only a single screen level, so I didn't have to deal with scrolling yet (but I will for the next projects). But I did it using a graphical surface that is the resolution of the game, scaled to fill the screen, and the level is constructed by blitting the tiles from a tile atlas
And I wrote my own tile based collision. Which collides by rounding pixel locations down to a grid tile location.
If you were to ever push this size (eg. maybe a mobile game, or a stupidly huge 2D game), then I suppose you could start breaking the level up into chunks using your own methods.
In my Jump n Bump game, each level is only a single screen level, so I didn't have to deal with scrolling yet (but I will for the next projects). But I did it using a graphical surface that is the resolution of the game, scaled to fill the screen, and the level is constructed by blitting the tiles from a tile atlas
And I wrote my own tile based collision. Which collides by rounding pixel locations down to a grid tile location.