http://www.cpcwiki.eu/index.php/Video_modes (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.
Quote from: sigh on 21:31, 01 April 11
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).
Good idea! :)
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... :D
Why ? because I always set my CPC monitor a bit darker so I can get dark black on it...
Quote from: MacDeath on 06:24, 02 April 11
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... :D
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.
Oops, perhaps I did them in a past when I was in 128 config instead... ;D
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 (8) being the closest ones.
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?
Well, if you want... :P
Done.
I clarified the thing.
Thank you :-*
Edit:
Thanks! I like the expanded extra information too.
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.
Quote from: sigh on 10:14, 05 May 11
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 (http://en.wikipedia.org/wiki/List_of_monochrome_and_RGB_palettes#12-bit_RGB), the same as the Amiga.
Quote from: redbox on 11:32, 05 May 11
It's a 12-bit RGB palette (http://en.wikipedia.org/wiki/List_of_monochrome_and_RGB_palettes#12-bit_RGB), 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.
Quote from: sigh on 12:19, 05 May 11
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.
I presume that this is only for mode 0? Do the same principles for hardware sprites apply to the other modes?
Quote from: sigh on 12:47, 05 May 11
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 :( )
Quote from: arnoldemu on 12:50, 05 May 11
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.
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?
Quote from: sigh on 13:47, 05 May 11
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.
Quote from: arnoldemu on 13:52, 05 May 11
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?
Quote from: sigh on 14:36, 05 May 11
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.
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 :(
Quote from: sigh on 15:35, 05 May 11
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 (http://www.cpcwiki.eu/index.php/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.
(http://www.cpcwiki.eu/imgs/d/d2/Xmas_2010_demo_screenshot.png)
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.
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...
QuoteThe result was nice. I got 16 colours in mode 1 resolution (http://cpcwiki.eu/forum/Smileys/akyhne/wink.gif) (pity i could not cover the whole screen (http://cpcwiki.eu/forum/Smileys/akyhne/sad.gif) )
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.
(http://cpcrulez.fr/forum/download/file.php?id=320)
(http://cpcrulez.fr/forum/download/file.php?id=319)
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.
Quote from: arnoldemu on 12:50, 05 May 11
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?
Quote from: hal 6128 on 20:03, 06 May 11
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?
Hardware sprites are a feature of the Plus. There are 16 of them and they are 16x16 in size. They do take up more space (256 bytes) than a 'normal' sprite (128 bytes).
You modify them by paging in the ASIC (http://www.cpcwiki.eu/index.php/ASIC). You can alter their magnification so they can
look like they are Mode 0, 1 or 2 irrespective of the actual screen Mode behind them.
As I told you, the HardSprites are independent from the normal Display (video modes).
It is a "second layer" applied on the normal screen by some additionnal components inside the ASIC.
I'm curious and maybe a stupid question. Is it possible to make the same with the old-gen CPCs if I integrate an additional CRTC and monitior I/O (combine both original and new signals) via expansion port?
Well, perhaps with an external Video card... :-\
Not sure if this would be fast enough though.
I was just looking at Pang youtube. I think it's using mode 1 with the 16 colour hardware sprites as the backgrounds seem to be split into 3 different sections using 4 colours and rasters.
Quote from: sigh on 18:33, 10 May 11
I was just looking at Pang youtube. I think it's using mode 1 with the 16 colour hardware sprites as the backgrounds seem to be split into 3 different sections using 4 colours and rasters.
I have already checked this one.
It's using mode 0 for backgrounds.
It uses the screen split of the plus to do the panel at the bottom.
The balls are made with sprites and are expanded depending on the size (smallest are not expanded), next size are x2 in x and y, next are x4 in x and y etc.
I think the man is also a sprite.
The harpoon and collectables are software sprites.
QuoteI was just looking at Pang youtube. I think it's using mode 1 with the 16 colour hardware sprites as the backgrounds seem to be split into 3 different sections using 4 colours and rasters.
:laugh:
"I don't think so Tim."
The backgrounds and even some sprites are clearly in Blocky pixels (2x1 ratio, sort of) and the "huge" number of colours is clearly mode0.
(http://www.cpc-power.com/images/ecran_titre/3580.png)(http://www.cpc-power.com/images/ecran_jeu4/3580.png)
(http://www.cpc-power.com/images/ecran_jeu2/3580.png)(http://www.cpc-power.com/images/ecran_jeu1/3580.png)
Youtube's video are somewhat largely compressed... so the Pixelisation is completely erroned.
Those PNG pictures are far more accurate.
Anyway, you got to remember that on an actual original Hardware, the CPC pixels, even in mode0 are not as large as we may believe...
And the graphics are cleverly designed to reduce this feeling, also the number of colours (quite decent for an 8 bit on Amstrad/PLUS) enable ditherings and antialiasing to even further reduce the Blocky effect..
BTW I got to check on Winape's "find graphics" option to see how those Hardwired sprites are actually used...
Are plus sprites "disturbed" by file IO? I mean, could you have a mode 0 loading screen on a 6128+ disk game with up to 31 colours, but 15 of them are used quite sparingly?
Quote from: Axelay on 10:01, 11 May 11
Are plus sprites "disturbed" by file IO? I mean, could you have a mode 0 loading screen on a 6128+ disk game with up to 31 colours, but 15 of them are used quite sparingly?
no I don't think they are disturbed, but I never checked.
The only time they would be disturbed is if you multiplexed them using interrupts. Standard loading turns off interrupts during a sector read so this will delay the interrupts.
but a static screen, mode 0, with sprites over the top for extra colours. not a problem.
Quote from: arnoldemu on 21:57, 10 May 11
I have already checked this one.
It's using mode 0 for backgrounds.
It uses the screen split of the plus to do the panel at the bottom.
The balls are made with sprites and are expanded depending on the size (smallest are not expanded), next size are x2 in x and y, next are x4 in x and y etc.
I think the man is also a sprite.
The harpoon and collectables are software sprites.
Whoops! My bad. :-[
Quote from: sigh on 11:13, 11 May 11
Whoops! My bad. :-[
don't feel bad.
I've updated the pang page on the wiki to reflect what + features are used, I'll probably do the same with the other plus games.
so we can at least get an idea of what is used, and perhaps we can learn how to do similar and get good results for our own + games.
The largest bubbles seem to actually use like 3 sprites...
The thing is that you can't have that many buble on screen because to split one buble into 2 smaller, the first (bigger) disapear then...Yet I think the GX4000 version have less bubbles than arcade.
Also the Arcade had a "splitter option" (all bubbles are reduced into smallest possible, hence a lot of those on screen).
Which I don't think the GX4000's have.
(post edit : ok, i saw the dynamite actually exists)
I didn't see vertically magnified sprites but i may be wrong.
Winape is quite strange concerning the find graphics option when you try with a Cartridge game.
Had anyone managed to get the game displaying "more" than the max sprites possible ?
Players seems to be in HardSprites... so if you are playing in 2 players, you then must have 4 sprites used by the players...
This makes "only" 12 available Hardsprites bfor the rest... or is it not ?
Many levels seems to have a theorical number of possible bubbles quite high.
How does the game manage it ?
Anyway Pang seems to make a clever use of PLUS features.
Such a shame a game like Operation thunderbolt didn't (appart from the PLUS palette, which other games didn't even managed...)
I mean some Hardsprites for the visor, the baddies fires, munitions and bonus... and perhaps a few explosions too... could have ease the CPU a little bit (lots of softsprites on it), while their special palette enable to get those sprites to differ from the rest a bit more.
And of course HardScroll for the horizontal parts... smoother.
But hey, they had only 128K cartridges at the time... such an Operation Thunderbolt "PLUS" would need at least 256K IMO...
That's such a shame Amstrad couldn't give them 256K so they had to reduce themselves into low profile production most of time.
Do you think that maybe the big bubbles and player characters are software sprites and the little bubbles are hardware sprites? The player sprites have very little animation going on, so maybe they felt that it would be a waste using hardware sprites for them.
No they must be Hardware because I saw them in the find graphics option...
There a picture, so you can also see the setting of winape to display this (perhaps better can be done).
The largest balls in the above screen shot seem to be 2 hardware sprites arranged vertically with a 2x magnification on the width...
I'm not convinced the players are hardware sprites.
Quote from: Skunkfish on 14:06, 11 May 11
The largest balls in the above screen shot seem to be 2 hardware sprites arranged vertically with a 2x magnification on the width...
I'm not convinced the players are hardware sprites.
they are. at least player 1 is.
I turned off the sprites in my emu and the man and the balls disapeared along with the small plane that appears on the map screen.
the harpoon, weapons, bird, background and panel remained.
I'm modifying the emu to give me more debugging information and then I may be able to answer how they do it all.
I'll update the wiki page about it when I've got the info.
I posted the picture screenshoot of my Winape.
I didn't parametered it well so didn't started a 2player game...but hey, I saw this pink guy too another time.
As you can see the biggest bubbles use 3 Sprites, and are not vertically magnified...they keep the "Mode0" pixels size at max one used.
From what I undestand...
The biggest bubble uses 4 sprites, it splits into 2x2sprites bubles, which turn into 4x1 sprites bubles (not sure if "mode1" pixels or "mode0" pixels... "mode1" I think...), which again turn into 8x1sprites bubles (the smallest bubbles... they seem to be in "mode1" sized pixels...)
When I talk about mode0 and mode1 with Hardsprite, it is just an indication on the pixels size, we know the Sprites are independant from the mode used and just "magnified"...
Also the reference is actually "Mode2 pixels" so a mode0 sized pixel is in fact magnified x4 (max available).
so there must be 4 sizes for bubbles (or 5 ?) each time spliting into 2.
1 biggest can theorically turn into 8 smallest bubbles...
So 3 sprites turn into 8 sprites.
Are there levels with 2+ greater bubbles ?
There on the pic I post :
2x "lvl4" bubles and one "lvl3" bubble. (= 8 sprites used... 4+4+2)
If all splitted (ouch...don't die) this can theorically make like 20 smaller (lvl1) bubbles... ???
Is this possible or does the game simply get such extra bublles to disapear ?
Perhaps it then use 25Hz display ? (flickers) so the same sprites is somewhat alternatively displayed at 2 places ?
I have run a few games and looked at which parts of the Plus hardware they use and added some implementation details which are appropiate.
I will go through the rest when I have time and add more info.
Plotting sets a not so good value for CRTC Register 0 (64), not sure if this would display ok using Bryce's hardware.
What exactly does putting 64 in register 0 do? Does it change any of the frequencies?
I think I tried plotting and did indeed have major screen flickering.
I may add a list of Games that won't display with modulators somewhere on the Wiki.
Bryce.
Quote from: Bryce on 15:19, 12 May 11
What exactly does putting 64 in register 0 do? Does it change any of the frequencies?
I think I tried plotting and did indeed have major screen flickering.
I may add a list of Games that won't display with modulators somewhere on the Wiki.
Bryce.
yes it means each line takes 65 microseconds, compared to 64 microseconds.
So this will effect hsync timings, vsync timings and frame rate.
Only a small amount, but enough.
EDIT: The R3 scrolling actually reduces the length of the hsync for every other frame. So it's 5us instead of 6us, but the overall frame rate is still 50Hz.
So perhaps 49Hz for the frame.
EDIT2: If we had a list of them, perhaps some could be patched to work.
Crazy cars 2 does use some plus features to enhance the game :)
Mystical - well I can't find any evidence to say it uses plus features yet - so this is definitely a direct to cart port.
The others, which I have looked at, use some plus hardware, although it's not often obvious (e.g. some colours have been modified a little compared to the cpc version).
But I still think the "classics": Pang, Navy seals, robocop 2 use the features the best.
I used edit and not reply :laugh: now I lost my previous info. Well it's on the wiki anyway now.
Wasn't Panza Kickboxing a Plus only game too along with Pang and Robocop 2?
Quote from: sigh on 11:24, 13 May 11
Wasn't Panza Kickboxing a Plus only game too along with Pang and Robocop 2?
I believe there is a version for cpc too.
question about video modes:
would it help anybody if I published some code to demonstrate various "extra video modes" and code to convert gfx to them.
e.g. bmp->"video mode"
this would also include instructions so you can go all the way from e.g. bmp -> cpc result in dsk format.
So simple that it doesn't require programming knowledge?
examples are:
- showing some gfx using only sprites
- generic code for loading and showing a picture
- generic code for loading and showing overscan picture
- code to do flashing pics (mode 1/mode 0) + converting code
would this help those who can do gfx but don't know how to code do new works and show them off in the new "modes"?
C64 scene has just picture releases and just music releases, cpc doesn't seem to have this much and we can do the same.
Panza had 3 versions...
=Panza CPC : some stuff are in Mode1 (menu)
http://www.cpc-power.com/index.php?page=detail&num=1597 (http://www.cpc-power.com/index.php?page=detail&num=1597)
=Panza Cart : gets a bigger screen because it use ROM to store Datas so no need to reduces the screen to fill the RAM betterly.
http://www.cpc-power.com/index.php?page=detail&num=3574 (http://www.cpc-power.com/index.php?page=detail&num=3574)
=Best of the Best : is both PLUS and CPC, so re-use reduced screen to get more storage in RAM, also no more Mode1 parts.
http://www.cpc-power.com/index.php?page=detail&num=384 (http://www.cpc-power.com/index.php?page=detail&num=384)
Panza cartridge seems to use more than 16 colours...
Cartridge :
(http://www.cpc-power.com/images/ecran_jeu5/3574.png)
32 colours.
(http://www.cpc-power.com/images/ecran_jeu3/3574.png)
34 colours.
I don't know yet if Sprites Are used, perhaps this is done in Rasters.
As you can see, the screen can be divided in 3 horizontal zones...
The bottom (public) part is clearly using raster.
I used Paint.net to cut the screen in 3 parts, and I get 16 colours in each one.
So yeap, rasters, not sprites.
Those must be unused according to the pictures unless some extra special effects.
Such game is clearly the good customer of Rasters...
= no scrollings needed as it uses fixed screens
=Animation is somewhat limited to only 2 Fighters (and the referee) so you can get big well animated softsprites.
=Hardsprites would be a bit clumbersome... I mean, this uses bigger Datas to get this in HardSprites, and those are slow to change/refresh so if many frames are used... this would be no good.
=limited to 128K cartridge too... A complete spritesheet would be far heavier and not especially fast/easy to animate.
But I may be wrong.
Need to check this with Winape.
Anyway, I used to play Panza on my EGA PC at the time... (which is also a softwared machine, concerning sprites and so on...)
Very decent.
This was the time Loriciel did a bunch of great 8/16 bit games :
Disc, Panza, TennisCup, and so on...
And all those CPC/Plus versions were having this Atari ST flavour...
To me, Loriciel was the sort of French OCEAN.
would it help anybody if I published some code to demonstrate various "extra video modes" and code to convert gfx to them.
e.g. bmp->"video mode"
this would also include instructions so you can go all the way from e.g. bmp -> cpc result in dsk format.
So simple that it doesn't require programming knowledge?
I'm craving for an Noob User friendly application to enable the "True Plus Video Mode".
This mean redimensionnable picture (fullscreen of course possible) using Rasters/interrupts (multiple modes, or just palette changes) and HardSprites patches (used as tiles).
ConvimgCPC is not that great when it have to deal with PLUS palette and ditherings.
Such an application that would help to convert/port/design pictures and make "self executable" versions would be a great imrpouvement to bring new talents into our "scene"...
The "self executable" is clearly where it's at...
Many Demoscene competition need your pictures in Graphic Category to be self executable on the real machine... So a guy who don't code like me simply can't do shit without help.
Other usefull features would be flickerings effects of this kind of thing.
Like the thing used in Batman Demo ? what is it ?
Interlaced...
concerning flickerings... could be great to have like...
=limited/partial flickering : only a few tiles are flickering (using the same palette)
=Hardwired Sprites flickers... : some Sprites "patches" could be used with "flickers" to get also extra colours / fine pixels effects.
And needless to say, would be great if this application also supports the CPC old...
in this case, mostly only flickerings, interlaced, Raster palette and/or Mode changes.
A picture using all this could really weight something like 48K in RAM... or less ?
What would be the "weight" for :
= the 16 hardsprites ?
= the code for the various routines (Rasters/interrupts, flickers, Hardsprites management...) ?
= concerning the basic picture, the weight is well known... 16K for a "normal" sized screen, 32K (=24k...) for overscaned picture.
Also to get this Application to enable to make proper Viewer of multiple picture would be great... (Diaporama)
Quote from: MacDeath on 11:47, 13 May 11
Such game is clearly the good customer of Rasters...
= no scrollings needed as it uses fixed screens
=Animation is somewhat limited to only 2 Fighters (and the referee) so you can get big well animated softsprites.
=Hardsprites would be a bit clumbersome... I mean, this uses bigger Datas to get this in HardSprites, and those are slow to change/refresh so if many frames are used... this would be no good.
=limited to 128K cartridge too... A complete spritesheet would be far heavier and not especially fast/easy to animate.
Im in interested in these comments especially about the "Hardsprites would be a bit cumbersome...". Why would it be slow to change and refresh? Why do software sprites operate faster for this kind of game?
Quote from: arnoldemu on 11:39, 13 May 11
would it help anybody if I published some code to demonstrate various "extra video modes" and code to convert gfx to them.
examples are:
- showing some gfx using only sprites
- generic code for loading and showing a picture
- generic code for loading and showing overscan picture
- code to do flashing pics (mode 1/mode 0) + converting code
Would be great. I'm still getting my head round these video modes.
Quote from: sigh on 14:41, 13 May 11
Im in interested in these comments especially about the "Hardsprites would be a bit cumbersome...". Why would it be slow to change and refresh? Why do software sprites operate faster for this kind of game?
The downside to hardware sprites is that they take up more space, and when you're copying them from RAM into the ASIC (location of Hardware Sprites) you have to copy twice as much data. Either this or you have to unpack your data if you've packed it to take less RAM for storage and this is even more of an overhead.
The problems therefore come when you want to animate hardware sprites - you can only just animate them all within one frame. But there are ways around this such as only animating some at a time.
Hardware sprites do have their pros and cons and what MacDeath was saying is they might not be suited to that purpose.
Thanks. I had no idea about this.
So what I'm gathering is this:
1) Pang or Shoot em up type game where the player sprites have very little animations, Hardware Sprites are a great choice (also for special effects animation such as explosions, fire and bullets.)
2) Panza/Beat em up game or football game, or anything that is heavily animated would be better off using software sprites due to the amount of animation and storage being used.
It seems like everytime I feel close to getting to grips with the video modes to generate my game ideas- something else always crops up :laugh: !
That's it.
Hardsprites from the Asic do not simply read RAM or ROM for content... they need to "upload them into the ASIC... which is somewhat slow because it seems the Sprites are designed as 256 colours... so weight far more than the theorically needed 16x16xmode0 datacode... (actually like 32x16xmode0 Datas)
Clearly a flaw in design.
If they were properly implemented (=like mode0 but with redimensionnable pixels = 4 bits per pixels) they may even be twice faster to upload into ASIC.
Or if they were really 256colours, they would be simply awesome...
But this also would need 256 colours slots in the ASIC for the Sprites Palette, which is quite a lot of space into a component. :'(
On the other hand, to move the sprites (not change the frame) is good and fast...
Amstrad PLUS lacked actually a very few things...
=overclocked video modes (=32K VRAM used... 160x200x256/320x200x16/640x200x4... like Atari ST, sort of)
So more something like 2x256colours slots for palette... (+1 for the border)
=less bugs and flawed features (DMA sound has some bugs to, sprites are unproperly done)
=More RAM and ROM (256K cartridges would have been the minimum IMO, minimum128K RAM config...256k would be great but even 160K RAM would be quite ok...)
=More sprites !
Most other machines like MSX had 32 sprites...
ok why not 2x16 sprites, using slightly different logic.
The 16 like the one already there (minus the flaw...would then be more like Hardware tiles) and additionnal 16 which would not upload but read Datas in RAM/ROM (pointer)... and perhaps even simply use the standard Videomodes code/colours...
So yep.
A proper PLUS would have needed 2 Asics instead of one... most other computers used 2 custom chips (when they used some), often one for sound and the other for Video.
In amstrad's case, one for Video only and the other for all the rest...(ACID reading, DMAs, Memory managment, and so on...)
And having 2xAY psg could have been great to.
and 16mhz Z80...
and and and...
:laugh:
ok i stop this wankfest.
Actually to simply get a PCW9256 with the PLUS' Design, Video (modes, colours, sprites, scrolls) and Sound (AY + DMA) would be ok...
(and compatible with both PCW and CPC...ouch...)
Quote from: MacDeath on 15:47, 13 May 11
ok i stop this wankfest.
Yeah, thanks a lot. (wipes his hands)
Quote from: MacDeath on 15:47, 13 May 11
Hardsprites from the Asic do not simply read RAM or ROM for content... they need to "upload them into the ASIC... which is somewhat slow because it seems the Sprites are designed as 256 colours... so weight far more than the theorically needed 16x16xmode0 datacode... (actually like 32x16xmode0 Datas)
Clearly a flaw in design.
The sprite ram is a clever idea. They didn't have the memory bandwidth to read sprites from main ram. (perhaps they could have used the time in the border area...)
So they used ram inside the ASIC which it could access fast. They used the memory bandwidth which was free in the hsync to read sound dma instructions which was clever too.
But what would have been really great, was if you could tell each sprite where in the ram to fetch it's pixels.
Then C64 like multiplexing would have been much more possible and take less cpu time.
Quote from: MacDeath on 15:47, 13 May 11
That's it.
Hardsprites from the Asic do not simply read RAM or ROM for content... they need to "upload them into the ASIC... which is somewhat slow because it seems the Sprites are designed as 256 colours... so weight far more than the theorically needed 16x16xmode0 datacode... (actually like 32x16xmode0 Datas)
Clearly a flaw in design.
On the other hand, to move the sprites (not change the frame) is good and fast...
Okay. Seems I overestimated the hardware sprites, but at least now, I have a clearer idea of it's uses.
Well for the sake of the argument, comparing hardware sprites to software sprites over background... For h/w sprites you need to copy the data, maybe unpack it, and set the XY co-ordinates and magnifications perhaps. For s/w you need to consider working out screen addresses instead of simply plugging in XY co-ordinates, you have to save and restore the background, and allow for the memory allocated to storing it, you need to spend the time to mask your sprites against the background, and you need to either use a second 16k screen as a buffer to prevent flicker (and needing twice the save/restore buffer space) or deal with trying to minimize flicker by managing sprite update order in some way. You also need to update every s/w sprite every frame it moves or the screen scrolls, where with the hardware sprites you can stagger sprite data update according to animation requirements. I really don't see how software sprites over backgrounds, especially horizontally scrolling ones, could hold a candle to the plus hardware sprites, even with their difficulties?
The problem with HardSprite is that there are not a lot of them...
When i told it was a flaw, Well... to get the sprites formated as 8bpp but using only 4bpp is a flaw.
The PLUS' sprites are often compaired to C64's sprites... not a good Idea. quite different.
C64 : ok, it's fast and easy to multiplex properly... but those must stick to C64 video limitation ("modes" and palette) actually...
C64 sprites are smooth and fast... but ugly as hell... C64 palette...erk... ok a good choice of greys, lol...
Also :
= 2 (1+Transparancy) colours only if fine square pixels. (1bpp)
= 4 (3+Transparancy) colours only if blocky 2x1 pixels. (2bpp)
Good point : they are 24x21 pixels... wich is quite good yet somewhat bastardish...
So Yep, with its 16 16x16x15 sprites, Amstrad PLUS is not that bad.
Also the HardSprites are supposed to be faster if ROM operated...
That's why I always have a mixed view on those.
Better than nothing, yet frustrating...
They just miss a little something to be fully operational...
=be faster to upload into ASIC (=reduced weight in data).
=or be more numerous (32 sprites=more slots for the same amount of data = reduced weight in Datas per sprite)
=or be actually 256colours (=same as they are but 256 ink slots for Sprites).
Twice would be great... so to be really in 4bpp ... :-\
But 8bpp would also be awesome ... ::)
Having 32sprites in 8bpp (256colours) would have been the ultimate combomaker. :'(
Also some stuff like flipside, reverse sprite or rotate it by 90° would have been a definitive plus.
The flaw in design was concerning the fact they use twice Bit as needed and don't use all their bits...
Anyway, I started a new topic to deal with such matter as we are talking now...
I mean we got far beyound the reachs of the original topic here...
http://www.cpcwiki.eu/forum/index.php?topic=2279.0 (http://www.cpcwiki.eu/forum/index.php?topic=2279.0)