To be honest, I would probably ditch the sty as well as the sun (in case it is not needed for something).

No, the sun isn't needed for anything: I just left it there for some cuteness. Indeed, I had already considered removing it to have more freedom with sky hues, but first I wanted to see how far I could go with it. Maybe it will go.
As for the whole sky, OK, I can remove it, but how can I fill that space, then?

BTW: forgot to say that the 4th row of characters (so, the 8-pixel band between the clouds and the topmost platforms) can only be painted in solid color.

The newest one you have there is just way too busy, I assume the player will go up there and be infront of all the busy stuff going on?

Yes, but it won't be a problem thanks to the outlines of "active" objects - if you want to try an earlier version for a better idea, get it from CSDb.

Also the gradient skye stuff does not look nice either. No need to emulate Amiga copperpuke skies.

Well, I didn't mean to mimic Amiga stuff - it's just that I couldn't figure out a way to fill the emptyness. I guess the problem is in dealing with clouds and sky background separately at conceptual level.

Otherwise this looks quite cute I have to say.

 

I appreciate the work gone into the skin, but I honestly can't say I'm pleased with the result: I'll eventually get used to the icons, the shapes and all, but for sure I won't get used to the background colors - as nice as they can be, to me their lack of hue neutrality will always alter the perception of the pixel art posted.
EDIT: also, as a simplicity and flatness lover, I'm not particularly fond of the shadows and of the depth of icons and frames - they only make the view unnecessarily more complicated to my eyes.

(Just my humble 2 cents.)

Yeah, I can imagine a few good examples, like how the tiles were gradient-hued in Lionheart on the first stage...

Definitely a good example, although, IMHO, negatively counter-balanced by the saturated purple of the sky - I'd wouldn't be surprised if the sky colors weren't chosen by Henk (and viceversa).

Great job, ptoing!

Just a few things about the Amiga...

12 bit RGB444 palette (4096 colours). This basically means you only have 16 instead of 256 choices per RGB channel.
On modern PCs this basically would be all values 00, 11, 22, 33, 44... up to FF.

000 ... FFF

Graphic Modes

There are 2 graphic modes in 2 subflavours.

Normal:
Lowres: 320x256 PAL / 320x200 NTSC - 32 colours
Highres: 640x256 PAL / 640x200 NTSC - 16 colours - tallpixels

Interlaced:
Lowres: 320x512 PAL / 320x400 NTSC - 32 colours - widepixels
Highres: 640x512 PAL / 640x400 NTSC - 16 colours
On the original machine the interlace modes flicker quite a bit unless flicker fixer hardware was installed.

Confusingly the modes are also often called: Lores, Medres, Interlaced and Hires.

There is something called Overscan which can achieve higher resolutions (wip)

Unfortunately things aren't that easy because the screen width/height is entirely programmable. The sizes you listed are just the most common ones, but the combinations possible are way too many to list (f.ex., nothing forbids creating a 336x267 screen, just to mention an odd one). Of course there were some limits, but sadly I can't remember them (too much time has passed) and it wouldn't be easy to describe them here anyway (just to give an idea: the left border could only vary between a certain range and at 8 or maybe 16 pixels multiples).

You were not totally incorrect, though, as modes do exist - it's just that they don't refer to the amount of pixels, but rather to the dimensions of the pixel itself:
 * LORES mode: 140 ns pixel, which is the biggest and most common one;
 * HIRES mode: 70 ns pixel, which is the kind of pixel here usually referred to with "tallpixel", since its height is twice its width (in practice, it's equivalent to a half LORES pixel);
 * interlace mode: activates the well-known odd/even-lines-only plus vertical offset effect to give the impression that the pixels height is half the normal size; it can combine freely with LORES and HIRES modes.

(The times expressed in ns refer to the time the raster beam takes to draw the pixel on screen.)

Another mode is the dual-playfield, which paired the even and odd bitplanes to form 2 overlayed, indipendent "screens", so the total amount of colors per "screen" is at most 8 for the background one and 7 (plus transparency) for the foreground one.

With the ECS/AGA chipsets things got even more complicated, but that's another story...

I am not sure if this wraps around scanlines, probably does.

I can't be 100% sure because I hated HAM and thus I never used it, but the memory of the very common tearing/bleeding problems of HAM suggests that it doesn't wrap around.


Then, let's not forget sprites
Here is some information:
 * there were 8 sprites, each of which had 3 colors + transparency;
 * each sprite could have a maximum width of... mmm... probably 16 pixels; height could be... lemme think... probably 256 pixels, but with vertical multiplexing the height could be virtually any;
 * sprites could be combined (by pairs: 0+1, 2+3, 4+5, 6+7) to form 15-color + transparency sprites;
 * if my memory doesn't fail me, colors were taken from these palette slots (sprites: colors): 0, 1: 17, 18, 19; ... 6, 7: 29, 31 (the pattern is: the colors from 16 to 31 are divided into banks of 4 colors, which are assigned progressively to the sprite pairs; the first color of each bank is irrelevant because of transparency); the AGA chipset had the ability to relocate the banks, but I can't remember whether it applied to OCS and ECS chipsets (probably no);

Finally, a little note: colors could be dinamically changed by the CPU or the Copper* so that the total amount of actually colors shown could be easily much higher than the number of colors in the palette. This is relevant to pixelling only when producing the graphics for a game or demo, of course.

*Actually this applies to most of the chipset registers, so that it was not uncommon having on the monitor multiple screen modes at once.