The screen 5 scroll

This part covers the basic bitmap scroll in Go Figure (as can be seen here). Note: The parallax effect is a separate topic.


Technical features and setup

Background

  • I had not seen any released games on MSX2 with 50 or 60 FPS smooth fullscreen horisontal scrolling, so I thought I'd give it a try.
  • As an old fan of Geometry Dash, I had been pondering about various ways to get that kind of game to the MSX.
    • I would need speed.
    • I would want bitmap mode.
    • I ditched the idea of vertical movement—an integral part of the original. Not needed, I thought. "No way it can be done with this approach anyway". *
  • Yet another PoC.

The scroll is

  • Bitmap mode, screen 5, 16 colors, palette mode, sprites on.
  • 60 FPS (60 Hz / NTSC).
  • Not using MSX2+ horizontal scroll feature.
  • Speed: 2 px/frame.
  • Almost fullscreen: 256x176 (horisontally 240 px for tiles + 16 px in total for black borders left and right side).
  • Using:
    • 16 x 16 px tiles.
    • 16-32 kB (1-2 pages) for tilesets.
  • Not very flexible. It goes towards right at constant speed only.
  • Supporting diagonal up/down scroll*.

Benefitting from these technical features

  • Set adjust (R#18) for horisontal movement.
  • VDP copy command "HMMV".
  • VDP fillrect command "HMMM".
  • VDP writes via "OUT/OUTI" - setting VRAM bytes directly.
  • Unrolling OUT/OUTIs.
  • Vertical movement uses VDP screen hard scroll (R#23)
  • CPU and VDP used in parallell.
  • Large buffers with pre-calculated VRAM addressing ("LUT").
  • ~64 kB VRAM - two pages, of using ~32kB (double buffering).
  • Screen 5 holds 2 pixels in each byte (⇒2 px is faster than 1 px).

Benefitting from these additional technical features - not 100% required

  • Setting aside some room for scoreboard reduces the amount of pixels to scroll: 16 px vertical block.
  • Line interrupt around line 16 makes a page split and upper part is static, and the scroll happens in the bottom part.
  • Memory mapper - used in the page where tile gfx are stored. Go Figure supports 2 x 16kB tilesets per level.

What makes this difficult on the MSX2 platform and drawbacks

  • VDP is very slow (only ~x bytes possible to move in a frame).
  • There is no interrupt of callback from the VDP when a copy command is finished.
  • Performance degradation in VDP commands when we do CPU in parallell (luckily its not massive).
  • Writing to sequential VRAM addresses, i.e. horisontally, works at decent speeds as the VRAM pointer increases by one for each write. Writing vertically on the other hand, has no such built in support (unless you use the VDP command - which is something else)

Memory setup

I would love to use the NEO-mapper here and get ROM in page 0 as well. Not for Go Figure, but maybe another time.

Tiles

A tilemap example from the game:


The last tile, the "X" (tile #127) is not copied into RAM. One tile is 16*16/2 = 128 bytes, and we use this reduced space to avoid placing data at the start of page 0 where there is an interrupt hook. For tile ids greater in the range 128-255, we swap to a secondary segment in page 0 using memory mapper.

In memory, a tile is rotated and flipped to speed up reading:

Levels

Created in Tiled:



In memory, the level is "flattened", with only 11 tiles height, always. Like this:
A level's tile memory size ends up ~ 9 kB. It's duration is around 90 seconds.

Numbers

  • Any Z80 cycles mentioned on this page are MSX Z80 cycles.
  • If cycles are mentioned to cost, example: 9328/9856 cycles, the first number refers to a normal VDP, and the second refers to a VDP with +1 wait cycle.

* this was the original plan. But reality came along and squeezed in some vertical movement too. Covered in in the last part.

Check out the details on the next two pages.


Comments

Post a Comment