5 bitplanes ...

[chadderack]

Forgive a little impertinence... I'm relatively unfamiliar with the nuances of the Amiga Hardware as of yet.

I'm working on a port of Black Tiger, and was thinking about how to manage the palettes among all the dependent objects such as the background and the BOB layer(s).

The original game used a 16bit indexed palette for everything which (in Amiga terms) seems to say 4 bitplanes.

Let's assume (for this discussion) I'm just talking about a single playfield. No dual playfield.

So...

Why not reserve the first 16 color indexes for map tiles/backgrounds/foregrounds and the next 16 (using a 5th bitplane) for characters and moving elements (BOBs?)

I'd been kind of reading here and there that the fewer bitplanes the better; however, Black Tiger with a dumbed down palette wouldn't be nearly as good looking.

I guess I'm just wondering if I dare enable the 5th bitplane and risk more processor time or if I should stay within the relatively "safe" 4-bitplane boundaries.

This game will have background music, sounds, and a scrolling map in addition to the usual enemies and player character.

I'm fuzzy on whether I could re-compute the palettes for the Copper so that the 5th bitplane (used only for moving elements/Bobs) could work without accidentally "animating" the background colors wherever a BOB (or player) exists. I've seen some pretty slick code for updating Copper lists on every vertical blank, so I assume that recomputing the screen palette (or just scrolling it) is very possible.

I'm thinking it would work fine. Black Tiger doesn't use unusual colors for HUD either.

What are the other considerations here?


Thanks!

Chad.

[jotd]

you can have 4 bitplanes and 32 colors if you use sprites. But sprites are limited. You can use sprites for the main character which is always displayed.

A lot of games are 16 colors only because they're lazy ST ports. But the 5th bitplane costs DMA (specially blitting). If you use interleaved bitplanes you have less / bigger blits so more time to do stuff with the CPU while waiting for blit to complete.

There are a lot of 32 color platform games on the amiga (Turrican, Ruff N Tumble). This is doable.

The thing with arcade games is that they don't care about/won't use dynamic copper effects. Amiga games can gain colors with copper effects, but an arcade game won't.

The palette can be changing between the levels. It's very common to change base colors for each level and keep some fixed colors for the main character / shots / bullets.

Gods has 16 colors but the palette slightly changes between levels (and also has copper gradients). Smart.

[chadderack]

Originally Posted by jotd

you can have 4 bitplanes and 32 colors if you use sprites. But sprites are limited. You can use sprites for the main character which is always displayed.

Amiga Hardware sprites... the _____ stepchild of Amiga graphics. (I've read as much). Will probably use sprites for something (maybe HUD?)

A lot of games are 16 colors only because they're lazy ST ports. But the 5th bitplane costs DMA (specially blitting). If you use interleaved bitplanes you have less / bigger blits so more time to do stuff with the CPU while waiting for blit to complete.

Yeah I was looking at some of phx's Solid Gold code and was surprised to see that it (apparently only) uses Copper scrolling(!). The Copper is one of the more unusual aspects of Amiga H.P. and I'm definitely thinking it will carry a large load of this new port. I assume the US Gold Black Tiger Amiga port had almost nothing to do with the Copper or copper lists.

There are a lot of 32 color platform games on the amiga (Turrican, Ruff N Tumble). This is doable.

The thing with arcade games is that they don't care about/won't use dynamic copper effects. Amiga games can gain colors with copper effects, but an arcade game won't.

The palette can be changing between the levels. It's very common to change base colors for each level and keep some fixed colors for the main character / shots / bullets.

Gods has 16 colors but the palette slightly changes between levels (and also has copper gradients). Smart.

Maybe I'm missing something fundamental here... but...

I was even thinking of changing the palettes during a level... even between frames... but just for the screen (scrolling edges) and (possibly) for the edge tiles around moving BOBs. That is, unless, that approach is overkill (or won't work).

I'd probably need to keep something like a conversion lookup table around to know how to re-assign bitplane 5 related colors so that the BOBs play nice with the background colors.

That might be way too processor intensive, though... considering that a modest BOB of maybe 32x32 pixels might have to have every pixel recomputed and then looked up and replaced in the bitplane 5 bits.

Or maybe I misunderstand something very fundamental here. I might make more hay just recomputing the palette for the entire level map PLUS the characters and see if we don't come in at 16 colors or less. Several of the background tile and object/sprite palettes from the original game share some colors.

Thank you for your response, jotd.

[saimon69]

Yeah, usually on OCS/ECS, if you don't want to go the dual playfield way (8+7), 16 colors are used for background and bobs and other 16 for sprites; OR some games reduce the horizontal size of the screen to have more bandwidth for handling 32 colors, like Toki or Ghosts 'n' Goblins; since i think you are targeting NTSC amigas first, i suppose you might have a bit of overhead from the 60hz but am not a coder...

[jotd]

I don't think changing the palette dynamically will work. The worst case could be: all tiles you have to display have more than 16/32 different colors, then you're stuck. It works if at some point of the level you enter in a room (so no scrolling) and the palette is different there.

Or use EHB but you have to compute your palette in a very smart way, and it adds another plane, oh my.

Or use 6 planes and AGA (careful: AGA doesn't solve everything. You get more colors, bigger sprites, but the blitter speed is the same as ECS which probably explains why not a lot of AGA arcade games have 256 colors / use 8 planes. Not sure it even 1 exists)

Real-life example: Supercars II is ECS and EHB. I added only ONE more plane for the AGA version, so I mutiplied the number of colors by 2 (64+simulated EHB). The result is good but game can be slow at times depending on the HW. And it's only 7 bitplanes. Ok that's not your question

A lot of superb technical stuff seen on original amiga (or atari) games won't apply here because Black Tiger hardware just doesn't need to use copper/palette tricks. It's a 1987 game with a hardware far superior to amiga ECS. So maybe choose AGA, like mcgeezer did for 1986 and seemingly not-that-impressive Rygar (where an ECS attempt was started & given up!!) and get the colors (& bigger sprites!!) that you need.

From 1986 (IMHO) arcade games beat up ECS hardware to a pulp. Everything pre-1986 can be covered with ECS. After that date, it depends. There are very good efforts, but with compromises (Pang, Slkworm, Rodland, Mortal Kombat). And Black Tiger seems to be even more demanding than Rygar.

[chadderack]

Originally Posted by jotd

I don't think changing the palette dynamically will work. The worst case could be: all tiles you have to display have more than 16/32 different colors, then you're stuck. It works if at some point of the level you enter in a room (so no scrolling) and the palette is different there.

Figured it might be something like that. Consider that just moving a BOB one pixel in any direction would re-combine all 5 bitplanes in such a way that everything the BOB touches changes color in some way... so every bitplane pixel for that BOB would need replaced.

Or use EHB but you have to compute your palette in a very smart way, and it adds another plane, oh my.

Or use 6 planes and AGA (careful: AGA doesn't solve everything. You get more colors, bigger sprites, but the blitter speed is the same as ECS which probably explains why not a lot of AGA arcade games have 256 colors / use 8 planes. Not sure it even 1 exists)

I'll keep all options open.

Real-life example: Supercars II is ECS and EHB. I added only ONE more plane for the AGA version, so I mutiplied the number of colors by 2 (64+simulated EHB). The result is good but game can be slow at times depending on the HW. And it's only 7 bitplanes. Ok that's not your question

A lot of superb technical stuff seen on original amiga (or atari) games won't apply here because Black Tiger hardware just doesn't need to use copper/palette tricks. It's a 1987 game with a hardware far superior to amiga ECS.

An arcade game--even in 1987--could add as many chips and PCBs as they needed. Need sound? Add a chip. Need more graphics? Add a chip. And a custom PCB would be created to help the chips communicate. Several megabytes of graphics and sound data could simply live on ROM and be called up in an instant. So this is the case where several beefed-up Z80s and a custom PCB kicks the stuffing out of a 16/32 bit 68000 and three custom Amiga chips.

So maybe choose AGA, like mcgeezer did for 1986 and seemingly not-that-impressive Rygar (where an ECS attempt was started & given up!!) and get the colors (& bigger sprites!!) that you need.

From 1986 (IMHO) arcade games beat up ECS hardware to a pulp. Everything pre-1986 can be covered with ECS. After that date, it depends. There are very good efforts, but with compromises (Pang, Slkworm, Rodland, Mortal Kombat). And Black Tiger seems to be even more demanding than Rygar.

Yeah, just trying to give it the engineering effort required. The fantasy is to create a game that plays just like the arcade game, looks just like it, sounds just like it... with every ounce of juice squeezed out of the Amiga 500 with 512K expansion.

If nothing else, I'll discover much more about the limitations and learn some creative approaches to solving Amiga HW problems.

[jotd]

Figured it might be something like that. Consider that just moving a BOB one pixel in any direction would re-combine all 5 bitplanes in such a way that everything the BOB touches changes color in some way... so every bitplane pixel for that BOB would need replaced.

Yeah, frustrating ain't it?

one game where I could leverage the different bitplanes is Pacman. With clever color choice you can write only on some bitplanes, saving bandwidth. But the colors are very simple, unlike Black Tiger, so that isn't going to work here.

Good luck with the project! (and use AGA )

[saimon69]

But..But...MY OCS!!!11
[ok, kidding!
However the old port was graphically not THAT bad hence is doable in 16 colors plus 16 for the player sprite; i would however give up the 'arcade perfect' idea on non-AGA machines]

[Muzza]

Originally Posted by jotd

There are a lot of 32 color platform games on the amiga (Turrican, Ruff N Tumble). This is doable.

Turrican 1/2 use 4 bitplanes (with HW sprites for the player)

[chadderack]

Originally Posted by saimon69

But..But...MY OCS!!!11
[ok, kidding!
However the old port was graphically not THAT bad hence is doable in 16 colors plus 16 for the player sprite; i would however give up the 'arcade perfect' idea on non-AGA machines]

Two playfields and three bitplanes a piece (interleaved) sounds easier in terms of getting background and objects to play nice... but it would mean only 8 colors per tile.

Originally Posted by Muzza

Turrican 1/2 use 4 bitplanes (with HW sprites for the player)

Maybe sprites can work for all of the player stuff (or even some enemies?) I've just seen people get frustrated trying to get much good use out of them.

[Muzza]

Originally Posted by chadderack

Maybe sprites can work for all of the player stuff (or even some enemies?) I've just seen people get frustrated trying to get much good use out of them.

Their limitations are frustrating to say the least. Using them for the player is often a good idea because typically:
A) Player is always on-screen, so the speed benefit of not needing the blitter is constant.
B) Player is always the focus, so the extra 16 colours go to good use.
C) There is only one player, so you can create a fixed budget for the sprite allocations, which simplifies things.

[redblade]

check out www.codetapper.com for some technical information on programming techniques on how they used sprites overlay and reused the colour palette. Because you are from UT are you aiming for a NTSC Amiga?

[saimon69]

Originally Posted by chadderack

Maybe sprites can work for all of the player stuff (or even some enemies?) I've just seen people get frustrated trying to get much good use out of them.

Well that was my proposal: four bitplanes for background and enemies and 16 color sprites for player (for weapons you could use well crafted 3 color sprites)

[pink^abyss]

I think the arcade hardware uses a resolution of 256x224. My Gradius port 'Tinyus' also used that resolution and had 5 bitplanes at 50fps. I guess a port would run fine on A500, even without using sprites at all (except for the HUD). 32 colors would make it much easier to be on par with the arcade gfx.

[chadderack]

Originally Posted by Muzza

Their limitations are frustrating to say the least. Using them for the player is often a good idea because typically:
A) Player is always on-screen, so the speed benefit of not needing the blitter is constant.
B) Player is always the focus, so the extra 16 colours go to good use.
C) There is only one player, so you can create a fixed budget for the sprite allocations, which simplifies things.

This might just work. The player's weapon (including all sections of the chain) shares the palette with the player, too.

Originally Posted by redblade

check out www.codetapper.com for some technical information on programming techniques on how they used sprites overlay and reused the colour palette. Because you are from UT are you aiming for a NTSC Amiga?

Thanks for the link. RE: NTSC... good question. My original intention was to do something nice for that A500 that has been patiently waiting in its box in my garage (or in other various places) for 33 years That would mean NTSC, but I'm open to doing it in such a way that all I can do is run it in an emulator. It won't be as much fun... but hey. Maybe I should buy a used Amiga 2500?

Originally Posted by saimon69

Well that was my proposal: four bitplanes for background and enemies and 16 color sprites for player (for weapons you could use well crafted 3 color sprites)

It was a good suggestion

Originally Posted by pink^abyss

I think the arcade hardware uses a resolution of 256x224.

That is correct... but I can even save a row of tiles at the top... since the top 16 pixel lines are devoted to HUD (no map in the background). 16x13 (in terms of tile blocks).

My Gradius port 'Tinyus' also used that resolution and had 5 bitplanes at 50fps. I guess a port would run fine on A500, even without using sprites at all (except for the HUD). 32 colors would make it much easier to be on par with the arcade gfx.

That sounds perfect. Is your source code available? If so, could I check it out please? Thanks

[pink^abyss]

Originally Posted by chadderack

That sounds perfect. Is your source code available? If so, could I check it out please? Thanks

No source, but there is a tech thread about the game here at EAB. There are most details explained. There is also another tech thread about my game "Tiny Bobble" which is also running at 5 planes@ 50fps (tho this has no scrolling most of the time).

Using 5 planes will also make it a bit harder because your run even more quickly out of chipmem. You will need ~138kb chipmem for your screen+scrolling. This leaves around 300kb chipmem (when you start from CLI) for audio, bobs and sprites. A good idea is to have the player anims in slowmem and copy them on demand to a single chipmem buffer.

[chadderack]

Originally Posted by pink^abyss

No source, but there is a tech thread about the game here at EAB. There are most details explained. There is also another tech thread about my game "Tiny Bobble" which is also running at 5 planes@ 50fps (tho this has no scrolling most of the time).

Using 5 planes will also make it a bit harder because your run even more quickly out of chipmem. You will need ~138kb chipmem for your screen+scrolling. This leaves around 300kb chipmem (when you start from CLI) for audio, bobs and sprites. A good idea is to have the player anims in slowmem and copy them on demand to a single chipmem buffer.

Cool. Thank you. I'll read up.

[saimon69]

Originally Posted by pink^abyss

Using 5 planes will also make it a bit harder because your run even more quickly out of chipmem. You will need ~138kb chipmem for your screen+scrolling. This leaves around 300kb chipmem (when you start from CLI) for audio, bobs and sprites. A good idea is to have the player anims in slowmem and copy them on demand to a single chipmem buffer.

Makes the YM emulation or Pretracker use almost a must with so little chip RAM left

[pink^abyss]

Originally Posted by saimon69

Makes the YM emulation or Pretracker use almost a must with so less chip RAM left

I quickly listened to the level tunes on YouTube to hear if its possible. It sounds like they could be almost 1:1 emulated in PreTracker with a 3 voices +1 echo/sfx voice setup. If the chords are omitted, that are used in a few songs, then the soundtrack (+sfx) should take around 8kb chipram and around 20kb slowmem. The songs could be converted to Pretracker by:
- converting the VGM tracks to midi (with 'vgm2mid')
- then convert midi to XM with BeroTracker
- use FT2 to clean the XM tracks and reduce them to 3 channels
- save them to 4chn tracker format and import into PreTracker subsongs
- recreate the instruments in Pretracker and give some polish
(note: PreTracker with soundFx playback and subSongs is not yet released)

[saimon69]

Little problem is that if you remove the chords you effectiverly remove the soundtrack; some songs are indeed chords heavy -_-