Boulder Dash's famous smooth animation

[Foebane]

I remember being fascinated by how smooth and versatile the animation was in this game, even when things were busy and frenetic, and I found out later on that by POKE-ing a single value into a memory register, the character set graphics could be changed just like that, and that somehow the programmers of Boulder Dash had EIGHT such sets of character set graphics.

 

I've seen other games where the graphics in character sets have been poked directly to produce random fizzle effects and whatnot, and I really like this aspect of Atari 8-bit graphics. I also noticed that the Commodore 64 seems to have the same ability.

 

I was even more surprised when I made my own game that utilised this multiple character set switching, where a Player sprite is guided around animated traps in multiple caves - even the collision detection worked this way perfectly!

 

What does everyone else think of this simple method of animation?

 

[Rybags]

I'm not sure that BD switches the entire character set. In most cases where games do that it's when around 2-4 animation frames are used.

Also, it's often more memory efficient and not too taxing on the CPU to just simply move the data into characters.

BD doesn't have that many animations going on. Diamonds, slime, butterflies and square enemies, probably a couple of other things I've missed. But at 4 character cells each, it's only 32 bytes per animated object that have to be copied. Though I suspect also some object types can be at different animation phase (e.g. butterflies)

[José Pereira]

I was talking with Xuel yesterday about sprites stuff and he said that on our X:8 he used 8charsets for the enemys and it seems that is what you're saying.

Other thing we also did was the top and bottom grounds are the same charset just by using the ANTIC charmodes inverse. You can try it just pokeing 755,4 in basic and all screen chars turn upside down.

[Rybags]

Method aside, for a 16K game there was good effort put in.

Plenty of other games of the time just had 2 or 3 animation frames and looked cheap as a result.

[José Pereira]

Yes BD was good but I never got why they didn't use the PMGs and beeing in charmode add the PF3 into gfxs. Was it to fit in 16KBs and run in the Atari 400?

The A8 was the original? That seems the reason for the direct port and no sprites nor colour atributes on the C64.

We talked here about this sometime ago and Tezz was thinking in have the guy as 3colour two PMGs multicolour. This would still leaves with other two maybe for the exit...

This way we could have same colours on Rockford on all levels and they freely can still change them on the gfxs.

And adding PF3 we could have like one colour different in rocks and walls or others.

I hope Tezz will do it like he did on Chimera and here seems more simple because the code speed is good and is just add PMGs.

Edited April 8, 2015 by José Pereira

[Foebane]

I'm not sure that BD switches the entire character set. In most cases where games do that it's when around 2-4 animation frames are used.

Also, it's often more memory efficient and not too taxing on the CPU to just simply move the data into characters.

BD doesn't have that many animations going on. Diamonds, slime, butterflies and square enemies, probably a couple of other things I've missed. But at 4 character cells each, it's only 32 bytes per animated object that have to be copied. Though I suspect also some object types can be at different animation phase (e.g. butterflies)

 

I never thought of it that way, but what I meant was that all eight character sets are in memory at once, and the single POKE into the memory register simply tells the custom chip what area of memory to refer to when rendering the graphics on screen. My own game did it this way, so that must be how BD does it. What's more, I've seen games where this memory register was given a value which didn't refer to any character sets in memory but other data, to give a type of fizzling blocky effect. I'm certain of that.

[billkendrick]

There's undoubtedly plenty of time during vertical blank interrupt to move a few bytes of character data around within the heavily-animated objects (like the titlescreen background and 'fizzle' tiles). No reason to waste 8KB on character data for so few changing characters.

[Foebane]

There's undoubtedly plenty of time during vertical blank interrupt to move a few bytes of character data around within the heavily-animated objects (like the titlescreen background and 'fizzle' tiles). No reason to waste 8KB on character data for so few changing characters.

 

The "fizzle" in the blank areas that announces an extra life, to my mind, is of a random number simply being POKED into the relevant character's display memory just twice, every four bytes. It looks cool as heck and is really simple to do. As for the rest, you're right. It would be wasteful of memory otherwise.

 

EDIT: As far as I can see, only the following is animated:

 

Rockford

Amoeba

Fireflies

Butterflies

Magic Walls

 

That's five animated items x 4 characters for each one = 20 characters x 8 bytes = 160 bytes altogether. Absolutely small overhead, yes.

Edited April 8, 2015 by Foebane

[Foebane]

Yes BD was good but I never got why they didn't use the PMGs and beeing in charmode add the PF3 into gfxs. Was it to fit in 16KBs and run in the Atari 400?

The A8 was the original? That seems the reason for the direct port and no sprites nor colour atributes on the C64.

We talked here about this sometime ago and Tezz was thinking in have the guy as 3colour two PMGs multicolour. This would still leaves with other two maybe for the exit...

This way we could have same colours on Rockford on all levels and they freely can still change them on the gfxs.

And adding PF3 we could have like one colour different in rocks and walls or others.

I hope Tezz will do it like he did on Chimera and here seems more simple because the code speed is good and is just add PMGs.

 

Why use sprites at all? It would've looked wrong if Rockford was a sprite and obviously not part of the environment. And the basic five colours could be seen as the "lighting" in the game world.

 

What is PF3?

 

Speaking of PMGs in Atari games - some games are JUST NOT SUITED for them. Take Mercenary, for example: a totally 3D graphic rendering game with just plain Atari graphics, and no PMGs in use at all - except for a simple aiming sight that is picked up as an inventory item. Must've been the easiest coding Paul Woakes ever did!

[Rybags]

Sprite/PMG gives the option to have more colours. PF3 is the extra colour available in the multicolour text modes, so giving 5 instead of 4 choices. High bit of char code=1 means to use PF3 instead of PF2 for "11" pixel values in that character.

[Foebane]

Sprite/PMG gives the option to have more colours. PF3 is the extra colour available in the multicolour text modes, so giving 5 instead of 4 choices. High bit of char code=1 means to use PF3 instead of PF2 for "11" pixel values in that character.

 

I think the Amoeba used the 5th colour, but I could be wrong.

[José Pereira]

 

I think the Amoeba used the 5th colour, but I could be wrong.

Yes it seems it use. I did some investigation last night after your post.

Indeed if you just see the original 'way of' PFs distribution you'll have PF2 always the white/light colour on the playing area and the PF3 is the yellow numbers at the top scores (then a DLI changes PF3 soo that Amoeba has other colour):

Here's an example of that:

 

But that is if you just use the original PFs colours. Lets say that instead of white be PF2 then you'll still have amoeba other colour but you can have, for example diamonds (or any other gfxs of your taste...) other/distinguish lines colour. Here's one of the many many Boulder Dash versions done using the construction kit but here the author seem to have PF2 other than white (see now that diamond is perfectly seen different than other gfxs):

(PF2 is lilac and PF3 is green)

 

And now look that if original the difference and the diamonds using same 3colours (althought the cycling lines is a good efect):

 

 

As for the guy be PMGs it's just the frames of it be 2Players in Multicolour Mode (P0+P1 giving an Ored 3rd colour) and you'll have any colours you want on the gfxs on any levels and game versions but Rockford will always have a same colour(s) on all and better looking/seeing VS gfxs.

Here's two levels example (and there's PF3 on the amoebas and I kept PF2 as white):

 

Here's the 25th Aniversary Edition did and that I hope he gets time to add at least the PMGs to Rockford like he intended and already did on his recent Chimera...

boulderdash_ii_25th_anniversary.zip

Edited April 9, 2015 by José Pereira

[José Pereira]

Humm... If the intention is to keep the game in 16KBs and I don't know if the todays .xex are same Memory as original files but BoulderDash the first ones has only 10KBs:

Boulder Dash.xex

Soo adding the guy using PMGs is what? More around 2KBs.

Each Player is an 8bit number (1Byte) and has 256scanlines tall soo for each there's the need to reserve 256Bytes in Memory and we have to pre-reserve 1,25KBs that is the 4Players + 4Missiles (these are equal as 1Player) more Rockfords data and you'll get that it was certainly possible and nothing more than the using what the machine has.

Now what where to use P2 and P3?

 

[Foebane]

I don't agree with PMGs in Boulder Dash AT ALL.

 

To me, part of the appeal of BD is that everything is locked into a cellular grid, and part of the appeal of Rockford's movement is the jerky cell-to-cell movement he has, not to mention everything else like the boulders and other entities, especially when the scrolling occurs. With PMGs, Rockford would be free to move smoothly from cell to cell and I would frankly find that very jarring. In fact, later BD clones have done just that, and I do NOT like these as much as the original jerky cell-to-cell movements.

[bfollett]

Well, the option is still there to have the same jerky movement with the PMGs. You'd still gain Rockford not changing colors every screen and blending into the current screens color palette . It would be the programmers choice if he liked the jerky movement over the possibility of adding smooth movements.

 

Bob

Edited April 9, 2015 by bfollett

[José Pereira]

And why it have move 1pixel at each time and not a one Byte in X and 8Bytes in Y if he's using PMGs the same way as beeing a char?

Everytime he moves horizontally its current xPos 4 and if it has 256scanlines just place it yPos in a multiple of 8/clear data when move/update to the next 8 or -8 scanline.

Is the vertical 2Players placement less quick than the char ones?

Coders around is it?

[José Pereira]

If you're using PRIOR1 and have something like this:

P0 lightest purple [5E] shirt line1 and shoes

P1 green [AC] shirt line2

P0 Oring P1 gives lighest brown [FE] skin on face and hands

P2 green [b6] trousers

P3 (behind) 8y8 data as black [00] it will even clear the gfxs around if you move in pixels and maybe there's no jerky movement .

Edited April 9, 2015 by José Pereira

[sack-c0s]

I agree with the cell locking - the logic revolves around everything acting in a particular way with cell-based movement, and being able to think ahead and predict the rules of that movement forms an import part of the game. I think once you start adding smooth player movement it feels like it breaks that

 

If I were making a modern version I'd possibly compromise by having a kind of 'quick dash' movement into the next cell, so you have a little more animation and it's not a sraight jump but it does respect the cell-based constraint of the game.

[Creature XL]

 

My own game did it this way, so that must be how BD does it.

Frankly, that is not a good enough reason for me