Another Unreleased Game - Blaze

[ReadOnlyCat]

Originally Posted by Mrs Beanbag

Another way to deal with this issue is to draw all the bobs "behind" the tilemap, as is done in Chuck Rock and other games using that engine. Presumably (i'm guessing) it also maintains a mask as it scrolls on another invisible bitplane, and combines that mask with the bob's mask. That way, to remove the bob we can just blast it off in colour 0 using the same mask again and we don't need to worry about restoring the background at all.

I was reading this wide eyed trying to make sense of this "just blast it off in colour 0" statement until I watched a video of Chuck Rock and realized the game uses dual playfield. Quite an important detail.

And to add to the list of techniques which save time when drawing bobs.
The fastest behind-bob background redrawing routine is the one ... you do not call.

I'm sure you will figure it out very quickly if you dedicate a few neurons to the idea.

[Codetapper]

Originally Posted by Mrs Beanbag

Another way to deal with this issue is to draw all the bobs "behind" the tilemap, as is done in Chuck Rock and other games using that engine. Presumably (i'm guessing) it also maintains a mask as it scrolls on another invisible bitplane, and combines that mask with the bob's mask. That way, to remove the bob we can just blast it off in colour 0 using the same mask again and we don't need to worry about restoring the background at all. But, it does require combining the background mask with the bob's mask in a separate blit, so that is 2 times the bob's area, times the number of bitplanes, plus one additional blit in one bitplane. Also clearing the bob might require more DMA cycles than a straight copy.

You're wrong about Chuck Rock - it doesn't blit bobs "behind" anything. The game is dual playfield, there's a front layer that contains ground, flowers etc, and the background playfield. The enemies are blitted onto the background layer as normal, they can't be "blasted off" with colour 0 at all. Chuck is made of sprites and sits behind the front playfield, but in front of the background playfield.

[Mrs Beanbag]

Ah, i'd guessed that Chuck would be made of sprites (it's what i always do, anyway), but somehow it never occurred to me that the bobs would be drawn on the background layer. That also means you don't need to take a copy of the background under the bob, because you know the background image isn't going to change so you can just keep a spare copy of it and redraw it from that.

This would limit the effects that would be achievable on the background later though, so the sort of parallax effects you see in Kid Chaos wouldn't be possible.

[ReadOnlyCat]

Originally Posted by Codetapper

The enemies are blitted onto the background layer as normal, they can't be "blasted off" with colour 0 at all. Chuck is made of sprites and sits behind the front playfield, but in front of the background playfield.

Interesting. I would have tried to use the foreground layer to draw at least some bobs as this allows to simply clear the parts where they do not overlap the background, instead of redrawing it.

Originally Posted by Mrs Beanbag

but somehow it never occurred to me that the bobs would be drawn on the background layer.

Glad to see I am not the only one with this idea.
Obviously, to get maximum color variation one could use both foreground and background layers to draw bobs but it seems reasonable to try to favor the foreground one.
It would also be viable to have some bobs use both layers to increase color count.

Originally Posted by Mrs Beanbag

That also means you don't need to take a copy of the background under the bob, because you know the background image isn't going to change so you can just keep a spare copy of it and redraw it from that.

Or one could save memory and use the Mr Beanbag technique you described earlier.

Originally Posted by Mrs Beanbag

This would limit the effects that would be achievable on the background later though, so the sort of parallax effects you see in Kid Chaos wouldn't be possible.

Why would it?
If you take parallax shifting into account while blitting you can still draw bobs over the background as long as you split them appropriately.

Note: we are quite off-topic, sorry Keith!

[PortuguesePilot]

Originally Posted by ReadOnlyCat

(...) Note: we are quite off-topic, sorry Keith!

Indeed. This is a very interesting conversation but ultimately seems merely academic. Knowledge for its own sake is a good thing, but better yet is when that knowledge is applied. Is anyone actually "working" on Blaze or can we forget about this one too? If yes, then it's too bad, 'cos its potential was immense.

[Mrs Beanbag]

Originally Posted by ReadOnlyCat

Or one could save memory and use the Mr Beanbag technique you described earlier.

If the background image is also a tilemap. On Mr Beanbag it's not, it's just a single large image that wraps around, not sure about Chuck Rock though.

[Codetapper]

Originally Posted by Mrs Beanbag

If the background image is also a tilemap. On Mr Beanbag it's not, it's just a single large image that wraps around, not sure about Chuck Rock though.

Chuck Rock's back playfield is definitely a tilemap, it's 160 tiles wide. Quite a few of your guesses about how this game works are way off the mark, and with WinUAE it's pretty trivial to verify things.

Another thing you have overlooked in your earlier posts is when you suggested you don't need to save the graphics behind the baddies as you can just restore them from the tiles. This only works if you are going to redraw every enemy each update, which in some games is extremely wasteful.

Consider the situation of a background tilemap, with 10 enemies that hardly move/animate, and say a bullet (with higher priority) passing over them. If you restore from tiles, you have to restore the background, then paste down the enemies, then the new bullet, when really only the graphics behind the bullet need to be replaced.

Also the tile method can be extremely wasteful. If you have a small bullet (say 8 pixels wide by 2 high), that could potentially be covering 4 different tiles (and doesn't Mr Beanbag use massive 32x32 tiles?). That's a hell of a lot of blitter use just to move a tiny bullet.

[Mrs Beanbag]

Originally Posted by Codetapper

Consider the situation of a background tilemap, with 10 enemies that hardly move/animate, and say a bullet (with higher priority) passing over them. If you restore from tiles, you have to restore the background, then paste down the enemies, then the new bullet, when really only the graphics behind the bullet need to be replaced.

So what you suggest, is you save the background and then draw, for each individual bob, rather than do all the saving, then do all the drawing... well, if a bob doesn't move (or if it animates but its mask doesn't change) we need not redraw its background at all anyway, but we do still need to redraw the bob itself. The best technique obviously depends on use case. Do you have a lot of bobs that don't move very often? If there are only a few, then 2 drawing operations instead of 3 still seems worthwhile.

Also the tile method can be extremely wasteful. If you have a small bullet (say 8 pixels wide by 2 high), that could potentially be covering 4 different tiles (and doesn't Mr Beanbag use massive 32x32 tiles?). That's a hell of a lot of blitter use just to move a tiny bullet.

It is possible to blit just part of a tile. There is no need to redraw an entire tile just because one corner of it got covered up. Using bigger tiles means a tile-boundary span happens less often for small objects.

[Codetapper]

[QUOTE=Mrs Beanbag;1053312]well, if a bob doesn't move (or if it animates but its mask doesn't change) we need not redraw its background at all anyway, but we do still need to redraw the bob itself.[QUOTE]

But then you'd have to have your engine keep track of which bobs have a different mask between animation frames so as to know which ones don't need saving/restoring?

Originally Posted by Mrs Beanbag

It is possible to blit just part of a tile. There is no need to redraw an entire tile just because one corner of it got covered up. Using bigger tiles means a tile-boundary span happens less often for small objects.

If you then have to keep track of which parts of a tile need redrawing, the added complexity in keeping track of all that will eventually outweigh any savings.

3 bullets that that partially obscure different parts of the same tile will then have 3 operations to restore it!

The engine would get more and more complex with all these special cases and at some point it's simply easier to have one optimised routine that handles everything rather than all this added complexity.

I do agree with you that it depends on the game what you're doing, but a more general approach that works well with almost all games is to save everything behind the bobs, redraw them, and restore them. And depending on the game, you don't need to waste time building up a second "clean" screen to restore the graphics from as you've saved the graphics behind the bobs anyway. If you're saving the equivalent of say 16 tiles worth of graphics behind the bobs, and in return you do not have to waste 40k of chip memory on a spare copy of the screen (to save one blitter operation/bob) and not have to draw the tiles into it, that's a big win.

[Mrs Beanbag]

Originally Posted by Codetapper

But then you'd have to have your engine keep track of which bobs have a different mask between animation frames so as to know which ones don't need saving/restoring?

that's true, and currently i don't bother doing that, but if a bob is completely unchanged from one frame to the next (or rather, from one frame to two frames ahead, because double buffering) then it doesn't redraw the background.

3 bullets that that partially obscure different parts of the same tile will then have 3 operations to restore it!

But that is the case anyway, if you are saving the background behind each bob.

All i'm doing is redrawing the map, in rectangular regions, over the bobs from the last frame. In theory i could process that somehow so that such regions never overlapped, and you might be right that that isn't really worth doing. Sure there is some CPU overhead but i "guessed" that it wouldn't be as much overhead as the extra blitting, in the average case. Maybe in the worst case it's not as good, but in the best case it is definitely better, and in the average case, well, i honestly can't give you any concrete numbers.

I apologise for being wrong about Chuck Rock, you seem to be really angry about that, i did say i was "guessing" how it works. I know i don't actually take games apart and analyse them like you do, so i bow to your superior knowledge in that respect.

[Codetapper]

Originally Posted by Mrs Beanbag

But that is the case anyway, if you are saving the background behind each bob.

But again, a tiny bob may be in 4 different tiles. Potentially only 1 pixel high in the corner of 4 different tiles.

Then you're comparing one save/draw/restore operation (and the save/restore is only a single blit using interleaved bitplanes) vs a minimum of 4 blits to restore the backgrounds and you have to first work out how much is obscured from each tile to determine you're doing 4 blits of 1 pixel high. And the chances of a bob overlapping more than one tile is at least 15/16. The only case where it wouldn't is a bob 16 pixels wide that fits perfectly inside the tile, so aligned on the edges.

[Mrs Beanbag]

Originally Posted by Codetapper

But again, a tiny bob may be in 4 different tiles. Potentially only 1 pixel high in the corner of 4 different tiles.

If it is only 1 pixel high, surely it can cover a maximum of only 2 different tiles.

Bit pedantic, i know. I get your point. But what is the total area of all these tiny bobs, compared to the total area of the large bobs? Usually, not a lot. Sure it costs us a bit of CPU time to handle these cases, but saves us a full blit the size of the bob for every bob on the screen, tiny or not.

And the chances of a bob overlapping more than one tile is at least 15/16. The only case where it wouldn't is a bob 16 pixels wide that fits perfectly inside the tile, so aligned on the edges.

Well that's one reason i use 32x32 tiles, although it is still advantageous not to cross word boundaries anyway, so i'm careful in the positioning of objects that only move along one axis. For platform games, this happens naturally anyway, since enemies spend a lot of time standing or walking on the platforms.

With some careful thought, it is possible to have bobs less than 16 pixels wide. Yes it will necessarily take up the full word width in memory, but if it has a few blank pixels down one side, obviously you don't need to draw or redraw that part, if it crosses a word boundary.

But coming back to Chuck Rock again for just a second, it makes me wonder about their design choice, if they are using the normal save/draw/clear method but drawing on the background layer, why have they bothered to do this? It must be because they want to use that colour palette, since it can have no performance advantage.

If, however, you wanted to use the foreground palette, but were content with bobs appearing "behind" the playfield, it might be advantageous to use the method i speculated about earlier. Are you aware of any games that use such a technique?

[keithbugeja]

Originally Posted by ReadOnlyCat

Note: we are quite off-topic, sorry Keith!

Actually, it's quite an interesting conversation.

[JudasEZT]

Originally Posted by keithbugeja

Actually, it's quite an interesting conversation.

Indeed it is. I want at some point make a Rastan type of game, and this reading is great.

btw, Keith, I think your Blaze demo has the most prominent usage of animated-background tiles of any amiga game. Walking from behind some of the objects is really a nice feature.

[Codetapper]

Originally Posted by Mrs Beanbag

If it is only 1 pixel high, surely it can cover a maximum of only 2 different tiles.

Obviously I meant 1 pixel high after all your calculations needs to be plotted in each of the 4 tiles (by potentially blitting a 2x2 pixel object right in the corner of 4 tiles). Just the blitter setup for such a tiny blit is horrendous. (And let's not extend this discussion by saying you'd have yet another special case for using just the CPU for certain size objects too. Imagine the code!)

With some careful thought, it is possible to have bobs less than 16 pixels wide. Yes it will necessarily take up the full word width in memory, but if it has a few blank pixels down one side, obviously you don't need to draw or redraw that part, if it crosses a word boundary.

But once again all these special cases you have to handle (and check every frame when drawing) cost you CPU time. For a constant frame rate, you have to consider the average case. The expense of having a 15 pixel wide object so that in the 1 in 16 chance it doesn't have to span 2 tiles is not worth the added complexity imho.

A constant 8 pixel wide object on the other hand might be worth storing twice in memory (one version shifted 8 pixels) so you only have to blit one word depending on the type of game.

But coming back to Chuck Rock again for just a second, it makes me wonder about their design choice, if they are using the normal save/draw/clear method but drawing on the background layer, why have they bothered to do this? It must be because they want to use that colour palette, since it can have no performance advantage.

They kept spare colours on the back playfield for the enemies, that's why the palm trees are not a particularly nice colour on the first level - a weird dark greenish colour mixed with a kind of grey.

And the foreground playfield is drawn to in a couple of places (most notably the dinosaur that craps on you on the 2nd level). But that is blitted in front of that playfield like normal. Almost all enemies live on the back playfield.

If, however, you wanted to use the foreground palette, but were content with bobs appearing "behind" the playfield, it might be advantageous to use the method i speculated about earlier. Are you aware of any games that use such a technique?

Very few games use that, and I can't think of any off the top of my head. Usually it's just only to make it look like the enemies are going behind or through something on the screen, but more often than not, they just blit the obscuring object over the top to make the code simpler.

[Mrs Beanbag]

it's funny that the hero can go behind a column and the bad guy can go in front!

[Mrs Beanbag]

Originally Posted by Codetapper

Obviously I meant 1 pixel high after all your calculations needs to be plotted in each of the 4 tiles (by potentially blitting a 2x2 pixel object right in the corner of 4 tiles). Just the blitter setup for such a tiny blit is horrendous.

"Horrendous", as in, it could easily take more time than the blit itself, but the efficiency of every individual bob is really not important. Only the frame rate is important. The golden rule is "make the common case fast". If the majority of your drawing can be sped up by ~30%, it's worth taking a hit on the edge cases.

The expense of having a 15 pixel wide object so that in the 1 in 16 chance it doesn't have to span 2 tiles is not worth the added complexity imho.

I haven't actually tried it yet, but i don't know what makes you say that. I think it would be hardly any extra complexity at all. The reason i didn't do it is because i'm using AMOS to grab the sprites, and the AMOS image bank format only specifies the width of a bob in words.

[Retro1234]

sorry you could easily create an effect of going behind something with a type of bob clip - object going behind get bob objet - follow hero etc

anyway for parallax I was thinking considerind the speed something like Toki with Two maps you have to redraw the background every?

[keithbugeja]

Originally Posted by JudasEZT

Indeed it is. I want at some point make a Rastan type of game, and this reading is great.

btw, Keith, I think your Blaze demo has the most prominent usage of animated-background tiles of any amiga game. Walking from behind some of the objects is really a nice feature.

Thanks! The foreground objects are not just decorative - behind them you can actually hide from enemies.

[Codetapper]

Originally Posted by Mrs Beanbag

"Horrendous", as in, it could easily take more time than the blit itself, but the efficiency of every individual bob is really not important. Only the frame rate is important. The golden rule is "make the common case fast". If the majority of your drawing can be sped up by ~30%, it's worth taking a hit on the edge cases.

Apart from a few games like Rick Dangerous that use 24 pixel wide bobs (so the graphics are standard across all platforms), I would say you'd hardly find any games that don't have the majority of their graphics very close to a 16 pixel wide boundary. I don't believe this 30% speedup at all, you'd be lucky to save 10% total and you probably lose that when you add up all the extra checks you have to do on every object to detect them, thus wiping out any saving.

I haven't actually tried it yet, but i don't know what makes you say that. I think it would be hardly any extra complexity at all. The reason i didn't do it is because i'm using AMOS to grab the sprites, and the AMOS image bank format only specifies the width of a bob in words.

For a 16 pixel wide object, you have 1 case where you adjust the mask to be $ffff, and can draw the object with 1 word if it's being plotted with 0 pixel indentation to a word boundary.
For a 15 pixel wide object, you have 2 cases where you adjust the mask to be $fffe, and can draw the object with 1 word if it's being plotted with 0-1 pixel indentation to a word boundary.
For a 14 pixel wide object, you have 3 cases where you adjust the mask to be $fffc, and can draw the object with 1 word if it's being plotted with 0-2 pixel indentation to a word boundary.
etc...

For the "majority" case you don't need to store the exact pixel width (knowing the number of words wide to blit is enough), no need to recalculate/lookup/adjust/set the masks, you don't need to calculate if it's going to need one word less to blit, don't need to adjust those modulos when the edge case is found, can use the blit-one-extra-word-with-last-word-mask-set-to-$0000 trick for shifting etc. Not to mention your restoring-from-tiles idea, adding that onto a complicated blitter routine when the screen could be using a copper-split to begin with seems inefficient. If you go ahead and disassemble some games you will see that most have quite a compact blitter drawing routine. They do not tend to have loads of extra cases to speed up blitting in the rare event that it happens. If it was worthwhile, I would imagine most of the big name games would have extremely complicated blitter routines, but the simple fact is that they don't. Check out the Lotus series for a great example of how simple the blitter routines are.