Plus on-screen colours

[Gryzor]

So, I've been reading conflicting info, even on our wiki - can the Plus range display 32 colours (no tricks involved) or only 16?

[gerald]

Something like  :
   17 for the screen + border in mode 0
+ 15 for the sprite
= 32

[Gryzor]

Ah, I had the sprite palette in mind, so this could be it. This is definite then?

[MacDeath]

yeah, every seems to forget the border is an additional colour on screen...

To do fullscreen means less colour... oh wait, it's a trick so it doesn't count.

[Gryzor]

So, if you have a static screen it's still 16+1, right?

[MacDeath]

well, also should speak about inks instead of colours... but yeah.

But Hardsprites can be overlayed on a static screen you know.



Anyway I think a game like Panza kick boxing on gx4000 easily go beyond 40 colours on screen, should re-verify...

[Sykobee (Briggsy)]

Yeah, I think you have to discount colour gradients that the Plus made easy when it comes to the basic colours on screen aspect. Just be aware of it when designing games.

[andycadley]

The usual mode restrictions apply, so 16 colours in mode 0, 4 in mode 1 and 2 in mode 2. Then on top of that you have the hardware sprites which are always 15 colours, regardless of mode or magnification. So that puts us up to 31/19/17 colours depending on the mode. If you want to count the border the it's 32/20/18.

On top of that, the Plus has a lot more capability in generating interrupts and such, so changing colours on specific screen lines is a lot easier. That, plus having a much larger choice of colours available means that putting 60-odd colours on screen isn't entirely out of the question. Obviously though you don't have complete freedom on where the colours are in those cases.

[Gryzor]

Thanks guys... I'm going to amend the article!

[Gryzor]

Ok, the reason I was asking was: Retrospecs - a retro camera for iOS!

Another question: how many colours can you get on a static interlaced image?

[andycadley]

Ah, I expect you'd have trouble using the hardware sprites effectively in an automated process like that. It's quite a quirky thing to optimize for.

As for interlacing, I don't know if there is a clear cut number. Whether colours blend el is a bit hit and miss and depends how much flicker is acceptable

[Gryzor]

Yeah, I figured that much but though that maybe it'd be like on the Amiga where the say they can display all 4k colours at once!

[andycadley]

I think @arnoldemu actually did manage that once. :-)

Not really a "picture" though. 

[Gryzor]

Something resembling noise, IIRC?

[Executioner]

Something resembling noise, IIRC?

Not noise, it's a nice colour gradient going through the RGB values across the screen and down. Has to update the palette continuously of course, and you couldn't really use the whole 4096 colours as much useful except a nice background, but it does prove that the full 4096 is possible.

[arnoldemu]

I think @arnoldemu actually did manage that once. :-)

Not really a "picture" though. 

http://www.cpc-power.com/index.php?page=detail&num=8308

all 4096 colours displayed, scroller made of hardware sprites.

Doesn't use screen split from what I can remember, and I never finished it so no sound.

[Gryzor]

Ohhh yes that one! Nice

[TFM]

Yeah, I figured that much but though that maybe it'd be like on the Amiga where the say they can display all 4k colours at once!

To show all Plus colors is no problem, showed that already 1992. You wait for the FRAME, wait a little more, the you do 16 times a inc hl while hl points to one color byte in RAM. So 16 colors per line. And you use 256 of them. But of course there is only about 15-20% CPU time left. Not much!!!

[Ast]

To show all Plus colors is no problem, showed that already 1992. You wait for the FRAME, wait a little more, the you do 16 times a inc hl while hl points to one color byte in RAM. So 16 colors per line. And you use 256 of them. But of course there is only about 15-20% CPU time left. Not much!!!

Euh, excuse me but, if you do 16 colors on 256 lines, you use 256*64 rasterlines. So we are far of 15-20% Cpu time Left. 

[TFM]

Calculation was 100/320*256 = 20. OK one has to code tricky of course. OK for demos, not easy for games (and probably not necessary anyway )

[Ast]

Sorry but i don't really understand what we are speaking of TFM?
Did you really speak of machine Times used in a raster of 256 lines? Because, in this case, your routine will take 16384 us.... It's more than 20% Cpu. As you know on cpc, you can only use 19968 us for 50 Hz screen, No more.
It takes appromatively 85% of cpu, not 15-20%.


1 rasterline-> 64 us
256 rasterlines -> 64*256=16384 us
312 rasterlines (1 vbl) -> 19968 us

Please explain me because i really don't understand... :-(

[TFM]

Uups. ok 300something

% free time = 100 - ( (100% / 312) * 256 )             roughly

So about 17,95% percent. must have pressed wrong key before.    We confused uses & free time I guess. 

[Ast]

Yes i believe about it..

[Executioner]

Since when is 17.95% not in the range 15-20%?

[Munchausen]

Since when is 17.95% not in the range 15-20%?

What he said