So, I've been reading conflicting info, even on our wiki - can the Plus range display 32 colours (no tricks involved) or only 16?
Something like :
17 for the screen + border in mode 0
+ 15 for the sprite
= 32
Ah, I had the sprite palette in mind, so this could be it. This is definite then?
yeah, every seems to forget the border is an additional colour on screen... :laugh:
To do fullscreen means less colour... oh wait, it's a trick so it doesn't count.
So, if you have a static screen it's still 16+1, right?
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...
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.
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.
Thanks guys... I'm going to amend the article!
Ok, the reason I was asking was: Retrospecs - a retro camera for iOS! (http://www.cpcwiki.eu/forum/other-retro/8bit-artwork-a-retro-camera-for-ios!/)
Another question: how many colours can you get on a static interlaced image?
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
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!
I think @arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122) actually did manage that once. :-)
Not really a "picture" though. :laugh:
Something resembling noise, IIRC?
Quote from: Gryzor on 17:41, 08 February 15
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.
Quote from: andycadley on 17:33, 08 February 15
I think @arnoldemu (http://www.cpcwiki.eu/forum/index.php?action=profile;u=122) actually did manage that once. :-)
Not really a "picture" though. :laugh:
http://www.cpc-power.com/index.php?page=detail&num=8308 (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.
Ohhh yes that one! Nice :)
Quote from: Gryzor on 15:45, 08 February 15
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!!!
Quote from: TFM on 21:56, 09 February 15
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. :-\
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 :))
Sorry but i don't really understand what we are speaking of TFM? :laugh:
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... :-(
Uups. ok 300something
% free time = 100 - ( (100% / 312) * 256 ) roughly
So about 17,95% percent. must have pressed wrong key before. :laugh: We confused uses & free time I guess. :)
Yes i believe about it.. :P
Since when is 17.95% not in the range 15-20%?
Quote from: Executioner on 11:22, 10 February 15
Since when is 17.95% not in the range 15-20%?
What he said :)
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. :) :) :)
In my mind, for a beautiful picture, using mode 1 and changing all the 4 colours in each lines...
My idea :
; 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...
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.
Quote from: TFM on 18:03, 10 February 15
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.
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.
Ok, but what do we want to do? :P
What is the goal?
Using less time changing ink?
Remember KillMax (https://m.youtube.com/watch?v=Z4vp-k69Vsc) 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?
That's the question! :laugh:
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.
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 :laugh:
Quote from: TFM on 20:34, 10 February 15
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 :laugh:
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).
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 :
(http://www.mobygames.com/images/shots/l/150226-alternate-reality-the-city-atari-8-bit-screenshot-outside.png)
(http://www.mobygames.com/images/shots/l/150227-alternate-reality-the-city-atari-8-bit-screenshot-one-of-the.png)
(http://www.mobygames.com/images/shots/l/150225-alternate-reality-the-city-atari-8-bit-screenshot-determining.png)
(http://www.mobygames.com/images/shots/l/150223-alternate-reality-the-city-atari-8-bit-screenshot-alien-ship.png)
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 (http://www.mobygames.com/game/alternate-reality-the-city/screenshots)
Also imagine a "Fugitif" like game for the Plus...
http://www.cpc-power.com/index.php?page=detail&num=931 (http://www.cpc-power.com/index.php?page=detail&num=931)
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=931&slot=6&part=A&type=.png)
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=931&slot=5&part=A&type=.png)
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=931&slot=2&part=A&type=.png)
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)
Quote from: andycadley on 00:53, 11 February 15
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.
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.
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
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. :)
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".
Quote from: andycadley on 21:24, 11 February 15
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.
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 (http://g2f.atari8.info/gallery/index.html)
G2F COMPO (http://g2f.atari8.info/gallery_compo/index.html)
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.
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.
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. ;)
Extra coloured maker or Extra Ced Maker was doing to do that. Just have a look at AE 2010 (http://www.pouet.net/prod.php?which=55304) 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... :-X
Nice. Thank you for info. :)
Are you keeping in drawer this Extra Ced Maker, or can I found it in net?
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.
If you do that, God bless you. ;)
But i remember i published a v1 in Sos Fanzine 6 (http://www.cpc-power.com/index.php?page=detail&num=7613) called Ecm (Extra Coloured Maker)
This version just allows you to change 4 inks all 16 lines or 8 lines. I don't really remember.
Have a good fun using this one, waiting for the next one.
Here is the screenshot of the first version of Extra Coloured Maker.
(http://img110.xooimage.com/files/f/f/1/image-49f0ee7.jpg) (http://amstradplus.forumforever.com/image/110/6/0/a/image-49f0ee6.jpg.htm)
That's what I'm talking, to make screen on CPC look like on Atari ST. It's look fantastic. You can't do that on Art Studio. New tool is necessary. ;)
Sometimes when I convert pictures for CPC, I feel pity to make tough decision because MODE 1 don't have enough colors, and MODE 0 have too wide pixels to look really good. Just divide screen on few horizontal part an change least 2 colors on each, can made colossal difference, and much better result. :)
So you can use the first version (v1) of Extra Coloured Maker.... It's really easy to use... :D
This version is made to use 320x200 screen colorize. Don't think about fullscreen :-\
Quote from: ZbyniuR on 17:11, 15 February 15
That's what I'm talking, to make screen on CPC look like on Atari ST. It's look fantastic. You can't do that on Art Studio. New tool is necessary. ;)
Sometimes when I convert pictures for CPC, I feel pity to make tough decision because MODE 1 don't have enough colors, and MODE 0 have too wide pixels to look really good. Just divide screen on few horizontal part an change least 2 colors on each, can made colossal difference, and much better result. :)
Do you try Ecm? What do you think about it?
Yeah, little bit. I really like it! Thank you for that. :)
But 2 things could be better. Why this change mode into 1 ?
I suppose it should work equal good, in mode 2 and 0. Changing only 4 colors in mode 0 it's still fine. :)
And second thing, too bad whole this magic disappear after click any key. :(
Little bit anim made in Basic with this rainbow colors could be fantastic. ;)
In my spare time I do that to program took colors from a file, .pal (Art Studio). There is 12 cycle, just what it need. Thats will be much easily than input numbers. :)
Post your tries here to see how this is.... It would be so cooool.
Ecm2+ gives you the possibility to change colours many times per lines and to change mode screen each lines.
The idea is (for each lines) :
-select mode screen
-select which colour you want to change in this line (for example colour 1)
-give the 12 colours for ink x (example colour 1) in the same line
Go to next line and do the same thing in the 255 lines selected.
Here's what I'm currently thinking. Mode 0, 8 colours per scanline chosen from the full Plus palette. Could possibly have some fixed colours across the whole screen, if you wanted simple sprites for example.