Parallax: Design of the system

Principles and assumptions

Storage principles

• Each unique parallax pattern is stored in ROM in once only.

Design principles

• We aim to use simple blocks and simple masks to increase the possibility reusing patterns.

VRAM principles

• We design a game where we use limited sprites for the gameplay.
• We devote lots of sprite storage for the parallax.
• We split the screen in two, where upper and lower part has their own PAT. This should reduce the work involved to maintain PATs which always has the required patterns.
• We keep one SAT only.

Performance assumption

• It is assumed that, the more available PATs, the lesser chance of having to update the PAT for the next frame. And if you have to, the more PATs you have, the more up front frames you have to smooth out PAT VRAM updates over.

Numbers

• We settle on these 32 entries in the SAT:
• 6 for gameplay (2 for player, 3 coins, 1 for dust trail and player crash)
• 13 for upper parallax
• 13 for lower parallax

Parallax sprite definition per level

Below, normal tiles are made semi transparent and we have a white helper rectangle to indicate a full screen:

• Numbers on top: Upper 13 parts are numbered 0-12 and lower 13 are 13-25. The color is a "class" in Tiled and we use it to define which color definition a sprite should use.
• In this example, we have a max of 4 parallax sprites on a line. Then add 2 for the character, 1 for a dust trail, and 1 for a coin = 8.
• The white 5 indicates where the screen splits.

VRAM - upper 64 kB is used for PATs only

• Both upper and lower part each get 16 PATs. Each of these PATs will be called a Group PAT.
• One PAT for each frame. It rotates. This means:
• Gameplay patterns (player, coin, dust, must be present in every PAT)
• Player patterns are plain copies, but dust animation pattern can alternate in the various PATs and animation for this sprite comes for free.
• Gameplay patterns takes up 16, so there is 48 left for parallax.
• Changing the active/visible PAT in the VDP and is basically free.
• Why 16?
• 16 is the amount of frames it takes for a full cycle of moving one tile past one parallax sprite.
• I tried with lower amounts of "slots" first, but 16 slots proved to reduce the final PAT update peak cycle usage.

From this, we expect:

• At frame 0:
• Set initial SAT.
• Set initial sprites' color definitions.
• Patterns needed in frame 0-15 is "uploaded" into the 32 PATs.
• For any frame after this, we will do:
• Updates to SAT via a data stream.
• Updates to PATs via a data stream.

Various things done to improve the performance & storage

• Lonely transparent pixels in the tiles were often made opaque to somewhat reduce the amount of different patterns, which in turn reduced the amount of PAT updates at runtime. Examples: Corners or space between blocks (blue background color).

• Vertical movement of the parallax is disabled in final version as this reduced the amount of data, without degrading the experience too much.

Continue your reading via the links in the footer below.

The parallax effect  |  Design of the system  |  The masker tool  |  In-game data consumption and rendering