Video Modes - RGB

[sigh]

http://www.cpcwiki.eu/index.php/Video_modes

Do you think that we could also put the RGB numbers next to the colours? This can come in handy if your monitor isn't calibrated properly and your looking to do some graphics and need to make sure that the values are correct. For the graphics I am doing for the beatem up, mine were out by a few numbers.

0 0 128
0 0 255
128 0 0
128 0 128
128 0 255
255 0 0
255 0 128
255 0 255
0 128 0
0 128 128
0 128 255
128 128 0
128 128 128
128 128 255
255 128 0
255 128 128
255 128 255
0 255 0
0 255 128
0 255 255
128 255 0
128 255 128
128 255 255
255 255 0
255 255 128
255 255 255
0 0 0

192 192 192

*I still find it interesting that apart from the 192 grey, the CPC palette only has 3 values - 0, 128 and 255, in different orders to complete it's palette range.

[redbox]

Do you think that we could also put the RGB numbers next to the colours? This can come in handy if your monitor isn't calibrated properly and your looking to do some graphics and need to make sure that the values are correct. For the graphics I was doing for the beatem up, mine were out by a few numbers.

I think that's a good idea.  RGB in hex would be helpful too (e.g. 255 255 0 is #FFFF00 etc).

[TFM]

Good idea!

[MacDeath]

This is an old page I did ... but my knowlegde is not the best...

I want to add the way graphic datas are understood by the CPC for each modes...

=what bit in a byte are used for each pixels...

The colour values is something actually not that usefull exept to emulate the CPC palette...
But the Graphic "format" of Datas is actually quite usefull.

Well, the Superwonderboy topic highlighted this to me...


Ok I can edit the chart, just need to find a model/source because i'm lazy... ...


Also, what is this 192 grey



Post Edit :
Ok, done...
I used the 127 value instead of the 128...
Why ? because I always set my CPC monitor a bit darker  so I can get dark black on it...

[sigh]

This is an old page I did ... but my knowlegde is not the best...

I want to add the way graphic datas are understood by the CPC for each modes...

=what bit in a byte are used for each pixels...

The colour values is something actually not that usefull exept to emulate the CPC palette...
But the Graphic "format" of Datas is actually quite usefull.

Well, the Superwonderboy topic highlighted this to me...


Ok I can edit the chart, just need to find a model/source because i'm lazy... ...


Also, what is this 192 grey



Post Edit :
Ok, done...
I used the 127 value instead of the 128...
Why ? because I always set my CPC monitor a bit darker  so I can get dark black on it...

Thanks, although it's now getting a little confusing with the 127. I copied and pasted your cube palette and palette ditherings into my graphics package (PSP) and they read as 128. Do you think we could just use one or the other to make it more clear? Now I'm wondering if I should change the graphics in my game to 127 numbers(?) -  because the CPC is surely only going to accept one or the other?

Also in your notes you've put that your using the 127 number on an actual 128 colour(?).

The 192 grey, I think is linked to the borders.

I'm just thinking that if I were a newcomer, I would still be confused in which values to go by. I may even end up mixing the different values such as using 0,128,255 and 0,127,255 on the same screen. Would the CPC accept that? If so, then that's fine.

[MacDeath]

Oops, perhaps I did them in a past when I was in 128 config instead...


Any way those values are just for "emulation" of the CPC palette on modern computers (in true colours most of time).

A CPC doesn'y even care...
You inbstruc it to set ink2 (so Mode 0 or 1) with colour  number 6 (firmware colour number : bright Red) per exemple, and he do it and know exactly what he must display on its screen...

which would slightly vary from monitor/CPC to Monitor/CPC yet.

But we will clearly see the difference between the Bright red and all other colours from the palette, Purple (7) and Magenta ( being the closest ones.

[sigh]

Okay. But just to keep things clean, do you reckon you could just put the 127 back to 128 so it corresponds nicely with the actual colours being shown please?

[MacDeath]

Well, if you want...


Done.
I clarified the thing.

[sigh]

Thank you

Edit:

Thanks! I like the expanded extra information too.

[sigh]

I was wondering if there were any RGB numbers for the 16 colour hardware sprites of the PLUS machines? I've never seen the palette.

[redbox]

I was wondering if there were any RGB numbers for the 16 colour hardware sprites of the PLUS machines? I've never seen the palette.

It's a 12-bit RGB palette, the same as the Amiga.

[sigh]

It's a 12-bit RGB palette, the same as the Amiga.

Ahhh - my mistake. I though it was a dedicated 16 colour only palette for the hardware sprites. I didn't know that you could choose any 16 from the 4096.

[redbox]

Ahhh - my mistake. I though it was a dedicated 16 colour only palette for the hardware sprites. I didn't know that you could choose any 16 from the 4096.

Yes, you can choose any 15 (pen 0 is always transparent) for the hardware sprites and a different 16 for the rest of the screen.

[sigh]

I presume that this is only for mode 0? Do the same principles for hardware sprites apply to the other modes?

[arnoldemu]

I presume that this is only for mode 0? Do the same principles for hardware sprites apply to the other modes?

For mode 0:
16 colours out of 4096 for screen pixels
15 colours out of 4096 for sprites

for mode 1:
4 colours out of 4096 for screen pixels
15 colours out of 4096 for sprites

for mode 2:
2 colours out of 4096 for screen pixels
15 colours out of 4096 for sprites

So the sprites are independent of the screen mode.

sprite x magnification 1 -> mode 2 resolution
sprite x magnification 2 -> mode 1 resolution
sprite x magnification 4 -> mode 0 resolution

always 16x16 pixels, but can be magnified in x and y.

EDIT: I even made a program that can display a small picture using just sprites (4 sprites horizontally, 4 vertically, x2 magnification).
The result was nice. I got 16 colours in mode 1 resolution (pity i could not cover the whole screen )

[redbox]

for mode 1:
4 colours out of 4096 for screen pixels
15 colours out of 4096 for sprites

Which makes for a nice and hardly used Plus setup, IMO.


You can also have screen splits pretty much anywhere you want on the Plus, so the 4 background colours could be changed several times down the screen.

[sigh]

16 colours in mode 1 is fantastic! It's nice to know that we can now have hi res sprites in 15 colours! Would it be possible to add this information to the cpcwiki on video modes?

[arnoldemu]

16 colours in mode 1 is fantastic! It's nice to know that we can now have hi res sprites in 15 colours! Would it be possible to add this information to the cpcwiki on video modes?

you can use sprites to make a picture, but it's dimensions are limited. So you can't have mode 1 in 16 colours accross the entire display.
The dimensions are dependant on how you choose to put together the 16 sprites.
4x4, 8x2, 2x8 etc.

[sigh]

you can use sprites to make a picture, but it's dimensions are limited. So you can't have mode 1 in 16 colours accross the entire display.
The dimensions are dependant on how you choose to put together the 16 sprites.
4x4, 8x2, 2x8 etc.

So if I wanted to create a 16 colour character in mode 1, 32x32 taking up 4 hardware sprites(16X16). This wouldn't be possible?

[arnoldemu]

So if I wanted to create a 16 colour character in mode 1, 32x32 taking up 4 hardware sprites(16X16). This wouldn't be possible?

Yes that's possible.

Sprites don't have a mode, just a magnification.
So you're talking about sprite, 32x32 using 4 sprites, with x2 magnification in x and x1 magnification in y.
So it has the same pixel resolution as mode 1.

No problem.

[sigh]

Yes - I was hoping that the pixel resolution would be the same (hi res). I take it that no games used this method in the short lived PLUS

[redbox]

Yes - I was hoping that the pixel resolution would be the same (hi res). I take it that no games used this method in the short lived PLUS

It is - think of a hardware sprite as 16x16 in MODE 1 with 15 colours.

What arnoldemu is saying is that you can alter the X and Y magnification.  For example, if you magnified X by 2 the hardware sprite would look like MODE 0 (double pixels).  If you halved X, it would look like MODE 2.  But it's still a 16x16 sprite.

For my Xmas 2010 demo I used hardware sprites (for the scroller) in the MODE 1 magnification against a MODE 0 background, all using the Plus palette.

[sigh]

I understood the information that arnoldemu gave. Sorry, I didn't explain myself properly on that last comment . I'll take a look at your demo.

[MacDeath]

Hardware sprites are most often quite independant from the usual display mode.

And it is exactly the case on Amstrad PLUS.

it's like some additionnal layer added on the normal screen...

The result was nice. I got 16 colours in mode 1 resolution (pity i could not cover the whole screen )

Well, other "solution exist...

-use a normal Mode1 screen with a lot of raster colour changes... and patches with Hardsprites on few details...
You can really get some nice colourfull feeling...

-use a full screen Mode0 in 2x2 pixels equivalent (square mode0... 1x2 pix actually)...
Then also add Rasters colour changes and sprites patches... you can even go up to 256colours perhaps if the design goes well with this technique.




Those are ported from some Neogeo Pocket Color portable console which is supposed to be 160x100 resolution...
Those ports are done in CPC (old) palette and show that a real 16 colour mode with square pixels is somewhat the thing that CPC missed cruelly...

If only CRTC+GA could get some overclocking...

anyway CPC and PLUS can actually have some "decent" square pixel 16 colour mode...
Provided you simply artificially divide the vertical resolution by 2.

while a 128x192 (Speccy) mode0 looks blocky.
perhaps a 160x200= 160x100 may actually give good result (even better in full screen then...) as you mix both square pixels (despite big...) AND 16 colours.


I also think it may even be possible to get some display routine that would enable to get this kind of graphics stored at half DATA weight...
Just get the routine to copy each lines twice in "VRAM"...

There you are, your 16K picture only need 8K to be stored in RAM (not VRAM) and said routine to be displayed.

As a result to store a complete fullscreen picture needs only (uncompressed) 12K instead of 24K.


Does some of you knows if such routine is easy or hard on CPU ?
Also, is it big in RAM ?


BTW the 16 Hardsprites of PLUS are always some kind of...disapointing.
it would have been so sweet if 32 were available...(MSX style...)
Also it seems they are designed as 256 colour sprites, but only use 16 probably because the ASIC had not enough spare room for 256 ink slots...



But hey... they exist and enable sweet graphics.

And "simple games" like LALA prologue and so on (Mojontwins...) may get good use of them IMO.

[HAL6128]

For mode 0:
16 colours out of 4096 for screen pixels
15 colours out of 4096 for sprites

for mode 1:
4 colours out of 4096 for screen pixels
15 colours out of 4096 for sprites

for mode 2:
2 colours out of 4096 for screen pixels
15 colours out of 4096 for sprites

I'm a technical newbie and just an old-generation cpc user. But... how is it possible to create a sprite with 15 colors in mode 2/1. (Is it the ability to use more RAM for storing color informations?) What are the technical difference between plus and old?