Flip screens on CPC / Emulator

[Noncorpus]

I have been testing Screens and palettes on one of my 6128's though my Tape port, using Wav files.. and i have noticed that when you blend colours using software. it doesn't take the luminosity into account.
for example.. when you blend the first 2 inks.. black and blue.. you don't actually get something half way between the two.. because there is more light emitting from the blue than there is the black.. so it's not half way, but more closer to blue.. and because of this effect of the colour with the most light glowing taking over i feel it's possible that you could get more than 125 colours.. i will have to see if i can work out how it could be done.. i will probably have to mix in the grey values somehow


also i have been experimenting with double interlacing (horizontal and vertical) and with screens that have minimal dithering it works quite well.


i was a bit disappointed that my horizontal mode 0 dithering wasn't compatible with the interlacing. it made the screens flash more because of having horizontal lines 1 pixel thick in my original 125 colour pictures.. but that's ok i'll just save that for my 16 colour Overscan screens..


i also have made some 4 frame 2 colour gif type animations and got them to cycle in OCP Art Studio.. but wouldn't have a clue how to get them to cycle in basic.. it only works once i've loaded it back into OCP.. I also tried some disk which was an OCP screen viewer that loads the palette.. but it would only show the first frame
i guess i will have to just make a longer basic file which changes the colours manually.. it's hard to find information on colour cycling

[Noncorpus]

as soon as i get the ability to make my own palette file for the flip screens then i can run more tests that i have lined up.. i am currently running tests with the palette from image 4 of the flip test disk. and i have definitely noticed when i blend bright yellow and bright red it doesn't match orange like it's supposed to.. its actually a bright orange.. so hopefully i can get some interesting results which will be useful for more colours and more accuracy on original hardware

[Devilmarkus]

Hi Noncorpus,
any viewable test-results would be nice... (DSK?!?!?!)

[Noncorpus]

well here is a couple of tests.. they don't do the same thing on an emulator on the PC.


first i tested a 16 colour palette to see which colours would be good to use with minimal flicker. and i noticed the mix of bright yellow and bright red was half way between orange and the mix of orange and bright yellow.. but on the PC it just equals orange (also fiddled with brightness etc to see if i could make it look the same level as orange but couldn't).. also i noticed that the method of merging i used made it flicker a lot less than i expected..  still flickers a bit on an emulator..


so then i ran another test with a gradient through black,red,yellow,white and added an extra 3 shades to see if they fit in.. and they do.. but they flicker when they sit next to eachother


but yeah a lot of colour mixes don't appear the same from PC to the Amstrad..

[Devilmarkus]

Nice flipscreens...

I loaded them into JavaCPC with deinterlace filter enabled...

Results:

[redbox]

but yeah a lot of colour mixes don't appear the same from PC to the Amstrad..

Have you tried comparing the colours to the ones here: http://www.grimware.org/doku.php/documentations/devices/gatearray#inkr.color-codes

[Noncorpus]

Have you tried comparing the colours to the ones here: http://www.grimware.org/doku.php/documentations/devices/gatearray#inkr.color-codes

i'm not comparing the solid colours from amstrad to PC


it's the mixed colours that are identical on pc which have differences to each other on the amstrad.


what i mean is like how bright red and black mix to make the exact same shade as red (no.3) in the 125 colour palette from mixing the colours... well they don't on the amstrad.. you can see the dark red on the screen with the "bright red and black mix" looking half way between the dark red and the "bright red and dark red mix"


so what my point is.. there is more colours possible with flipscreens than i thought. and i'm gonna have to see if i can make an extended palette to work with to get my screens looking more accurate.. but will probably only look right on a CRT monitor

[Noncorpus]

Nice flipscreens...

I loaded them into JavaCPC with deinterlace filter enabled...

Results:

ahh.. yes i will have to try that on the javacpc emulator.. because i always thought there was only 125 possible colours.. this will help

[Noncorpus]

although the ones on that first screen.. the colours in the bottom left corner are a lot brighter on the amstrad.. because they are bright colours mixed with dark colours and the brighter ones take over a lot more

[Noncorpus]

Nice flipscreens...

I loaded them into JavaCPC with deinterlace filter enabled...

Results:

awesome.. that's 221 colours just from that 16 colour palette.. now i should be able to get my screens looking a bit better.

[Noncorpus]

awesome.. that's 221 colours just from that 16 colour palette.. now i should be able to get my screens looking a bit better.

oh.. nope.. some of them are dithered with a .1 color difference. will have to do a recount

[Noncorpus]

so.. what it was.. was i thought that the middle of the 3 rgb levels (0, 1, 2) was half way.. like 128/255.. which would make bright red and black equal the same shade as dark red.. but since dark red is lower than half way that make bright red and black mix brighter.. so yes your javacpc palette is more accurate than the standard half tones one

[Noncorpus]

have just worked it out.. there are 216 colours to choose from when making a flipscreen... not 125 like i originally thought

[arnoldemu]

Are you looking at the results on a real cpc with an amstrad colour monitor?

I know that some emulators do not have the correct palette - and you have found this to be true.

So, make it right on the real amstrad and us emulator author's will correct our emulators

[Sykobee (Briggsy)]

When I've been messing about with CPC graphics, I've been using 128 as the mid-shade. It seems this is too bright? What would be a better value?


I guess this could also change on a per-colour-component basis? e.g., Dark Red is { 112, 0, 0}, Dark Green is { 128, 0, 0 } and Dark Blue is { 96, 0, 0 }

Actually, there's probably a definitive palette on the wiki somewhere, let me take a look...
Hmm CPC Palette - CPCWiki suggests to use 127, any comments?

[Devilmarkus]

Once I connected my CPC with an Audio/Video grabber to my PC.

There I catched a screenshot showing the complete palette...

Then I measured the RGB values with a photo-editor and these are the results:

Code Select Expand

    protected static final int[] inkTranslateMeasured = {
        /*R G B */
        0x677867, /*13*/
        0x677867, /*27*/
        0x0FF878, /*19*/
        0xF8F865, /*25*/
        0x020850, /* 1*/
        0xEF186F, /* 7*/
        0x087067, /*10*/
        0xF8896F, /*16*/
        0xEF186F, /*28*/
        0xF8F865, /*29*/
        0xF8F821, /*24*/
        0xF7F8F8, /*26*/
        0xE81F13, /* 6*/
        0xF818F8, /* 8*/
        0xF88F07, /*15*/
        0xF889F8, /*17*/
        0x020850, /*30*/
        0x0FF878, /*31*/
        0x11F80E, /*18*/
        0x28F8F8, /*20*/
        0x000706, /* 0*/
        0x0A10D8, /* 2*/
        0x086F08, /* 9*/
        0x0F7EF8, /*11*/
        0x570F59, /* 4*/
        0x78F870, /*22*/
        0x80F80C, /*21*/
        0x79F8F8, /*23*/
        0x510F08, /* 3*/
        0x6011E8, /* 5*/
        0x677807, /*12*/
        0x6F7FF8 /*14*/
    };

The order is for hardware values! I added the INK values in /* .. */

Maybe that's helpful...

[SyX]

Or you can take a look to the work that Grimm has made in this area too

[Noncorpus]

yes i have looked at that.. but the problem is not really about what the standard amstrad colours are.. its more about what the false flip colours equal to the eye on the amstrad.. i have discovered this


i just used the standard 0,128,255 colour settings for this example.. as it doesn't really matter because it still makes the point





1. the top example is what the colour end up when you resample the dithering of the two colors.. similar effect to when you deinterlace on javacpc


2. the second (middle) example is when you set the red and blue half way between the brightness of the first example and the second example.. which is what appears on the cpc screen


3. is just a reference (see 2)


now that's why when my pictures look perfect on JavaCPC, they look terrible on my amstrad



i'll get there eventually.. now all i have to do is work out some kind of way of generating the whole false palette using that method instead of the resample method.. i may have to write the whole palette by hand yet. and it still may be more than 216 colours (or even less).. i have yet to find that out.

[Noncorpus]

Are you looking at the results on a real cpc with an amstrad colour monitor?

I know that some emulators do not have the correct palette - and you have found this to be true.

So, make it right on the real amstrad and us emulator author's will correct our emulators

yes.. this is about trying to make screens that look perfect on a real CPC
but not necessarily about the rgb values of the 27 CPC colours.. just the Flashing colours
but yes having the RGB values right is also essential.. but i'll leave that up to someone else.. lol

[Noncorpus]

i might have to work out what all this means.. when i got time.. lol
http://mcom.cit.ie/staff/Computing/CManning/comp6021/comp6021-13-exe1.pdf


i think that might help me with my tests


i gotta find a simple way of averaging the colours.. in a way similar to my example.. but once you get to the more complex colours it's not so simple to average them.. might have to use calculator

[pelrun]

Human vision is very non-linear; if you're alternating between a dark and bright colour fast enough then the eye will see the result as much closer to the bright colour. To have the appearance of the 'average' colour you would need to display the bright colour for only a small fraction of the overall cycle time - obviously not an option here.


Instead you'll have to change your averaging formula to a weighted average, giving more weight to brighter colours than darker ones.

[Noncorpus]

Human vision is very non-linear; if you're alternating between a dark and bright colour fast enough then the eye will see the result as much closer to the bright colour. To have the appearance of the 'average' colour you would need to display the bright colour for only a small fraction of the overall cycle time - obviously not an option here.


Instead you'll have to change your averaging formula to a weighted average, giving more weight to brighter colours than darker ones.

yes.. thats what i need.. i just worked out that half way between 127 blue and 127 red is not 63 or 96.. it turns out that 88 blue and 88 red is the best match..


but i didn't use calculator to do that.. instead i resampled the dither to 200% and then 25% size.. and it gave a brighter result than just going straight to 50%
so i should be able to build a whole palette (for converting images) quite fast that way..


some colours it make a slight difference but some it make a big difference.. i am now going to build a range of extended palettes based on each version of the CPC palette and it will be interesting to test them

[arnoldemu]

yes.. this is about trying to make screens that look perfect on a real CPC
but not necessarily about the rgb values of the 27 CPC colours.. just the Flashing colours
but yes having the RGB values right is also essential.. but i'll leave that up to someone else.. lol

Also done rely on "PAL" filters on emulators.

PAL for computers involves the following:
- R,G,B in the computer converted to PAL signal (Y,U,V)
- signal is passed down cable to television
- television converts Y,U,V to R,G,B

In addition with PAL there are blending artifacts between scanlines I believe.

With CPC you get:

- R,G,B from the computer direct into the monitor.

So test on real cpc colour monitor too

[Noncorpus]

Also done rely on "PAL" filters on emulators.

PAL for computers involves the following:
- R,G,B in the computer converted to PAL signal (Y,U,V)
- signal is passed down cable to television
- television converts Y,U,V to R,G,B

In addition with PAL there are blending artifacts between scanlines I believe.

With CPC you get:

- R,G,B from the computer direct into the monitor.

So test on real cpc colour monitor too

well.. it's not a real CPC monitor. but it is a Commodore monitor plugged directly into the Analog RGB 9-pin D-sub.. which is apparently more accurate than a CRT TV with SCART.. the colour knob doesn't effect the picture (which is good).. but i do have brightness and contrast instead of just brightness.
a bonus is i can change the screen height and width.. so i have it right to the edge and can see the entire screen.

all my amstrad monitors got stolen from someones storage a couple of years ago.
and i'm always on the look out for more Original monitors or other accurate monitor alternatives (with RGB)

[Noncorpus]

i would still like to be able to make my own binary file which sets the border and pen inks and then flips the screens after i have loaded them.. i have just been using a copy of one of the files off the fliptest disk.. and my choice of colours is very limited. that way i know i have done the best i can do if i get to choose my own set of inks to mix with... i thought it might have something to do with the flipscreen tool in JavaCPC Paint.. but all i can get that to do is make flipscreens.. i can't see any way of saving them in a way that has that .bin file with the pen and border ink settings..