Commander X16

@ZeroByte recommended I start playing with tiles by writing a BASIC program.  Which turns out to be a pretty good idea!

I also dug into my Rogue Forest code, which uses Layer 0 to emulate a fog of war situation.

Et voila', my first scrolling code.

I need to either find or write a bmp->tiles utility because this gave me an idea for a funny X16 port of an old meme from YTMND.

 

So, these scroll registers are the horizontal and vertical pixel offsets.  If I use a 32 x 32 map of sixteen bit tiles, then the effective horiz and vert offset values run from 0 to 511.

Now the ACTUAL map will be superhuge.  I keep track of that in code.

As the offset shifts towards the edge of the viewport, I set the VERA address to point ahead a row (or column) and write that data to the map.  The target address is modded based on the dimensions of the map data in VERA.

Easy to say.  Trickier to conceptualize in code.

If you are lucky a map size of 128x256 or 256x128 is enough. VERA supports it and it will fit into VRAM (64 KB). If you want a larger map I think you have to do what I have done in Rally Speedway, start with tiles, then define blocks of tiles of a certain size and finally define your game world with a map of blocks. Then while scrolling you constantly calculate which actual tiles should populate the actual VERA map. By doing this I have implemented virtual maps (or what to call them) consisting of 256x256 tiles. Pretty cool but the code is complicated as well as the workflow for creating graphics.  

Thanks @Johan Kårlin, it's the larger-map case, where I have to populate just beyond of the viewport coordinates, populating rows or columns from the larger map in Banked RAM.

"Viewport coordinates" seems like the appropriate term for what VERA calls the horizontal and vertical scroll values.

 

 

I like to call it the "camera"

And one thing to point out in case you missed it - the scroll value itself auto-wraps, so if the map size is 512px wide, you can keep right on incrementing the scroll register. The view just wraps back around again anyway - it doesn't walk off into the void if you say scroll=513.

Next two steps.

(1) Create a temporary map, or at least part of it, at MAP BASE ADDR ($10000).  A 32 x 32 map at 8bpp is 2K bytes, right?  So the map runs from $10000 to $10800.

(2) Make some tiles and load them to TILE BASE ADDR.  (I can probably set the base addr as $11000, right?)

 

 

So I'm getting the tile base and map base all mixed up.

I *THINK* this loads into $11000+ on VERA.  Yes?

Here's where I think my errors are. I *THINK* this sets the Map Base at $10000, and the Tile Base at $11000.  HOWEVER, the tiles appear random to me, indicating that I either loaded it to the wrong place, or I set the Tile Base wrong.

That works.  At least I'm pretty sure it works.

OK the map entries are two bytes each.  The first byte is the low index of the tile.  Since I only have 8 tiles, that's all I need to set.

The second byte sets the palette offset, flips, and upper index to zero.

I have set the auto increment to 1.  So, that loop fills the map from $10000 to $10400.  Right?

Maybe I'm setting the target address wrong?  But it seems OK.

And we scroll.

So it scrolls, but.... but I'm either loading the tiles to the wrong address, or the map address is wrong, or the tile address is wrong.  Or something else is wrong.



 

To load into bank 1 of VERA, 

VLOAD"LANDTILES.BIN",8,3,$1000

should work better. 8,1,$1000 would load it into low RAM at address $1000.

Thanks.  Anyway I started moving things around.

I've pre-generated a map that I can load directly into VERA, that only has tile indexes 0-8 (randomly), and the second byte is always zero since I'm not offsetting the palette, flipping, or etc.

Can I load these into bank 0?  Would that work?

This doesn't work:

 

Figuring out these VERA fields in BASIC is a royal pain.