Plus on-screen colours

[TFM]

Relax guys, we just confused:
- Used CPU time
- Remaining CPU time


Actually, what's more important: How could we use such a 'super color mode' in a way which makes some sense.
New GFX modes to display pictures f.e. or a game with a loooot of split rasters?


Would be nice to do something for the Plus range. 

[Ast]

In my mind, for a beautiful picture, using mode 1 and changing all the 4 colours in each lines...


My idea :

Code Select Expand


; asic must be delocked to use Cpc+ extended palette
; give access to Cpc+ Feature by sending #b8 in #7f port to acces RMR2 Ram
; synchronized with vbl, halt, and some nops
; then Go on with
;
....
      Ld sp,#6406        ; Pen 3
      Ld hl,#aaa
      Push hl                ; transfert hl in Pen 3
      Ld hl,#888
      Push hl                ; transfert hl in Pen 2
      Ld hl,#444
      Push hl                ; transfert hl in Pen 1
      Ld hl,#000
      Push hl                ; transfert hl in Pen 0
; and so on....
; remember than :
; push hl takes 4 us
; ld hl,xxx takes 3 us
; ld sp,xxx also takes 3 us
; so to change all 4 inks in each lines it takes 30 us.
; So you have to wait for 34 us more to change
; the next colours in the next line.
......
       Ld sp,#6403
......etc...


[TFM]

Problem is that you already use the 30 ys of the 64 ys of one line.


I thought about a kind of a compiler, which changes only the needed inks when needed. This of course would need some kind of defined picture format.

[Ast]

Problem is that you already use the 30 ys of the 64 ys of one line.


I thought about a kind of a compiler, which changes only the needed inks when needed. This of course would need some kind of defined picture format.

That's right but, you also have 34 us free per line to put your routines... Here is the tips... Not filling the 34 us by writting some zeros but inserting your own routines during the 4 inks changing.
Solution 2 : using Playcity NMI to insert your Ink changing.

[TFM]

Both ideas are great. Eventually it depend what one really want's to do. 


PlayCity is not needed for Plus, it already got it's line interrupts. Well, maybe the NMI has some advantages though.

[Ast]

Ok, but what do we want to do?
What is the goal?
Using less time changing ink?
Remember demo which displayed really greats pictures playing sid music in the same time.
Remember sid musics take a lot of time when making sid Voices calculations.


So, what is the real goal with pictures with rasters? What is the idea?

[TFM]

That's the question! 

[andycadley]

The end goal is surely the display of things like photos better than a straight 16-colour conversion. I was having a think about this myself the other day as it happens.

[TFM]

Well, what's first? The idea or the tool? Probably it's the best if things do co-evolve.... I'm getting a Soda now 

[andycadley]

Well, what's first? The idea or the tool? Probably it's the best if things do co-evolve.... I'm getting a Soda now 

Well I think it's a matter of figuring out how many colours can be effectively changed per scanline (bearing in mind a full RGB change can't be done atomically) and then producing some code to optimize and generate what's required. It's an interesting problem and one which the C64 scene has done a lot of clever things with (mostly via interlacing on those machines, which is another option too).

[MacDeath]

I think real possibilities for Amstrad PLUS in Mode1+rasters can be inspired by some Atari 8bit works.

atari 8 bit was somewhat strange, they often couldn't get past the "CPC Mode3" as in 160x200x4... but because big palette and many rasters it could work.

best example :






Some atari 8bit demoes I saw recently released were a lot into "Mode3 pictures" which is somewhat fun as CPC/PLUS could do the same in 320x200x4, but well used, you can add in the sprites and many rasters and get nice results.

Here in PLUS we may produce same sort of things as "alternate reality : the city" but in Mode1 of course...

Alternate Reality: The City (1988) screenshots - MobyGames


Also imagine a "Fugitif" like game for the Plus...
http://www.cpc-power.com/index.php?page=detail&num=931




But attributes and constraints are difficult to work with...


Concerning Mode0 + rasters, the AppleIIgs was also a heavy "raster" user to get inspired from, I guess... could get 256 by screen with lines of 16 colours "only" (like 16 different palettes ?) so it was raster attributes. (bigger resolution though)

[TFM]

Well I think it's a matter of figuring out how many colours can be effectively changed per scanline (bearing in mind a full RGB change can't be done atomically) and then producing some code to optimize and generate what's required. It's an interesting problem and one which the C64 scene has done a lot of clever things with (mostly via interlacing on those machines, which is another option too).

Actually it's more about: Which color needs to be changed first in the scanline, which one second and so on... and then of course the limitations have to be considered in a program which is used to actually paint such a picture.

[Sykobee (Briggsy)]

Are we talking about a scheme like the "MODE 5" mechanism, although that is a picture viewer with inbuilt palette change logic.


In a game, interleaving the palette logic with the game logic would be ... tough. I agree that adventure games could benefit most.

[andycadley]

I was thinking only in terms of an image slideshow type of thing, where there would be a lot more scope for pre-processing the image and optimising the palette and changes. It'd probably be a bit too processor and memory intensive for anything but very simple games

[TFM]

Well, for games you could use it as Title screen (ok, not loading screen), as map, as menu (just scanning few keys don't need too much cpu time). Guess there are some options. 

[Ast]

Or use the remaining time to put your routines inside the raster's one. That's why i spoke about mode 1 screen. Changing all the 4 inks will only take 30 us for each lines.


There would be enough time to do something better than "keyboard scanning".

[arnoldemu]

I was thinking only in terms of an image slideshow type of thing, where there would be a lot more scope for pre-processing the image and optimising the palette and changes. It'd probably be a bit too processor and memory intensive for anything but very simple games

It is worth mentioning that if you change colours by writing to plus registers.
e.g.

ld hl,&f00
ld (&6400),hl

then you will see a transition where low byte is written then high byte.

So you need to plan for this.

[ZbyniuR]

As you probably know, ZX Spectrum can change attribute of colors enough often to show 2 different colors in every 8x2 pixels.

So how many times CPC can change all 4 colors in standard MODE 1 320x200 when just show picture?
How much processor power is need to change (for exemple) 2 colors every 16 pixel lines?
I can imagine how super pictures it can make it possible. Even in standard 27 colors.


Few years ago fans of Atari XE found way to display 32 colors at once with pixel wide like in MODE 0 on CPC. Yeah 5 bits for pixel in Overscan 192x240. And they have program on PC to convert graphic into this. I'm jealous. Here some pictures:

G2F
G2F COMPO

[Ast]

On cpc old, in mode 2 count every 32 pixels (1 out=4 us), on cpc plus every 16 pixels (ld (hl), a,b,c,d,h,l, 2 us).
So, you can change 16 times the same ink in one line on cpc old and 32 times on cpc plus.
Same times in mode 1. But you will have same colours using this way.

[andycadley]

The problem with answering that question is that the answer is always a bit misleading. So you can change a colour on an old school CPC every 32 mode 2 pixels, but that's excluding the setup time for changing which colour changes. On top of that you only have a few registers to preload values, so there are only a limited number of colours you can alternate between without spending time reloading registers.

Similarly the Plus machines can change a colour quicker, but it again ignores setup time and the fact the colour change isn't an arbitrary one. Not only do you have register limitations, but each colour is stored in two register so a change can only alter the green or the red/blue component of a colour at a time.

The one advantage the spectrum has in this regard is you can change the attributes ahead of time slightly and the change will only take affect at fixed points. On the CPC, by contrast, the change is immediate and so timing is even more critical.

[ZbyniuR]

So if I understand, every 4 byte sending from graphic memory to screen can be change 1 ink?

It sounds awesome! Better than I thought. It's much more then we need to display picture like on XE. Maybe even in MODE 1. Why we don't have similar converting program on PC, like for XE ?   For every lamers which want excite sweet like honey screens on CPC.

[Ast]

Extra coloured maker or Extra Ced Maker was doing to do that. Just have a look at AE 2010 demo i've made with Ced. I made a tool to use this extra feature.


Edit : after re-reading what i wrote, i found some errors so :


In mode 2, 1 out takes 8 mode 2 chars (64 pixels)
In mode 1, 4 mode 1 chars
----
Using Cpc+ colours
In mode 2, it takes 4 mode 2 chars (32 pixels)
In mode 1, 2 mode 1 chars.


Sorry for my mistakes...

[ZbyniuR]

Nice. Thank you for info.
Are you keeping in drawer this Extra Ced Maker, or can I found it in net?

[Ast]

You can't find it for now, but maybe i'll release a public version.
It's not a drawer program. You'll have to draw your gfx by yourself.(using iMPdraw v2 which is coming soon)
After your gfx was ready, you can use the ExtraCedMaker to add colours in your gfxs.

[ZbyniuR]

If you do that, God bless you.