Shiru wrote:
With single screen game you can just unpack level from metatiles or anything in RAM buffer as simple tile/collision map, and have simple collision code, that's what I meant.
I see. Well, in scrolling games you can use the same type of progressive updates you use for the name tables with the collision data, it's basically the same principle.
Personally, I prefer to access level data directly from ROM, using compression schemes that allow random access.
Let me try to classify all the important parts of a scrolling game, the ones that might differ from single-screen games.
First there's the scrolling engine itself, which handles the rendering of the background:
- A "camera" that hovers over the level and decides when it's necessary to draw new rows/columns;
- A method to extract the required rows/columns of tiles and attributes from the level map;
- A method to calculate the target address for the tiles/attributes in VRAM and a procedure to write them there during VBlank;
Then there's the game logic:
- Management of object/enemy (re)spawning based on a sorted list of entities;
- Collisions between objects, which can be done by directly comparing their coordinates (coordinates must have a number of bits compatible with the dimensions of the largest level);
- Collisions between objects and the background, which require access to the level's collision data (can be progressively decompressed or accessed directly from ROM);
And finally there's the sprites:
- Some objects are positioned with absolute coordinates, such as the HUD or anything else that's part of the screen rather than the level;
- Level objects/enemies must have their screen coordinates calculated by subtracting the camera's position from their own;