Another Unreleased Game - Blaze

[Mrs Beanbag]

Originally Posted by Codetapper

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.

The reasoning here is oddly circular... obviously if the bob engine only supports images with widths of multiples of 16, it would be wasteful not to design your graphics to that limitation.

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.

It is exactly a third less in terms of total blitted area. I think you are overestimating the complexity of the process, there are no "extra checks on every object", all there is is a function that can redraw the map in a rectangular area. There is obviously some extra CPU overhead involved, but it's hardly reams of code.

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...

You think it is a special case for every extra pixel wide, this is strange. There is the case where you have to blit an extra word wide, and the case when you don't. There is no need to worry about the LWM at all in the latter case, since the bob's own mask image is zero there anyway.

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.

But these calculations are trivial. For a 16-pixel wide bob, knowing when not to blit one extra word wide is just a case of checking if the bit shift is zero. For other widths it's just a comparison against (16 minus (pixel width & $f)).

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.

Copper-split does add some complexity, but it is worth doing for the sake of the scrolling. Although i have another idea up my sleeve for my next scrolling and bob routine.

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.

Well i imagine if it was "fast enough" and they had a release deadline coming up, that they were happy to leave it at that, and we all know how many games creators seemed happy with 25fps. Lotus is not a great example to compare, since most of its bobs are fairly large and probably appear in a fairly uniform distribution regarding their position on the screen, but for 2D scrolling games things are different. Often enemies are constrained to move along one axis at a time. If they move sideways at 4 pixels per frame, they are on word boundaries 1/4 of the time, not 1/16. If they move around a maze like pacman, they are on word boundaries about 1/2 the time. If they only move up and down, they are on word boundaries ALL the time. So for 16 pixel wide bobs, you can cut the blitting time in half, and you would tell me that it's not worth doing, for the sake of a few CPU instructions? And that when it is usually the CPU waiting for the Blitter, rather than the other way around, and that the CPU can perform its calculations for the next blit while the Blitter is still busy on the previous one.

[Codetapper]

Originally Posted by Mrs Beanbag

It is exactly a third less in terms of total blitted area. I think you are overestimating the complexity of the process, there are no "extra checks on every object", all there is is a function that can redraw the map in a rectangular area. There is obviously some extra CPU overhead involved, but it's hardly reams of code.

You're simplifying things here. How many games use 16x16 bobs? And how many restrict the enemies to 2 or 4 pixel horizontal movement?

Since you've been talking about Chuck Rock, most of those are 32, 48 or even 64 pixels wide. There's a few 16 pixel wide bobs, but most are larger. The enemies such as the bird follow a smooth sine wave when lifting Chuck up over the gap. The large dinosaur you move on also moves around smoothly. The coconuts that get thrown from the tree take up the full 16x16 pixels and can move to any pixel (sine waves again, plus bouncing). There's many more examples through the game.

Maybe Mr Beanbag is an overly simplified game engine compared to Chuck Rock and you're thinking about that specific case of horizontal/vertical only movement in only 2 or 4 pixel chunks but not considering a more general game? One game I'm working on has the main character moving 3 pixels per frame for example.

But these calculations are trivial. For a 16-pixel wide bob, knowing when not to blit one extra word wide is just a case of checking if the bit shift is zero. For other widths it's just a comparison against (16 minus (pixel width & $f)).

And my point is if you have 50 objects to check, that's 50 series of calculations you're doing to work out if the bob can save one extra word (after retrieving exact pixel dimensions, so that's even more CPU usage) and if only 1/16 bobs happen to be on that boundary, you're saving 1 word of blitting x the height of 3 bobs for the cost of all those calculations. And if the blits are small (only a few pixels high) the blitter will be finished and wasting time waiting for all your extra calculations to take place.

Maybe in your simple restricted-to-up-down-left-right game it's worth it, I don't know. For a general game it sounds like the 6.25% of the time on average the bob would be exactly on a word boundary isn't worth the complexity added with the code.

[Mrs Beanbag]

Originally Posted by Codetapper

You're simplifying things here. How many games use 16x16 bobs? And how many restrict the enemies to 2 or 4 pixel horizontal movement?

Quite a lot. Anyway that's beside the point. You brought up the case of small bobs, 2x2 in fact, which is smaller than anything i've ever used. 8x8 is perfectly reasonable for bullets, or bits of shrapnel or whatever.

Since you've been talking about Chuck Rock, most of those are 32, 48 or even 64 pixels wide.

and in only 3 bitplanes. I mentioned Chuck Rock because it draws the bobs behind the main playfield, and i'd speculated about how that was done (and got it wrong, ok). Most of Mr Beanbag's enemies are 32x32, 48x48 is common on later levels. 16x16 or smaller is usually for thrown or fired objects, animated collectables &c.

Here is 48x48 elephant and 64x32 tiger:

Maybe Mr Beanbag is an overly simplified game engine compared to Chuck Rock and you're thinking about that specific case of horizontal/vertical only movement in only 2 or 4 pixel chunks but not considering a more general game? One game I'm working on has the main character moving 3 pixels per frame for example.

It's not an oversimplified engine. It's an overcomplicated engine according to you. Of course it can handle any complexity of movement, but if you do keep objects to word boundaries, you get the benefits of that. There are 16x64 portcullis objects that swing up and down, for instance, and 64x16 moving platforms that move in a similar pattern, plus all of the beans and various other collectable items oscillate up and down. Not wasting time on these objects means i can spend it elsewhere, or have loads of them on screen. Main character is a sprite in any case so that's academic (in Mr Beanbag and in Chuck Rock). Many of the objects in Chuck Rock appear to move at constant sideways speeds, some quite fast.

And my point is if you have 50 objects to check, that's 50 series of calculations you're doing to work out if the bob can save one extra word (after retrieving exact pixel dimensions, so that's even more CPU usage)

How is retrieving "exact pixel dimensions" any more CPU usage? It fits in a word in either case... 50 objects on screen would be pretty chaotic anyway, just picture that for a second. There are only 70 background tiles on the screen, with 32x32 tiles. And it's not "one extra word". We're talking about *doubling the size of all the blits of 16-pixel wide objects*. Or for 32-pixel wide objects, it's 50% extra blitting.

And if the blits are small (only a few pixels high) the blitter will be finished and wasting time waiting for all your extra calculations to take place.

but you were just saying that most game objects are large... make your mind up...

Maybe in your simple restricted-to-up-down-left-right game it's worth it, I don't know. For a general game it sounds like the 6.25% of the time on average the bob would be exactly on a word boundary isn't worth the complexity added with the code.

But it's hardly any complexity, it's literally a few extra instructions, and you can *arrange* for objects to fall on word boundaries more often than they would by pure chance. It is a simple matter to ensure that an enemy's bullets go at 8 pixels per frame, for instance, or that an enemy charges at 4 pixels per frame.

[Codetapper]

Originally Posted by Mrs Beanbag

How is retrieving "exact pixel dimensions" any more CPU usage?

In my case, I don't bother storing the width of the object in pixels as when you're plotting it it doesn't make any difference if it's 31 pixels wide or 32. I store the fact it is 2 words wide on the sheet of graphics so it's ready for the blitter. It seems pointless to read the width as 31 into a register if the final pixel happens to be empty and make a bunch of calculations including shifts (which are slow on the 68k) to work out that almost all of the time it's going to still take up 2 words plus the one extra for shifts. Remember the A500 has a fast blitter compared to the CPU, and I am making it to run on the A500 at 50fps.

And it's not "one extra word". We're talking about *doubling the size of all the blits of 16-pixel wide objects*. Or for 32-pixel wide objects, it's 50% extra blitting.

It's not "extra" at all, that is the "normal" case that you should consider - ie. the object NOT exactly on the word boundary. Anything else is (hopefully) an optimisation to save one word per pixel height (but if you do too much work on every object to work that out, it's not).

Anyway, I originally wrote my code thinking that method you speak of might work (saving a word rarely) and ditched it as it made the general blitting routine much more of a mess and so I ditched it.

It is a simple matter to ensure that an enemy's bullets go at 8 pixels per frame, for instance, or that an enemy charges at 4 pixels per frame.

Have you seen shoot'em-ups that do that? They look utterly mental. The bullets either look like they're appearing from way out in front of the guns one frame and way back the next frame when you creep forward a pixel.

[turrican3]

REally interesting...
Guys you should make a new team fo amiga coders !!!
You should make a kickstarter to finish blaze or to make a new amiga game !!!

[JudasEZT]

Originally Posted by keithbugeja

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

Yeah! I've checked it.. its true.. very cool feature. Now the game also is a bit more like a MetalGearSolid

[Mrs Beanbag]

Originally Posted by Codetapper

In my case, I don't bother storing the width of the object in pixels as when you're plotting it it doesn't make any difference if it's 31 pixels wide or 32.

So do i, currently, but i'm thinking about not doing that in future. Or perhaps store the word width, plus an additional value to compare against the shift register when you have it, which might be faster than a shift.

I store the fact it is 2 words wide on the sheet of graphics so it's ready for the blitter. It seems pointless to read the width as 31 into a register if the final pixel happens to be empty and make a bunch of calculations including shifts (which are slow on the 68k) to work out that almost all of the time it's going to still take up 2 words plus the one extra for shifts. Remember the A500 has a fast blitter compared to the CPU, and I am making it to run on the A500 at 50fps.

There is not "a bunch of calculations". There is a single comparison operation (once you know what to compare against, which you can precalculate), and you either proceed exactly as normal, or you decrement the word width/increment modulos and set the Last Word Mask to $ffff. If you were using a lot of 8-pixel wide bullets i think that would be worth doing. Obviously there's no point programming features you don't intend to use. Admittedly, i've been coding for A1200, where the profile is different.

It's not "extra" at all, that is the "normal" case that you should consider - ie. the object NOT exactly on the word boundary. Anything else is (hopefully) an optimisation to save one word per pixel height (but if you do too much work on every object to work that out, it's not).

We risk falling into pedantic word games here. It's "extra" in the cases where it isn't really needed. How often this case occurs depends on the design of the game. I can think of many cases where it would occur a lot. Platform games where characters go up and down word-aligned ladders, vertical shoot-em-ups with waves of 16-pixel wide missiles hailing down the screen.

Anyway, I originally wrote my code thinking that method you speak of might work (saving a word rarely) and ditched it as it made the general blitting routine much more of a mess and so I ditched it.

i've also ditched things in the past that i could probably do better now. i tried to implement some kind of blitter queue at one stage, that didn't really work out so i gave it up. i might try again at some point.

Have you seen shoot'em-ups that do that? They look utterly mental. The bullets either look like they're appearing from way out in front of the guns one frame and way back the next frame when you creep forward a pixel.

If the guns firing such bullets are stationary, it is not a problem.

EDIT: just been looking at my source code, i haven't touched it for over a decade and i can see immediately that i could do some fairly trivial optimisations (the benefits of hanging out here), but after that and stripping out the code that handles the clipping at the edge of the screen, calculation of BltAFWM/BltALWM looks like this:

  moveq.l #-1,D4
  and.w #$F,D1  ; low 4 bits of X-coordinate
  beq.s aligned
    addq.w #2,D2  ; blit width
    subq.w #2,D3  ; A/B modulo
    clr.w D4
aligned
  [lsl.w D1,D4]  ; BltAFWM : BltALWM

EDIT2: wait a minute that can't be right, i'm going to have to sort this out until it makes sense again
EDIT3: worked it out, the last line only happens during clipping (forgot how the masks worked! it's been too long)

[Amiga600]

Sadly I cannot get this to work, I always get bad graphical glitches all the time, regardless of how I try to load it in, I have tried normally, under WHD Generic 1.3 and WHD Generic 3.1 and even tried ToggleAGA E/A and other tricks to try and get Blaze working, But alas, as of yet, no go

Could someone make a WHDLoad of this perhaps?

Mrs Beanbag (I assume this is your game since you mention "my source code" above so please can I ask/have your permission to feature this on my Games Collection?

Many Thanks