News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
T

Proof that the Commodre 64 palette is far superior to the Amstrad CPC.

Started by tastefulmrship, 16:24, 13 February 16

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Oliver Lindau

@andycadley
You can be sure that there was a wide, wide range of colour settings out there. One rather controversial project that is going on in the C64 world is is the community colours project by P1x3l.net. Controversial because of its approach creating a palette by collecting subjective user palettes and building an avarage value. Personally I am also mixed about the current status there because the colours are even more saturated than my approach (guess that people with unique settings are more motivated in partitipating than those who don't touch anything). I believe more in my own experiences and talks with people that were active in the 80ies and 90ies, which were mostly in the games industry and hardware nerds. And the usual conclusion is that there is no universal palette that does justice to all c64 setups and its graphics artists.



@ukmarkh
yes. The TV out is a league of its own including extreme black bleed and a desaturation effect by using big white areas. Fun fact is that I used two different screens in the early 90ies (no joke) one low saturated TV and the more saturated monitor. Still do using PEPTO instead of a telly nowadays.

||C|-|E||

I am quite impressed with this image.

[attachimg=1]

Could anyone enlighten me about how it was done? If there was a semi-automatic way to do this some games in Mode 1, like our adventure, could have truly amazing graphics in the future.

1024MAK

This thread appears to be going in circles now...


The debate about what the correct colours for the C64 are, is about much use as debating how pink or not, "white" people's skin should be on a 1980's colour TVs (what your preferred settings were for contrast, brightness and colour on the TV controls). I remember one nan liked the skin to be pinkish, while my Mum and Dad, and my other nan preferred a whiter colour.

So to be clear, IMHO any domestic composite TV system (including S-Video) does not have calibrated colours, saturation levels, or properly configured grey scales.

And also, for the record, analogue RGB also is not a fully calibrated system.

Mark
Looking forward to summer in Somerset :-)

Oliver Lindau

@||C|-|E||
Not sure what tools Rexbeng uses. In Grafx2 there is a effect called 'Sieve' that can draw with dithered patterns. Choose 'FX' and 'Sieve' - right click on Sieve and open the dither-design dialog. All tools work with the chosen foreground and background colour.

@1024MAK
Of course RGB is no fully calibrated standard. Still 16bit systems were definitely more practical for adjusting video systems than a more or less random 16 colour palette. But what you are saying is exactly what I mean. Those were analogue times. Everyone did what he thought was right with their screen. And from that point pictures also look different on each screen and leads to many individual palettes...

Fessor

A true NTSC-System...
Even in PAL-Region it has Never The Same Color...

invent

Quote from: ||C|-|E|| on 23:46, 18 February 16
I am quite impressed with this image.

[attachimg=1]

Could anyone enlighten me about how it was done? If there was a semi-automatic way to do this some games in Mode 1, like our adventure, could have truly amazing graphics in the future.


Hi ||C|-|E||, zooming into the image gives some clues, custom dithering and particular colours next to each other. While I can't think of an automatic way, if I was going to recreate this effect I would create custom patterns in Photoshop for example and fill in solid areas with the pattern (colour shade). Would need to create a set of patterns ranging in tone or spectrum of colours.  Look like an interesting challenge.  Very interesting technique which works best using primary colours for greatest range in colour spectrum if that's your intention (Red, Green , Blue and Black)
Enjoying/Creating Retro Games

1024MAK

Quote from: Fessor on 10:39, 19 February 16
A true NTSC-System...
Even in PAL-Region it has Never The Same Color...
Never Twice Same Color...
Looking forward to summer in Somerset :-)

1024MAK

Also, keep in mind that the 625 line system can use either PAL or NTSC colour encoding.
And the U.S. 525 line system can also use either PAL or NTSC colour encoding.
See Broadcast television systems - Wikipedia, the free encyclopedia

Mark
Looking forward to summer in Somerset :-)

||C|-|E||

Quote from: invent on 13:15, 19 February 16

Hi ||C|-|E||, zooming into the image gives some clues, custom dithering and particular colours next to each other. While I can't think of an automatic way, if I was going to recreate this effect I would create custom patterns in Photoshop for example and fill in solid areas with the pattern (colour shade). Would need to create a set of patterns ranging in tone or spectrum of colours.  Look like an interesting challenge.  Very interesting technique which works best using primary colours for greatest range in colour spectrum if that's your intention (Red, Green , Blue and Black)


I was thinking a little bit about that and I think that it should be possible to implement an automatic or semi-automatic conversion with a little bit of effort. It would be necessary to create a database with all the virtual colors you can get using dithering and then create a palette from it. Later, you would use that palette to draw your images using tiles of 2x2 pixels. Finally, the application would convert those patches to the dithered version and some manual adjustment would be required to remove the blocky aspect. The program could actually be more sophisticate and try to remove the blockiness by itself. In this case, you would draw the image in a normal way using the custom palette, then it would be converted to a blocky image made of tiles of 2x2 pixels, this image would be dithered automatically and, finally, we could refine it trying something like a Monte Carlo approach until we find the best correlation with the original thing you drew. Huum... I am probably saying just a bunch of stupid things  :picard:

ZbyniuR

Do you remember OverPixel ?  What is possible in 4 colors only.
JavaCPC Paint Overpixel effect (MODE 1, 4 colours)
Compress makes more colors but in reality there are only 4 CMYK colors mixed like pixels in printer.
In STARS, TREK is better than WARS.

MacDeath

But you can't do that on speccy or C64 because it needs to have more than 2 colours around themselves in small pixels...
:D

dithering is really important.


Also : NSFW

invent

Further experimenting with the 4 colour palette.
The 8 colour one below the original is only for reference (trying to use the full range of colour from the Amstrad palette, then reducing it down)



Enjoying/Creating Retro Games

Oliver Lindau

@MacDeath
Except using underlay sprite graphics modes on the C64... those are based on HiRes bitmap.
... but those are not appropiate for games. They need way too much ram and rastertime for this.


arnoldemu

I'm enjoying reading this thread :)

In the same way that some c64 pictures use sprites and heavy cpu use for display, we can also do the same on CPC :)

Sylvestre does a good job of investigating CPC possibilites:

Amstrad CPC - Les Sucres en Morceaux

nice pictures here:
Les Sucres en Morceaux - Demos en Sucre sur Amstrad CPC

Mode 5 can be used on cpc and that uses lots of cpu time. (it's mode 1, but with palette changes many times per line)

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Oliver Lindau

Quote from: arnoldemu on 11:25, 20 February 16
Mode 5 can be used on cpc and that uses lots of cpu time. (it's mode 1, but with palette changes many times per line)
That sounds similar to C64 NUFLI. Atari 8Bit has something like that too called Graph2Font, though normally the gfx artists use low resolution for that mode.

MacDeath

QuoteExcept using underlay sprite graphics modes on the C64... those are based on HiRes bitmap.
... but those are not appropiate for games. They need way too much ram and rastertime for this.
yes, you can "patch" the graphics with the hardsprites to add extra colours* where attributes wouldn't allow it.

But while CPC has far less colours on screen in Mode1, you cannnot apply Hardsprites on the whole screen I guess... especially in 384x256... (but Sprites can add graphic surface on the border, can't they ?)
otherwise, c64 sprites can be multiplexed so you can apply them on the whole screen height... this would get the whole pictures (+ the code for it) being far more heavy than the common 320x200+attributes.


anyway we are talking about pure graphic screens, not games...


The "mammouth" picture uses a lot of er... interuptions ? in order to manage some sort of colour change on the same line.
very CPU intense and need clever timing but can quite work for pure graphics.
Easier on PLUS and can be Sprite patched as well..

But still usable on simple CPC too actually.



yes, Supersly is one of Amstrad's graphical scientist and expermimental wizard.



* I meant extra brown and grey, of course...  :P


Anyway this thread needs more pictures...
Pic or it doesn't exist...








oops lol this is CGA graphics...  ;D

Seriously CGA graphics when done well could be quite nice.
Basically a shame CPC had more Spectrum graphics than real CGA graphics... and in 320x200x4... CPC is quite a superior CGA.
::)

slight mockup with some added rasters...
[attachimg=1]

Oliver Lindau

@MacDeath
NUFLI uses multiplexed x-stretched hardware sprites to cover the whole screen. Almost - because is uses FLI and on C64 the first 24 pixels cause something called FLI-bug, which means that colours cannot freely defined here and two sprites are used to cover this area. By definition this means that the last 8 pixels each line are bitmap-only. To make things more complicated - colours are split for the bitmap each regular line and for the sprites each irregular line.
Up and low border sprites are still possible in theory but haven't been seen in real life yet.

Border sprites is a similar concept, but esp side borders are tricky codewise. It is possible to get a similar effect like overscan pictures on the CPC, but actually it is playing with reduction. The demo Deus Ex Machina starts with a picture that is an interlaced fullscreen ifli covering the whole border, here it was the flicker that compensates stretched sprites. In others details are reduced to the 8-sprite-limitation per line. Some pictures implement rasterbar-effects to fill the gaps.


arnoldemu

It is true that for both machines the "default modes" are expanded with various techniques (rasters, sprites, overscan, interlace) to achieve much better images.

I think what is sad is there are much less people making graphics on CPC compared to C64.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

arnoldemu

Quote from: Oliver Lindau on 01:50, 21 February 16
Border sprites is a similar concept, but esp side borders are tricky codewise. It is possible to get a similar effect like overscan pictures on the CPC, but actually it is playing with reduction. The demo Deus Ex Machina starts with a picture that is an interlaced fullscreen ifli covering the whole border, here it was the flicker that compensates stretched sprites. In others details are reduced to the 8-sprite-limitation per line. Some pictures implement rasterbar-effects to fill the gaps.
@Oliver Lindau:

Is it true that on c64 to "open the borders" you must do something every line (just like on Atari ST with it's 50/60hz switch to open borders)?

I think in this respect the cpc is easier, because overscan be done with no cpu time, but at the expense of 22KB of RAM used for the display.


My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

MacDeath

Quote... in a .dsk!
thx for the attention but I guess it could be done a bit betterly, I mean the OCEAN logo could be more well done...
Can someone post it photographied from a real Hardware ?
or post the two versions ? would be great to compare...

the dude at ocean did quite an impressive job on this one and "(enter the) DragonNinja feat. Bruce almighty...

But as often, those intro pages wee limited, could really include some rasters of even bigger screen... damn 64k Tape configs...

QuoteI think in this respect the cpc is easier, because overscan be done with no cpu time, but at the expense of 22KB of RAM used for the display.
overscan/full screen on CPC is basically a hidden feature that manufacturer wasn't even aware of...
And yeah it can use quite a huge lot of RAM then...
22k ? may be something like 24k actually, if you consider 192x256x16...  that's 4x time what a monocolour screen on speccy would weight if you don't use attributes...
funnily many CPC games were in 256x192... but in Mode1.  :'(

Sykobee (Briggsy)

I'm loving the pictures and mockups and tweaks.


Big differences between loading screens and demo art, in my opinion. The latter can abuse everything because it can.


The former, well, it's a loading screen, so you can't rewrite the loading screen memory with game data without glitches or that final loading section blanking the screen. In addition, you don't have the freedom of CPU time, as CPU is used for loading and processing tape/disc data.


Which is why I think a loading screen using a few rasters is a decent achievement, even if it's not that insane MODE 5.

Apollo

While I have no quarrel with C64 but I think CPC is superior if used to the same extend as the C64. On the C64 it is much more common to use all kind of tricks to enhance it graphic capabilities while on the CPC it is very common to use the standard modes as they are.
So in the end most images on CPC are not as good as on the C64 because of lack of coding tricks used while there are plenty available and there are MUCH more GFX creators with much higher competition pressure in the C64 scene then it is on the CPC.

As example of an image with some code trickery on the CPC I want to show just this one from Kvety/LesSucresEnMorceaux :
[attach=2]
CPC - My beloved first computer!

MacDeath

QuoteThe former, well, it's a loading screen, so you can't rewrite the loading screen memory with game data without glitches or that final loading section blanking the screen. In addition, you don't have the freedom of CPU time, as CPU is used for loading and processing tape/disc data.
Most of this issue came from having games loading via Tapes... seriously with a disk, it doesn't quite matter to use  30-45 more seconds to load while displaying some rater effects.

also a game who will use 128K and Double buffering can quite use one bank or a bit more for a really fancy loading screen during... loading.


but some Amstrad loading screens were really well well done when they weren't just cheap ports from other systems.

Grim

Quote from: MacDeath on 19:39, 22 February 16seriously with a disk, it doesn't quite matter to use  30-45 more seconds to load while displaying some rater effects.
It's not really like the FDC/FDD will magically slow-down to accommodate some spare CPU cycles for "some raster effects". It's a little bit more complicated than that and a lot of work just for showing off once for a few seconds.

Powered by SMFPacks Menu Editor Mod