Animated chars with characterset from memory

[+mksmith]

Hi,

 

By swapping charactersets (as shown by Synthpopolooza) you can very quickly swap an entire set of characters each frame using memory pointers.

 

So currently if you wanted to animate a single char with say 8 different frames you can setup screen ram, then do a memset with the next character index and thus create an animated char (even a full background). One of the great examples of what I'm thinking is Delta on the c64 - the animated starfield was pretty much a range of characters cycling to move the stars across the screen.

 

Now we get to the fun bit.  Can you configure something in memory (such as a small characterset) and update a pointer to cycle a character to animate a char on-screen? I certainly believe this could be the most efficient way to do something like this... So the question is can this be done??

 

 

[Synthpopalooza]

To animate characters this way requires a block for each font.  The font must be in the same position each bank.  You then change the character pointer to which frame you want.

Edited August 29, 2019 by Synthpopalooza

[+SmittyB]

Another, more flexible way to animate tiles would be to copy your tileset into RAM and then update CHARBASE to point to it so that whenever the 7800 draws in indirect mode (from a tile map) it will load the graphics from RAM. You would then be free to modify that area of memory to change your tileset on the fly. As there's no good reason why a tilemap shouldn't be aligned to a zone the tileset graphics wouldn't need to be padded with zeroes or stored in the usual areas surrounded by 'holey DMA' so they could be stored elsewhere in ROM and copied out as needed, freeing up space for other graphics.

The problem with this is that you would have to either use additional RAM on the cartridge or have a limited tileset of say, 64*16 bytes. 

 

Rather than storing each frame as a different tile many games would just roll the data in ROM which makes it appear to scroll, and as graphics data is typically stored row by row it's trivial to scroll different lines by different amounts.

Delta probably isn't a good example actually as the graphics are very sparse and it uses more tiles to create the effect so it's not as obvious what's happening. The C64 version of R-Type uses a handful of tiles in a repeating pattern for the background, and while the screen scrolls left it rolls the graphics for those tiles to the right so it looks like the background isn't moving as fast so you get a parallax effect. 

 

 

[+mksmith]

@Synthpopalooza I gave your method a quick try and as each charset appears to need to be in it own gfx block it does limit it to 3. Does that sound right?

 

@SmittyB have you got an example of this? This is pretty much what I'm thinking - I tried a few things using incgraphic memcpy etc but couldn't get it to work.

 

 

 

[+SmittyB]

I don't have an example of it as it's just something I've been thinking of doing at some point, but I might be able to get one soonish.

[+mksmith]

1 hour ago, SmittyB said:

I don't have an example of it as it's just something I've been thinking of doing at some point, but I might be able to get one soonish.

Ok thanks. I think this has some potential for a small set of tiles. I was thinking of eventually doing a game similar to Jeff Minter's Matrix (follow-up to Gridrunner/AMC). The grid moves using a single repeated tile. It would also allow some additional animations where you cycle different tiles. 

 

 

[+SmittyB]

I don't know why I forgot and gave you wrong information but a reduced tileset wouldn't help with the memory requirement as each line of graphics must always be offset by 256 bytes. That means a tileset for an 8 pixel high zone is 2k and the 16 pixel high zone requires 4k so cartridge RAM is needed.

 

I'll see if I can get something working quickly this weekend.

[+mksmith]

1 minute ago, SmittyB said:

I don't know why I forgot and gave you wrong information but a reduced tileset wouldn't help with the memory requirement as each line of graphics must always be offset by 256 bytes. That means a tileset for an 8 pixel high zone is 2k and the 16 pixel high zone requires 4k so cartridge RAM is needed.

 

I'll see if I can get something working quickly this weekend.

All good - very kind of you ?

[RevEng]

Multiple character sets are for sure the most efficient way with regard to processor time. If you can't throw multiple character sets at this, you can still do it with individual character updates... you just need to split up the character updates across frames. Salvo does this when the play area shrinks away, after you've lost all humanoids.

 

Obviously that this works best if the vertical connectivity of your tiles is limited, so nobody sees "seams" due to the delay. Since a starfield has no seams, you could do that with one horizontal row update per frame, if it's meant to scroll fairly slowly.

[+mksmith]

Thanks Mike - will have a look at the Salvo source ?

 

[+SmittyB]

I've attached a (somewhat) minimal example of manipulating tile graphics in RAM. It draws a static tile map from ROM and the only animation comes from editing the tile data.

It shows graphics scrolling left at different speeds, scrolling up and down, copying new graphics over the tileset to change it on the fly, and finally scrolling right.

Of course a lot more can be done with this, but this just shows the basics of the techniques which have been used to great effect in many games.

SuspiciouslyShiftyDemo.a78 SuspiciouslyShiftyDemo.bas

[+mksmith]

@SmittyB thank you very much - look forward to take a look ??

[Synthpopalooza]

This is going to help me out too with my 90 color interlaced font tool in 320B.  Thanks