Quote:

The very big bosses!!!

Where ( is there a link ) i can see these monsters ?

Indeed, Bombaman only uses software sprites. In singleplayer mode, there are max 6 player&enemy sprites which are 16x24 pixels, plus 2 bombs. They're all transparent so drawing them (and restoring their old background) is quite costly but the game still runs at a steady 15 frames per second. Maybe 20fps would be possible too, but I think the multiplayer mode would suffer from some slowdown (max 4 players & 8 bombs).

The bosses are max 48x48 pixels or so, not all parts are transparent so drawing the bosses is less costly than the normal enemies. There are also some bullets of course but they're usually 8x8 pixels.

Quote:

Indeed, Bombaman only uses software sprites. In singleplayer mode, there are max 6 player&enemy sprites which are 16x24 pixels, plus 2 bombs. They're all transparent so drawing them (and restoring their old background)...

Restore and save of background could be done in high speed mode. The only operation that require TIMP (-> logical) is the sprite drawing

It is actually done that way But restoring the background can be quite costly 'cause since only 16x24 pixels are restored the game has to calculate which parts of the background patterns have to be copied (so sometimes you end up with strips of 2x16 pixels, 2x8, 14x16 and 14x8). Displaying a player is done with just one VDP command, while restoring the background can use up to 4 VDP commands. Still less costly than a 16x24 timp copy though...

Keep an empty background somewhere in vram. To overcome the little storage problem you can reduce the game area (=>bgd size) and switch to 192 line mode (for extra storage space).

But is there any place where i can see the big monsters of manbow 2?

To copy the sprites you can create 'pipelines' or 'copy lists'. Then run one list during other routines.
example:

1 execute copy command
2 call move object
3 check if vdp is ready : true => goto step 1 | false => goto step 2

obviously must also be checked if the list is finished. This could be in step 1 or step 3. In step 3 you could jump to a different routine.

Now by using double lists you can also fill up a new list for the next frame during building a 'current' one.

1 execute copy command LIST 1
2 call store object in LIST 2
3 check if vdp is ready : true => goto step 1 | false => goto step 2

Now there might be a point where you run out of things to do... well then you will have only step 1 and 3.
Once the pipeline is empty swap pages and swap lists (pointers only obviously).

@PingPong: I dunno I just asumed

GhostwriterP: I haven't tested it myself, but I doubt copying the background twice (once to store, once to restore) is faster than doing 4 smaller copies. And in Bombaman there wasn't even any VRAM left to temporarely store background gfx. Switching to 256x192 would've been an interesting option though...

Bombaman also uses that 'copy list' technique you're describing. It really helps a lot!

Quote:

I haven't tested it myself, but I doubt copying the background twice (once to store, once to restore) is faster than doing 4 smaller copies

I don't recall mentioning something silly as that... Maby you mis interpeted the pipeline a little

then if you mean, keeping the whole playing background in memory, the 'little' storage problem becomes a BIG storage problem

If you know it in advange the hole game can be build around it. Decompress stuff only once needed. Big LEVEL 1 START letters for example. Little less convinient is to do the same with map gfx.
At least if you wanna have 'fast' screen build during levelscreens swapping.
With a 'wide screen HD' display setting of 256X160 you have 2 pages to store other data. And 32 lines for a status window (screensplitje). Wich is quite exeptable don't you think.

Don't forget Herzog!