Display List Interrupt Demo

[Mr SQL]

I've been working with DLI's on the Atari 8-bit/5200 - a fascinating and powerful technology for doing really cool things with the display!

 

I have decided to add them to the next release of Virtual World BASIC for the 2600!

 

Here's a BASIC Display List Interrupt Demo for the Atari 2600, the program listing and the DLI chapter from the manual to discuss.

DLI_Demo4.bin Display_List_Interrupt_demo4.txt

The BASIC DLI demo is only 20 lines of code, easy to review (I reused code from 9LineBlitz).

 

Note: This DLI code won't compile until the next version of vwB is released (soon, along with other enhancements).

 

Draft of the new chapter on DLI's:

Display List Interrupts
-------------------------------
Display list interrupts run during the vertical blank and provide the ability to split the screen up into multiple horizontal sections, each of which can contain a vertically, horizontally or diagonally scrolling playfield with free floating or tile-mapped sprites.

 

The DLI demo program (DLI_Demo.txt) demonstrates setting up display lists to scroll the top half of the screen vertically while scrolling the bottom half of the screen horizontally at different speeds.

 

The demo actually uses 4 DLI calls to do this but arranges them to create two contiguous scroll zones.

Syntax for calling the DLI is simple: "gosub DLI"
two rows (1/5) of the screen will be updated based on the value you store in scrollvirtualworldtoggle (it's reused for DLI's; just don't use zero).

 

Put in an 8, and the bottom two rows of the screen will be updated:
100 scrollvirtualworldtoggle=8:gosub DLI:scrollvirtualworldtoggle=0: rem call DLI, update tile rows 9 and 10.

 

Put in a 1 and rows 2 and 3 will be updated near the top of the screen:
100 scrollvirtualworldtoggle=1:gosub DLI:scrollvirtualworldtoggle=0: rem call DLI, update tile rows 2 and 3.

 

Trick to span three rows (about 1/3 of the screen) - use "3" as a prefix before the start row.

Put in a 37 and the bottom three rows of the screen will be updated:

100 scrollvirtualworldtoggle=37:gosub DLI:scrollvirtualworldtoggle=0: rem call DLI, update tile rows 8,9 and 10.

 

Put in a 30 and the top 3 rows will be updated.
100 scrollvirtualworldtoggle=30:gosub DLI:scrollvirtualworldtoggle=0: rem call DLI, update tile rows 1,2 and 3.

It's no more complex than setting the x,y coordinates for the playfield camera to pan the view about the virtual world, you're just able to do that independantly for each section of the screen you define with a DLI!

 

You can call a DLI from each gameloop with different camerea settings; each game loop runs on one of the vertical blanks so one of your DLI calls will happen "before" (called from the top blank) the display is drawn and one will happen after the display is drawn, the one called from the bottom blank (gameloop2).

 

DLI Overhead:

3 row DLI's will occuply nearly the entire top blank, and cannot fit in the bottom blank while 2 row DLI's leave plenty of space for your own program code.

 

Just like raising an event to scroll the entire screen, A DLI need be called only as frequently as you need to update it's target section of the screen (pan the camera).

 

Exercises for setting up multiple DLI's and setting their animation rates:

 

1. Increase the scrolling speed of the top half of the screen to match the bottom, so they are both animated at 30 FPS (every other frame).

2. Change the demo to show three visible scroll zones; try to set up two zones scrolling horizontally in opposite directions or at different speeds, while the third "larger" zone (comprised of two zones) scrolls vertically or diagonally.

 

Edited April 26, 2016 by Mr SQL

[Mr SQL]

Here's another DLI demo, three scroll zones with color attributes:

 

DLI_Demo5.bin

 

[maiki]

What exactly are those "tile-mapped" sprites?

[Mr SQL]

What exactly are those "tile-mapped" sprites?

 

Great question maiki! Tile mapped sprites are precisely bound to tile coordinates, though usually smoothly animated with smaller steps between them.

 

You don't need a large virtual world for tile-mapping, any game where character movement appears deliniated along a character sized grid pattern like KC on the 7800 or MS Pacman on the 2600 is a good example; the characters smoothly animate from tile to tile but you can only make precise turns (no turning between tiles).

 

Tile mapping is particularly advantageous with a virtual world because you can simply pan the camera around and all of the relative positioning is adjusted.

 

vwBASIC lets you tile map sprites with a single command, vwpixel; it let's you set tile pixels anywhere on the screen like bB's pfpixel, but extends to the large Virtual World and has the option to bind the spites to the tile pixels:

 

vwpixel(30,3,bindplayer1)

 

Here's an example of the DLI demo illustrating this command adding a tile mapped sprite on top of the Atari 2600 text:

 

DLI_Demo_plus_tilemapping.bin

[maiki]

Oh, so basically a standard method of storing sprites in a grid of usually 8x8 pixels squares right? I was rather thinking about some sort of drawing objects into tilemap...

[Mr SQL]

Oh, so basically a standard method of storing sprites in a grid of usually 8x8 pixels squares right? I was rather thinking about some sort of drawing objects into tilemap...

Yes. Drawing objects on the tilemap with playfield graphics is another interesting aspect. Tiles in vwB have only two sub playfield pixels so you can't draw much on the tiles though it is a usefull effect. BoulderDash uses larger tiles that are four playfield pixels (16 pixels) accross to allow character objects to be drawn on the tiles.

[Sprybug]

This is great stuff here. Could you post the BASIC source code of DLI_Demo_plus_tilemapping.bin?

 

I'd love to check it out.

[Mr SQL]

This is great stuff here. Could you post the BASIC source code of DLI_Demo_plus_tilemapping.bin?

 

I'd love to check it out.

 

Thanks! Here is the source:

 

Display_List_Interrupt_demo5.txt

[unbibium]

This looks like it would be useful for parallax scrolling, with each region being a different color. Or, having a different window for the left and right player.

 

though, to nit-pick a bit, on the Atari 8-bit this can be done with an ordinary display list, and not an interrupt. You can reset the memory reading origin at any line.