Jump to content
rje

Scrolling Land on the X16

Recommended Posts

I'm slowly getting back into sprites, after decades, and I want to have a scrolling 2D top-view coastline (and landscape) using sprites.

You know, like Seven Cities of Gold.  Your ship is in the center, and the land scrolls around it.

I can have 64x64 pixel land tiles... which is cool.  I want to be clever and use an 8 pixel transparent boundary for shoreline; I then overlap the sprites to build up land masses and hide the shorelines.  Ideas attached with blue boundaries; I plan to make these transparent of course.  Alternately, I can have dedicated coastal sprites -- but I worry I'll run out of space.  I've attached a few of those, as well.

If I place an 8 x 8 grid of sprites, then I can have a "play field" size from 384 x 384 to 512 x 512.   (512 is actually probably too big!)

"Scrolling" with sprites can be easy:  I just define a center viewport, draw a thick frame around it, and tile in sprites based on the underlying map.  I use a DX and DY offset for each sprite position to simulate scrolling.

Is there a better way to do it?

 

island desert.png

island grass.png

island savannah.png

land coast e.png

land coast n.png

land coast ne.png

Edited by rje

Share this post


Link to post
Share on other sites

I can have dedicated shoreline sprites, as long as I have enough VERA RAM for all the sprites I want.  My worry is that I want more STUFF than I have RAM for.  Ships, land, flora and fauna, buildings, gangs of tiny little soldiers or brigands or whatever... it all adds up.

-- granted, land is the biggest sprite (4K).  Ships are probably also 4K.  If I manage to get them into 4 bit color, then 2K each.

Plants, animal herds, and barbarian hordes probably don't take as much space.  If they're 32 x 32 or 16 x 16 then maybe I have plenty of space.

I just have to be careful.  

And... It just "seems like a waste of space". XD

 

Edited by rje

Share this post


Link to post
Share on other sites

I still don't understand why you are using sprites for shorelines. You can have tiles on layer 1 with transparent pixels, too. Then you only have to scroll them along with the rest of the tilemap. If you do have sprite overlays, then you can deal with those separately, but I bet the majority of non-animated things can just be tiles.

Share this post


Link to post
Share on other sites
13 minutes ago, rje said:

It's because I don't know what "tiles" are.  ?

Tiles are like text. Actually, strike that; text is just another type of tile.

You can point the VERA's graphics layers to a blob of memory where you've put a bunch of graphics together. It treats the first graphics thing at that location as "tile 0", then expects "tile 1" to follow right after that, then "tile 2", "tile 3", and so on. You don't have to fill all the memory, which is good because most graphics layer settings can use up to 1024 tiles, and that quickly turns into a lot of memory!

As well as pointing the VERA layer to a blob of tiles, you separately point it to a blob of tile indices to draw. For the most part, this is just a long list of all the tiles to display, starting from the top-left corner, then going left-to-right, for each row top-to-bottom.

This is an excellent way to represent repeating patterns of pixels, such as the playfield of a game where the same image is expected to be stamped over and over into different places. Instead of trying to cram a bunch of sprites into a row and dealing with their positions and stuff, just use tiles and a tilemap.

This is also a great way to represent a text console, which is why this is exactly how the VERA does that. The only trick is that since text is generally 1bpp, and there's only a small handful of symbols to define, it changes what data is expects in blob of tile indices, so that it can squeeze a little bit of color data into there. But otherwise, it's exactly the same thing.

Edited by StephenHorn
  • Thanks 1

Share this post


Link to post
Share on other sites

Ah, ok, tiles, got it.  I understand.   Thank you.

And, I think that's how my Rogue Forest game works -- one layer holds the characters of the map (I guess those are tiles), and the other is the "fog of war".

Are tiles 8x8 pixels then?  Sounds like I'd want to create a custom character set.

I'm not creating a repeating background: it's a viewport (call it 40 characters by 40 characters or so, in the center of the screen) into a gigantic map.  It sounds like *changing* the tiles requires 1,000 VPOKES...  suppose your ship "moves" 320 pixels to the West; that's a whole new map, different from moving 320 pixels North.

Edited by rje

Share this post


Link to post
Share on other sites

Character modes are simply two kinds of tile mode where there's 256 different tiles (characters) available.

The other tile modes make 1024 different tiles available, in sizes of 8x8, 8x16, 16x8 or 16x16 pixels. Also in 1, 2, 4, or 8 bits per pixel, and in map sizes of 32, 64, 128 or 256 tiles vertically or horizontally, in any combination.

So, there's really 4 tile sizes * 4 bit depths * 4 map sizes horizontally * 4 map sizes vertically = 256 different combinations per tile layer.

Oh, and tiles in these "real" tile modes can be horizontally and vertically mirrored.

I suggest you read the VERA Programmer's Reference thoroughly and try to understand the tile modes, because they're VERA's main strength.

 

Share this post


Link to post
Share on other sites

The tilemap can be scrolled horizontally and vertically, and will loop when it reaches the edge. Due to this looping behavior, it is possible to reduce the number of writes necessary by only rewriting the row of tiles that needs to be changed.

3 minutes ago, Guybrush said:

I suggest you read the VERA Programmer's Reference thoroughly and try to understand the tile modes, because they're VERA's main strength.

I definitely agree; the VERA reference is extremely useful. Here is a link.

Share this post


Link to post
Share on other sites

It's nice -- (16 x 16) pixel tiles, in a (256 x 256) matrix, is pretty good, and nice that it's handled in hardware.

 

Share this post


Link to post
Share on other sites

@rje Please be aware that 256x256 tile map is really not usable since it uses 128k of VRAM (256 * 256 * 2bytes). I suggest you use the tile map size only slightly larger than your visible game area, and load in new columns or rows as needed. And just try to wrap (pun intended) your mind around the fact that tile layers wrap around 😀

  • Thanks 1

Share this post


Link to post
Share on other sites

You can do 256x256, just don't populate the whole map. The pixel graphics police won't arrest you for that. Place scrolling limits in software and use the unvisited parts of the map (most likely the bottom rows) for other things and leave space for the reserved addresses at the end.

Share this post


Link to post
Share on other sites
[mention=15]rje[/mention] Please be aware that 256x256 tile map is really not usable since it uses 128k of VRAM (256 * 256 * 2bytes). I suggest you use the tile map size only slightly larger than your visible game area, and load in new columns or rows as needed. And just try to wrap (pun intended) your mind around the fact that tile layers wrap around 

I have implemented this, but updating single columns and rows got unnecessary complicated. I ended up with a double buffered 32x32 tilemap (tiles 16x16). I scrolled 15 pixels and then updated the complete visible part of the tilemap. That made be spend about half of the available CPU cycles including all other code that was running each frame. A processor speed of 8 MHz makes a great difference compared to 1 MHz : ).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use