Video Modes

From Uzebox Wiki
Revision as of 15:00, 9 December 2017 by Jubatian (talk | contribs) (Made a hopefully better description for Mode 3)
Jump to navigation Jump to search

The Uzebox has several video modes, here you can browse those which are the most useful for designing games

Mode 1

Alt text
Mode 1 Example - Megatris
  • The mode used in the original kernel (i.e: used for Megatris)
  • 240x224 resolution
    • 6 or 8 pixels wide tiles
    • Configurable tile height
  • Allows more than 256 unique tiles on screen by using 16 bit vram array (each entry is a direct memory pointer to a tile in flash)
  • no scrolling
  • no sprites
  • CPU cycles left: high
  • RAM consumption: medium
  • Program memory consumption: very low

See also

Mode 2

Alt text
Mode 2 Example - Zombienator
  • 144x224 resolution, 6x8 pixels tiles, 32x32 vram
  • 8 bit vram array, each entry is an index into a 256 tiles table
  • full screen scrolling
  • multiples screen sections with independent scrolling, height, sprite priority and tile memory
  • maximum 32 sprites at once, 6x8 pixels, up to 5 per scanline. No sprites flipping. (though now vertical flipping will be possible)
  • Sprites blitting independent of background offset
  • CPU cycles left: low
  • RAM consumption: medium-high
  • Program memory consumption: high due to unrolled loops (low if horizontal scrolling not required)

See Also

Mode 3

This is the most often used video mode on the Uzebox, recommended for colorful games which don't need too many sprites.

Alt text
Mode 3 Example - Super Mario demo
Alt text
Mode 3 Example - Donkey Kong
  • Up to 240x224 or 256x224 resolution, 8x8 pixels tiles, up to 32x32 vram
  • 8 bit vram array, each entry is an index into a 256 tiles table (ROM + RAM tiles)
  • Full screen scrolling
  • 1 scrolling main section and 1 static overlay section for scores, etc.
  • Configurable number of sprites, sprites can be flipped on the X/Y axis and can be overlaid on other sprites.
  • CPU cycles left: lowest (Depends on sprite count)
  • RAM consumption: high
  • Program memory consumption: medium

This mode's sprites are realized by RAM tiles, which means that tiles which need to contain sprite material are copied into RAM, and the sprite part is drawn over. This is done outside the video frame, taking away CPU time otherwise used for game logic. One RAM tile takes 64 bytes, for a free-moving 8x8 sprite 4 RAM tiles are needed (256 bytes), for a 16x16 aggregated sprite, 9 RAM tiles (576 bytes), usually 28 - 36 RAM tiles can be made available in typical games. For managing the sprites efficiently see the Sprites Techniques for Mode 3 guide.

Note that most other modes (apart from Mode 2) use the same method for rendering sprites, so the techniques described for Mode 3 also apply to those.

See also

Mode 5

Alt text
Mode 5 Example - Chess4uzebox
  • Based on Mode 1, but using 8-bit indexes to save RAM
  • 240x224 resolution, 6x8 pixels tiles, 40x28 vram
  • 8 bit vram array, each entry is a index to a tile table (maximum 256 unique tiles on screen)
  • no scrolling
  • no sprites
  • CPU cycles left: high
  • RAM consumption: low
  • Program memory consumption: very low

Mode 6

Alt text
Mode 6 Example - Vector Demo

Monochrome 1bpp ramtile-only video mode.

  • Submodes: 240x224 (30x28 ramtiles) or 288x224 (36x28 ramtiles)
  • Supports up to 256 ramtiles
  • Foreground/Background colors can be changed per scanline in 240x224 submode
  • Optimized point and lines functions
  • CPU cycles left: low
  • RAM consumption: medium
  • Program memory consumption: medium

Mode 8

Alt text
Mode 8 Example: Bitmap Demo
  • 120x96 bitmapped mode
  • 4 colors per pixel (2 bits per pixel)
  • Global 4 color palette out of 256 colors
  • no scrolling
  • no sprites
  • CPU cycles left: high
  • RAM consumption: medium
  • Program memory consumption: very low

Mode 9

Alt text
Mode 9 Example: Uze Snakes

Video mode 9 uses tiles that are actually compiled into AVR assembly ("code tiles"). It provides the highest resolution on the Uzebox. Sub mode "80" is useful for 80x25 text display.

  • no scrolling
  • no sprites
  • CPU cycles left: high
  • RAM consumption: low
  • Program memory consumption: very high (depending on tile count)
  • Sub mode "60": 360x240, 60x28 tiles, 6x8 pixels tiles, 256 colors per pixel
  • Sub mode "80": 480x240, 80x28 tiles, 6x8 pixels tiles, 2 colors per pixel

Video Mode 9 Implementation Details

Mode 90

These are two variants (Mode 90 and Mode 92) of Mode 9's Sub mode "60", offering much smaller code tiles (112 bytes / tile) along with other features.

  • no scrolling
  • no sprites
  • CPU cycles left: high
  • RAM consumption: low
  • Program memory consumption: high (depending on tile count)
  • 16 color RAM palette with palette splits
  • Mode 92: 2bpp double scanned 120 pixels wide graphics mode support on the top with arbitrary split

See the documentation within [videoMode90core.s] for details on usage. Tileset assembly files can be generated using the [program] provided along with the video mode. Video mode 92 is almost fully compatible with Video mode 90, except that it has a fixed tile height of 8 pixels.

Mode 13 WIP

There is currently a work in progress for mode 13 paletted mode. It will be quite similar to video mode 3:

  • 8x8 tiles for flash and ram tiles, 32 bytes each in size
  • full screen scrolling
  • screen overlay
  • global palette of either 8 or 15 colours

Video Mode 13 Implementation Details

Mode 40

Mode 40 example
Mode 40 Example

Attribute mode which could be used to reproduce the text modes of various old 8 / 16 bit machines such as the Commodore Plus4 or the CGA text mode of the IBM PC.

  • Up to 44 tiles wide, 28 tiles tall (normally 40 x 25)
  • 8x8 pixel tiles, ROM based (2 KBytes / tileset)
  • Foreground and Background color for each tile can be selected
  • Tileset can be selected for every row
  • Optional row modes: 1bpp (4x4 pixel / tile) or 3bpp (2x4 pixel / tile) graphics
  • Colored border (optional)
  • No sprites
  • No scrolling
  • CPU cycles left: High (no video mode related task in VBlank)
  • RAM consumption: High (3 bytes / tile)
  • Program memory consumption: Very low

Read the Mode 40 guide for more information, you may also check the [example program] to begin using it right away.

Mode 74

Mode 74 example
Mode 74 Example: Sprite engine demo

Paletted (4 bits per pixel) mode at 7 cycles per pixel (1,5:1 pixel aspect ratio, slightly wider pixels than in Video mode 3).

  • Up to 192 pixels width (7 cycles per pixel; 24 tiles at 8 pixels per tile)
  • X and Y scrolling
  • Arbitrary (vertical) split screen regions
  • 8x8 pixel tiles
  • Normally 192 4 bits per pixel ROM tiles + (up to) 64 4 bits per pixel RAM tiles
  • Each tile row's VRAM address and display mode is individually configurable
  • Further row modes include 1 bit per pixel and 2 bit per pixel modes ("Multicolor")
  • Sprite engine supports X and Y flipping, background priority (by masks) and recoloring
  • The 16 color palette supports palette effects
  • Loading random access data from SD card is possible during spare HSync time
  • CPU cycles left: Depends on number of sprites used, may need lower vertical sizes for utilizing all RAM tiles
  • RAM consumption: A 256 byte buffer is required for the palette, a RAM tile takes 32 bytes (half of Mode 3's respective consumption)
  • Program memory consumption: Low to medium depending on required features (however ROM tiles for this mode are smaller than for Mode 3)

Mode 74 Quickstart, a short guide on how to start working with this video mode.

SPI RAM video modes

The video modes on the following page are only useful if your Uzebox has the 128 Kbyte SPI RAM extension.

SPI RAM video modes

Special purpose modes

These are video modes which have special purposes, not necessarily useful for common games. You may check them out if the more common modes don't seem to serve your demands, one of these could be what you need!

Special purpose modes

Experimental & Non-game modes

On the following page some more obscure video modes are described, they may be useful for certain specific purposes, but they are either less useful for common games or might be untested or unfinished.

Experimental and Non-game modes

Additional Information

How Video Modes Work