Skip to content

VERA rendering pipeline is not properly documented #286

Closed

Description

@stople

I would like some documentation regarding how the VERA pipeline works.

Based on what I found regarding sprites in the VERA programming guide, I THINK the order is:

  • Background
  • Layer0
  • Layer1

Sprites can be rendered at these locations:

  • Disabled
  • Between background and layer0
  • Between layer0 and layer1
  • In front of layer1

For sprites within the same location, sprites with its properties at a lower address in ram is rendered on top of sprites with its properties higher in ram.

The background itself, is defined by the "Border Color" (DC_BORDER) register.

Once this is confirmed (or corrected), I think this info belongs somewhere inside the VERA Programmer's reference.

In addition to this, I suggest to document how the different screen modes uses the layers, since users may want to start with a screen mode, and do VERA config on top of it. Not sure where this implementation detail should be documented though. I think this info may be in the same category as the memory map describing HOW the x16 stores data in video ram, and thus, I think these details should be stored the same place.

Activity

  1. stople commented on Feb 18, 2026

    @stople
    ContributorAuthor

    My first explanation seem to be inaccurate. Trying again, with what I found: (TLDR)

    • The display composer draws a border outside the active area of the screen, with the BORDER_COLOR color.
    • The active area of the screen is composed like this:
      • Background (black)
      • Sprite if Z = 1
      • Layer 0 (unless transparent)
      • Sprite if Z = 2
      • Layer 1 (unless transparent)
      • Sprite if Z = 3

    Sprites are first rendered to a line buffer, and there are a limited number of sprites that can be rendered pr line:

    The line budget is 801 pr line.

    • Evaluating a sprite costs 1.
    • Fetching a data block (32 bits) of pixel data from video ram costs 1.
    • Drawing one pixel to the line buffer (transparent or not) costs 1.
      The line can have up to 640 pixels. There are 128 entries in the sprite table.

    While drawing the screen, sprites are written to a line buffer.
    This line buffer stores color, Z and collision info for each pixel.

    The sprite with lowest address is evaluated first.
    If the sprite is on the line, the pixels are evaluated:

    • If pixel is transparent (index 0), ignore (also ignore collision)
    • Write collision mask to the pixel
    • If the pixel already had this mask set (from another sprite), we have a sprite collision
    • If Z index of sprite is higher than the pixel already rendered at this position of the line, update color and Z for this pixel

    The composer evaluates the Z of each sprite pixel of the sprite line buffer, and draws the color at the relevant place.

    Screen mode $80 uses layer1 for 16 color 1bpp text with transparent background, on top of pixel data which uses layer0.

    Screen mode 0 uses layer1 for 16 color 1bpp text with white text on blue background, hiding layer 0 which is disabled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions