That's not the problem I describe here, mate... ;)

It's more about if the quality of graphics really scale with those extra 16 colours. In my case they don't (yet).

Nope, the 262144 colors come from the 18bit color depth you get in HAM8 (and for example on VGA). The amount of pixels on a PAL hires screen is higher (640x512=327680).

I never liked the HAM modes, so I never did anything with them. However, reading here prompted me to go a little deeper. Without giving the matter the thought it should, I'd say that HAM8 allows way more than 2^18 colors. If I'm wrong, no problem, just open my eyes ;) My reasoning goes as follows.

I guess that the 2^18 figure comes from the concept that by chain-modifying each channel one can obtain all the RGB combinations with a depth of 6 bit per channel -and that's correct, of course.
However, that does not take into account that the resolution of the 64 base colors is 24 bit, not 18 bit. Let's assume that all the channel values of the 64 base colors are not divideable by 4, i.e. they cannot be obtained by scaling 6 bit values to 8 bits values (e.g. $023375). Those colors are outside the 2^18 colors already counted. So, HAM offers at least 2^18 + 64 colors.
But there's more to it. Each of those 64 colors can be used to derive other colors by holding one of the channels and modifying the other two channels for a total of 2^6 * 2^6 = 2^12 times, and none of the derived colors would match the initial 2^18 colors, i.e. there are additional 64 * 2^12 = 2^16 colors.
In all, I'd say that HAM8 offers 2^18 + 2^16 + 2^4 = 327744 colors.

Regarding the color depth VS screen resolution matter, it has to be pointed out that 2^18 + 2^16 is exactly the already reported amount of pixels on a PAL HIRES interlaced screen - so, HAM can theoretically provide more colors than that. But interlacing means that those pixels are not actually shown at the same time, so a more appropriate comparison should be done with standard SHRES, which does have 327680 (= 1280x256) pixels on screen. The Amiga is capable of wider screens though, so screen resolution "wins" anyway.

EDIT (in order not to prolong the OT): the above was based on my wrong assumption that the 6 replacement bits would be taken as absolute channel value and mapped to [0, 255], but, as robinsonb5 points out below, they are simply used as the 6 most significant bits, while the 2 least significant ones are held. That invalidates my reasoning above - and proves I wasn't lying when I said I never worked with HAM :D See robinsonb5's post below. Thanks, robinsonb5.

Hopefully comprehensive answer:
* the palette is 24 bit;
* the number of colors of non-HAM AGA screen modes can be any power of 2 up to 256;
* HAM8 can provide up to 2^24 colors (see robinsonb5's post below);
* the standard dual playfield mode gives up to 31 colors + 1 transparent color;
* if not all 256 colors are used, sprites can add up to 15 more colors;
* the more colors, the more bitplanes are needed (color depth = number of bitplanes; e.g. 64 colors -> 6 bit depth -> 6 bitplanes needed), the more memory is needed;
* the Copper can dynamically change colors as the screen gets drawn, so visually the colors count can be much higher (which is what Metro Siege's developers are magistrally doing, as you can see from the screenshots they're posting here).

As you say, HAM8 can adjust the upper 6 bits of each channel's colour, with the two least signficant bits being inherited from the most recently used palette entry. Since there are 64 base palette entries, it's possible to have one palette entry for every possible combination of those two least significant bits across the three channels - which means that in HAM8 mode you can actually display any of the 16 million colours. You can't do it in a way that's generally useful, though. Picking a base colour because of its least significant bits rather than because it's vaguely near the colour you want to display is going to give... less than optimal results!

Might be time to move the OT discussion to a new thread?

Numbers (#) of the posts to be moved and new thread title please and one of us will take care of that when the opportunity arises.

I don’t think anything needs to be moved as some of the posts are still somewhat relevant, more if people want to continue the OT discussion, we should probably do it in a dedicated thread.

I hoped bitbeamcannon to release this during the covid.19 emergency :P

Unfortunately the lockdown slowed development a touch (home schooling etc) but the pace is now increasing again and we are making steady progress.

Not to say it's impossible, but I think it's very very difficult for any type of game that has moving objects using the full vertical width of the screen.
Which renders ye typical copper trickery useless.

I have tried for two years to get some variation into Inviyya with using dual playfield, but in the end it's just too limiting.


You are right.
Would be working with smaller games (like tiny galaga does for instance), usually you will be encountering a lot of bias here.

Amiga fans want their games to look, play and sound a certain way, that is something I learned.

If you deviate too far from that and try something more avantgarde, you will get a lot of flak.

Basically it really depends on the game. The specific trick we're using is only good for platformers, brawlers, beat'em'ups, horizontal shooters e.t.c. Not so good for vertical shooters, isometric or top down 8way scrollers (like a Zelda game or an RTS f.e.).

In regards to moving objects using the full vertical width is not so much of an issue, regarding you copperise colors not used by bobs. That's what we also do in Metro Siege, i.e. the 16 color palette is divided to colors used by everything and colors used by backgrounds only. And those we can heavilly and freely copperise. Optionally a couple common used colors as well but with very subtle color changes (so it's never noticeable).

Yup, for the style you're shooting at, I think dual playfield wouldn't cut it indeed.

That's true. But at the same time I think there hasn't been really many new Amiga games that attempt to do this properly. I.e. modern 8-bit looking PC indies actually do a heck of a lot more than what an actual game working on an 8-bit console would be able to do. That is really fast movement, a ton of objects on screen, a ton of particle effects, screen shakes, detailed and fluid animation with great feedback and other 'juicy' stuff.

I think the reason people embraced the recent galaga clone is that it indeed attempts and succeeds to replicate some of these tropes and tricks.

This.
Plus, novelty (regarding both the technical aspect and the gameplay) might even pass unnoticed or be totally misunderstood.

Yes, amigans want well established clichés, thats right.

On Topic.

@developers

I watched this video the other day:
https://youtu.be/xsLPmYss-cU?t=147

At 2:30, he is talking about grab move, and that is not automatically activated when getting close to the enemy, but instead, you need to push some buttons differently.
Did you decide yet what this combinations of the button is, and if yes, can you share with us?

Honestly, I've never experienced what he said in the video: Unwanted grab. Actually, I did, and lot's of time, but never bothered me, because throwing opponents after the grab, makes your character invincible for a short period of time. So, even a grab is by accident, it's no problem, if you react quickly.
For me personally, regular grab trigger would be just fine.

This is just a loud thought of mine. :)

The "grab attempt" is triggered by holding down the primary attack button and pressing the joystick "forwards" towards the enemy you want to try and grab.

Interesting, makes me wonder how the buttons are assigned. Are both buttons attack buttons? Or is one for jumping?

Well the controls are obviously quite complex as we have so many moves, but yes, from idle, the second button will jump, but in other situations this button will trigger other moves.

Of course, nothing is set in stone until the game is released, so I am only talking about how we are currently using it.

Here is a bit of trivia, the default player "Alex" currently has 482 animation frames, and in level 1 all characters combined have over 1800 animation frames. (Note: this includes the reversed frames, so the number of frames that have been created by the team is 1/2 that).

It's a pity that 3 button joysticks are so rare on the Amiga, sounds like you could've used an extra button or two ;)

Impressive number of animation frames there. Does that include the... Oh, I forgot how it was called in those streams I watched all that time ago... Let's say "smart" frames - where you're moving part of the object around rather than having separate frames for everything?

Thanks.
Well, that doesn't sound too complex. :D
I am just afraid (after watching the above video), that with (really great) innovations, you don't go to far from the feeling of playing some Capcom beat em up, that we all always wanted for the Amiga. :)

Wow!
Usually walk cycle in these games are something like 4-6 frames (If I am not mistaken), for arcade something like 10-12.
That's a LOT!

Keep up the great work!