Tiled dynamic copperlist: feasible?

[saimon69]

Am copying this from the Final Fight thread;

My crazy idea is to change some of the colors according to a grid 8x8 made with the copper and dynamically allocated by the approximate position on screen of the bob (a bit like on the c64 and spectrum the attribute grid is changed dynamically) so that some enemies might have different colors like in the Capcom Arcade.

Why 8x8? To reduce copperlist changes and possibly create it dynamically - amiga copper has an horizontal step of 8 pixel; for the vertical just make an increment every 8

A similar technique was used in games like Lionheart or Turrican 3, albeit not that extensively: might create some color clash but is an interesting idea, just hope not too processor time consuming... by the way, if in a ZX spectrum the dynamic change is fast enough to simulate multicolor (nirvana engine), i guess on Amiga should be sorta feasible too (albeit in assembly, not in blitz basic or AMOS).

So i did create a mock-up image using one of the Street of Rage pictures by Mastar484, and considering the color 4 (pink) as dynamic.

Not the best in this sprite sheet, but if bobs are drawn assuming the color as changeable then look might improve.

The original sprite sheet:


How the grid might behave:


Copper replace color 4 according to the approximated to the top left margin of the8x8 grid tile coordinates of the several bobs on screen; if two bobs overlap, as visible, some clash might happen.
The grid is calculated according to bob positions and their attributed jolly color attributed to them.

If unoptimized copper might change color 4 40*24 times in a 1/50 second on PAL machines

Since am not a coder would love to know if something like this is technically feasible and usable.

[Shatterhand]

Just to be fair and give proper credit, that image was created by Mastar484, not me

This was the original thread created by him:

http://eab.abime.net/showthread.php?p=1109296

[saimon69]

ok i acknowledge that and i changed the credits.
By the way if you split the bobs as mentioned in the other thread the effect might be reduced too i guess

[chb]

I'm not completely sure what you want to gain by this technique. For a color change every 8 pixels you can not use more than 16 colors, so max 4 bitplanes. Also you need to change color 4 for every line - the Amiga has no per-char-attributes like Sinclair/C64. You can use copper loops to have a shorter copper list, but DMA will be the same - so all slots during display are used for copper and display, nothing left for blitter and cpu.

So why not use 32 or 64 colors from the start? Less dma, more colors (in 64 mode), no attribute clashes. I do not see any benefit for your idea.

What could work: if you have unused sprites, you can use them behind the playfield to color your bobs (color 0 in the bob will be replaced by sprite color). You have only 16 pix width, but maybe it's enough for some clever coloring of some bobs.

[saimon69]

The latter one you mentioned was another idea for some situations a la final fight where you have Poison and roxy with different hair colors, was not sure on how prioritize the two in case were almost overlapping though, unless set sprite depth accordingly - AND am afraid multiplexing is needed anyway

[mcgeezer]

Originally Posted by saimon69

Am copying this from the Final Fight thread;

My crazy idea is to change some of the colors according to a grid 8x8 made with the copper and dynamically allocated by the approximate position on screen of the bob (a bit like on the c64 and spectrum the attribute grid is changed dynamically) so that some enemies might have different colors like in the Capcom Arcade.

Why 8x8? To reduce copperlist changes and possibly create it dynamically - amiga copper has an horizontal step of 8 pixel; for the vertical just make an increment every 8

A similar technique was used in games like Lionheart or Turrican 3, albeit not that extensively: might create some color clash but is an interesting idea, just hope not too processor time consuming... by the way, if in a ZX spectrum the dynamic change is fast enough to simulate multicolor (nirvana engine), i guess on Amiga should be sorta feasible too (albeit in assembly, not in blitz basic or AMOS).

So i did create a mock-up image using one of the Street of Rage pictures by Mastar484, and considering the color 4 (pink) as dynamic.

Not the best in this sprite sheet, but if bobs are drawn assuming the color as changeable then look might improve.

The original sprite sheet:


How the grid might behave:


Copper replace color 4 according to the approximated to the top left margin of the8x8 grid tile coordinates of the several bobs on screen; if two bobs overlap, as visible, some clash might happen.
The grid is calculated according to bob positions and their attributed jolly color attributed to them.

If unoptimized copper might change color 4 40*24 times in a 1/50 second on PAL machines

Since am not a coder would love to know if something like this is technically feasible and usable.

I am by no means a master at coding on the Amiga, but in my opinion something like this is very very difficult.

Here's why.

The requirement as I understand it is to dynamically change the colour registers at 8 pixel boundaries in the display.

Horizontally there are 113 positions you can change a colour register which equates to every 4 pixels.

Now - if the requirement was to change just 1 colour register then that wouldn't be a problem, as a matter of fact we've seen it done in the past with plasma effects. But this needs to change more than one colour register, once you changed one colour register the beam position has then moved to the right so if you change the next register it will not take effect till later on in the scan line.

Theoretically if you were changing maybe six registers you could chase and sync with the beam - but I wouldn't want to code something like that, basically the cycle timing would need to be perfect.

In a nutshell, a very difficult thing to achieve.

Not something I would bother with trying but hopefully I've explained my thoughts... if any of the other coders want to chip in and correct or clarify my thoughts then I welcome it.

Cheers,
Geezer

[saimon69]

btw the idea was to have more enemy classes using the same sprite like in several capcom games with classes differentiated by a color change. Another contact of me was considering to do a beat em up on OCS/ECS (still at brainstorming phase) and wanted to find some ideas on how to have more colors on screen.

BTW mcgeezer, i remember powder coders telling me that OCS/ECS blitter had a 8 pixel horizontal resolution, since you did work with it can you confirm me that is instead 4px?

[saimon69]

Horizontally there are 113 positions you can change a colour register which equates to every 4 pixels.

Now - if the requirement was to change just 1 colour register then that wouldn't be a problem, as a matter of fact we've seen it done in the past with plasma effects. But this needs to change more than one colour register, once you changed one colour register the beam position has then moved to the right so if you change the next register it will not take effect till later on in the scan line.

Theoretically if you were changing maybe six registers you could chase and sync with the beam - but I wouldn't want to code something like that, basically the cycle timing would need to be perfect.

Yup, in my incompetency i though copper was THAT good :/