In a game like "The Legend of Zelda", it's probably pretty straight forward: Since the game only uses screen-by-screen scrolling, the screen graphics buildup function probably also fills an independent 16 x 11 byte array that has the data of the playfield. And when the characters move, they check their x and y position against this array to check whether they can walk or whether they reach a wall.
So, in this case, it doesn't even matter how the screen data is stored in ROM. The checks during live gameplay go against a small and simple array.
If you had a huge amount of space, the same would also work with scrolling levels: For a level that's 20 screens wide, just declare a 320 x 15 array in ROM and put all the background object IDs there. Use this same array for graphics buildup and for game logic alike: You can use these IDs to check in another array what graphics to load. And in yet another array whether this object is walkable. Divide the character's x and y position by 16 and you get to the exact place in the array where your character is standing.
But what if the level structure is compressed? How is the immediate walkability of a certain point on the screen determined?
Take for example "Castlevania": I doubt that the structure of a level is stored as one huge, uncompressed 1:1 representation.
So, how does the game store its immediate on-screen level status?
Does this game have an 18 x 11 array in RAM, i.e. two blocks wider than the screen? And every time the game scrolls by 16 pixels to the right, then all values in all the rows of the array are shifted to the left, with the last columns being filled with new data from ROM?
Code: Select all
ABCDEFGHIJKLMNOPQR BCDEFGHIJKLMNOPQRS
ABCDEFGHIJKLMNOPQR --> BCDEFGHIJKLMNOPQRS
ABCDEFGHIJKLMNOPQR BCDEFGHIJKLMNOPQRS
And just think of four way scrolling. You would need an array that's slightly bigger than the horizontal and vertical size of the screen. And you would have to shift data horizontally and vertically whenever the player character moves.
That's surely easily possible on a PC game. But is this also the way NES games do this? To me, that's a huge performance eater, having an array that's more than 255 bytes big and also having to constantly shift data around. How do professional games, like "Crystalis", handle this?