AMSTRAD CPC Vs C64, FIGHT !!!!

[jimpqfly]

MacDeath : ils auraient changé de type de RAM sur la gamme "+" plus pour sécuriser l'approvisionnement que pour les perfs ?

[MacDeath]

Quelle gamme "PLUS" ? sur les Spectrum?
En fait j'avais vu quelque part que les spectrum (probablement ceux de sinclair) utilisaient des RAM foireuses donc en fait seulement la moitié de la mémoire sur les puces était utilisable, après je ne sais pas trop si c'était toujours vrai sur les Spectrum +2 et +3 fait par Amstrad.
Là si un spécialiste peut confirmer ou infirmer c'est cool.

Après c'est vrai que c'est assez rageant car un "spectrum +2 ou +3 (128) inclus vite autant de composants qu'un CPC à peu de choses près.

Peut être le ULA est plus économique que le Gate Array+CRTC...

L'idéal aurait été d faire une machine hybride capable d'être compatible avec les deux, mais les ingénieurs d'Amstrad avaient autre chose à foutre.

Dommage car un 8 bit compatible CPC/ZX/PCW ça aurait été sympa quand même... mais ça devient super complexe en fait, une usine à gaz avec des composants customs (gros ASIC) qui doivent inclure plus ou moins les composants spéciaux de chaque machine (ULA, Gate array, etc...).

Y'a qu'a voir le bordel que c'est pour que les MO6/TO8 soient rétrocompatibles MO5/TO7, ou que l'Amstrad PLUS soit aussi compatible CPC.

[youki]

Si tu avais eu un une machine compatible CPC/PCW/Spectrum , au final que aurait eu que des jeux "Spectrum"...

en developpment un jeu spectrum , il serait vendable a la base enorme (par rapport a la base CPC) d'utilisateur spectrum , et aussi sur la machine "hybride"... ducoup pas besoin de se fatiguer pour faire une version specifique.

Remarque ca a aurait peu etre un bien, car je persiste et signe... les jeux spectrum sont peut etre plus moche mais il sont nettement plus jouable que les versions CPC pour la grande majorité.

Ya qu'a voir, ce qui s'est pas avec le C128 et sa compatibilité C64.... Il y a 4 jeux qui sont specifique 128!!...et encore il sont quasiment identique a la version C64 juste quelque petit enhancement...

[fzu2801]

Non il aurait fallu faire le 464plus dès 1984 ...

[youki]

oui, la je pense que la donne aurait etait differente...

Je n'irai pas jusqu'a dire que le CPC aurait ecrasé le C64 , et surtout pas en terme de vente, mais je pense qu'il aurait pu s'imposer dans un plus grand nombre de pays , et peut etre meme au U.S.

Bon bien sur il aurait fallu que les developpeurs suivent.

En fait un Sam Coupé en 1984 , ca aurait parfait.

Et vous les expert CPC , il y a des Demo CPC+ ? Des trucs qui poussent un peu la machine (autre que les portages faignant qui sont sorti sur la console... bon soit Burning Rubber est pas mal, Robocop 2 aussi, Pang est jolie mais le gameplay bof , Tintin sur la lune correct... mais les autres bof.)

[Invité]

y'a un remake de rick dangerous en CPC+ il me semble .

[fzu2801]

En fait un Sam Coupé en 1984 , ca aurait parfait.

Bein non ... tu n'aurais eu que du spectrum ...

[MacDeath]

LE Sam coupé avec son mode 256x192x16 était en fait relativement lent.
En gros :
CPU = 1,5 x la vitesse d'un CPC (Z80B en 6mhz).
Graphismes = 2x le mode vidéo d'un CPC (4bpp d'un mode0 mais avec la résolution d'un Mode1...)

Et c'est une machine "full soft" comme les Spectrum et CPC (et Atari ST)

Et là, c'est "do not compute that well".

Bon d'autres aspects entrent en jeux, comme la RAM moins limitée.
Mais il me semble qu'il manque au SAM coupé des modes étalonnés sur le CPC...
Ou un mode 256x192xattributs 8x8 x2bpp par exemple (un mode1 de CPC avec des attributs donc).
Là avec les mêmes modes qu'un CPC, le +50% de vitesse de CPU se ressentirait bien.
MAis bon, le Sam coupé souffre encore d'être trop proche d'un Spectrum (portages émulation à la con) et de n'avoir plus ou moins rien en hard (scrolls, sprites...).

[Invité]

Des demos cpc+ y'a ca :





Rick dangerous :


Prehistorick 2 qui est pas mal :

[fzu2801]

LE Sam coupé avec son mode 256x192x16 était en fait relativement lent.
En gros :
CPU = 1,5 x la vitesse d'un CPC (Z80B en 6mhz).
Graphismes = 2x le mode vidéo d'un CPC (4bpp d'un mode0 mais avec la résolution d'un Mode1...)

Et c'est une machine "full soft" comme les Spectrum et CPC (et Atari ST)

Et là, c'est "do not compute that well".

Bon d'autres aspects entrent en jeux, comme la RAM moins limitée.
Mais il me semble qu'il manque au SAM coupé des modes étalonnés sur le CPC...
Ou un mode 256x192xattributs 8x8 x2bpp par exemple (un mode1 de CPC avec des attributs donc).
Là avec les mêmes modes qu'un CPC, le +50% de vitesse de CPU se ressentirait bien.
MAis bon, le Sam coupé souffre encore d'être trop proche d'un Spectrum (portages émulation à la con) et de n'avoir plus ou moins rien en hard (scrolls, sprites...).

Mais il a deux mode avec attributs ... attribut type mode Spectrum (attribut par 8*8 => 8ko) et attribut type MO5/MSX (8*1 => 12ko) ... le dernier étant très interressant car quand même bien moins limité que le speccy ... mais l'absence de sprite hard conduit quand même à du color clash...

[MacDeath]

Le probleme du mode attributs 8x1x1bpp... c'est que au final c'est pas aussi bien qu'un mode avec des attributs en 8x8x2bpp (qui serait plus lourd il est vrai)... mais c'est quasi aussi lourd que du 2bpp normal.

Exemple : La VRAM d'un MO6/TO8 est de 16K... (comme le CPC) et c'est la même pour les modes CPC ET le mode 320x200x attributs 8x1.

Et les attributs en 8x1 ont du mal a gérer quand même les colour clashes comme tu l'a dit... voire le MO5 en la matière... ou encore le MSX1 qaund il n'utilise pas bien les sprites ou que ces derniers sont trop vite utilisés.

R-Type sur MSX1 par exemple, on a pas mal d'attributes clashes sur certains niveaux.

Un mode avec des attributs type spectrum (8x8 pixels, des caractères donc) mais un graphisme encodé en 2bpp... ça serait le super compromis et permettrait aisément de limiter les colour clashes en cas de sprites soft tout en ayant des graphismes plus beaux/facilement exploitables.
Car on aurait 4 encres par caractères, un peu à la manière du mode 160x200x2bpp du C64...mais en pixels fins (un peu comme le background tuiles de la NES aussi en fait).

Avec son Z80 en 6mhz le Sam coupé aurait pu faire de belles choses avec ça.

Que "attribut type MO5/MSX (8*1 => 12ko)" c'est avant tout de par le fait que l'on a l'écran dimensionné en 256x192 et non 320x200 (CPC, MO6/TO8...).
Mais dès que tu veux faire du scrolling soft ou un gros paquet de sprites et autres animation, le moindre data graphique que tu bouge est bien aussi lourd, et sans sprites hards/plan lutin avec d'autres palettes de dispo en "overlay", bin tu gardes un paquet d'attribute clashes.

Bien sûr il est possible d'utiliser les techniques comme sur le Stormlord sur Oric Atmos.
Mais l'oric atmos possède l'avantage d'avoir des attributs plus fins : 6 pixels au lieux de 8...

Graphiquement tu peux aussi sans doute jouer sur un effet "scanline" hyper prononcé...
Genre les graphismes alterneraient des lignes noires et colorées, sprites et tuiles étant alors décalées de 1 pixel verticalement, les lignes colorées des sprites n'étant alors jamais sur celles du background. Et alors tu peux ombrer, pour peu que tu utilises systématiquement du noir comme une des deux couleures...mwaip, et encore même pas certain que ça marche bien.


Sur Amstrad PLUS, il y a eut une petite démo sans trop de prétention en 2012... bien sympa quand même je trouve mais je sais que d'autres trouveront à y redire...




http://www.cpc-power.com/index.php?page=demo&cpcplus=1

sinon ma mini prod perso officielle :

Sans grande prétention non plus il est vrai, mais j'aimerai voir le C64 faire ça... encore que la palette serait presque compatible, mais il faut patcher en sprites comme un porc sans doute.

[fzu2801]

Car on aurait 4 encres par caractères, un peu à la manière du mode 160x200x2bpp du C64...mais en pixels fins (un peu comme le background tuiles de la NES aussi en fait).

Oui mais en plus lourd ... aucun mode ne peux rivaliser avec le concept pour un gameplay arcade ...

Tes tuiles bien calée dans leur 8ko pour la NES (256 *(2bpp 8*8)) ...(sur la cartouche ) ... plus les 4 palettes 4 couleurs de tile .

Tu as seulement 1ko (32*32*1octet) à raffraichir pour changer ton screen ... et en plus elle te gère le double buffering et le scroll hard ... bref tu ne changes ton screen que toutes les huit images ... et en plus tu as la durée de tes 8 images pour préparer ton tout petit 1ko ...

Tu rajoutes à ça les sprites ... tu comprend comment ces machines pouvaient se contenter de si peu de RAM pour un tel affichage.

Par contre tu n'as pas toute la liberté du bitmap ... je n'ai jamais compris pourquoi pour le 464plus Amstrad n'avait pas plutôt créer un "mode 4" avec un mode tiles et sprites ...

Remarque personne n'a rien compris à Amstrad sur cette période là ...

[MacDeath]

La NES avait un CPU vachement "overclocké" et en plus pleins de DMA pour aller quérir les tuiles et sprites toute seul sans CPU si je ne me trompe pas.
Enfin les cartouches étaient évolutives et pouvaient avoir des co-processeurs et RAM et autre supplémentaire... ce qui explique pourquoi les jeux comme MArio3 étaient si bien réalisés... la machine était boostée au passage.

Le "464PLUS" avait moult problèmes.
En gros il était limité par sa rétrocompatibilité CPC et le fait qu'amstrad n'ai voulu développer qu'un seul ASIC (plus la puce de plombage des cartouches, l'ACID).

Un seul ASIC pourtant bien remplis déjà... il gère la vidéo (équivalent de deux composants, gate array+CRTC), la puce ACID, le lock en mode CPC, les canaux DMA pour le son (mal en plus), 16 tuiles hards de 16x16x15+transparence encodée en "8bpp" mais n'utilisant que 4bpp...erf...

le problème est que comme il n'y avait pas d'arbitrage de RAM potable car étalonné sur le CPC464, prévu à l'origine sans sprites et avec seulement 64K... tu ne peux pas tirer paretis d'une machine en 128K par exemple car seul les 64K de départ servent en VRAM potentiel, en Cannaux sons DMA, etc...
Un bon arbitrage de RAM en 128K (donc meilleur port I/O) ça pourrait dire que quand la vidéo et le son lisent des bank de RAM, le CPU peut encore avoir ses 64K rien qu'à lui et donc ne pas se ralentir car pas de partage du port I/O avec la vidéo donc passage en mode "wait" lors de l'affichage des scanlines.
Et ça aurait permis un super double buffering aussi.

Enfin les Sprites du PLUS sont une sorte d'imposture.
L'idéal aurait été des sprites capables de lire en RAM comme un vrai second circuit video en overlay, et être vraiment encodés en 4bpp (16 couleurs donc)

Avec ça on aurait pu les utiliser pour afficher une simple image genre 256x200x16 (15 car transparence) par exemple par multiplexing, comme les sprites amiga non limlités en hauteur en fait.

Mais bon, voilà quoi, on dit qu'amstrad n'a fait le PLUS que pour finir des stocks de composants en efait... probable.

Bref... un CPC arrive malgré tout a faire des trucs potables en mode1/Mode0 quand il n'est pas mal speccyporté, donc un SamCoupé devrait pouvoir arriver à faire de bonnes chose avec un "mode1" de moindre résolution (256x192) ET des attributs en 8x8...
Quand on voit que le CPC claquait bien souvent du CPU dans des rasters en mode1, que avec des attributs c'est ça de moins aussi et tu as de fait des "rasters verticaux" aussi.

ça m'étonne vraiment qu'ils n'y aient pas pensé, ils sont trop restés dans les modes Attributs typiques en 1bpp et sinon on mis un mode type Atari ST en pixels fins et 4bpp... sauf que c'est souvent trop lourd pour un 8 bit.

LE bon point c'est qu'on peut porter graphiquement des jeux MO5/TO7 facilement sur le SamCoupé...lol...

[StaxX]

sinon ma mini prod perso officielle :

Sans grande prétention non plus il est vrai, mais j'aimerai voir le C64 faire ça... encore que la palette serait presque compatible, mais il faut patcher en sprites comme un porc sans doute.

D'après http://c64.superdefault.com/ ça donnerait ça :

[MacDeath]

ouch... bon faut quand même voir que passer de 192x270 à 160x200 ça n'aide pas...
En découpant donc gardant la pixélisation exacte de départ, bref pas de redimensionnement sauvage, ça donnerait plutôt ça :

C'est mieux mais il y a quand même de la perte graphique.

Après faudrait encore voire par rapport aux gris différent, bref re-étalonner ou re-assigner manuellement les couleurs/encres... tout en tenant compte des limitation d'attributs.
Il y a largement moyen d'ajouter du détail pour le fond gris et les tissus rouges je pense.

Mais j'avoue que je me suis fait plaisir avec les gris et marrons sur cette compo, donc dans un esprit C64 finalement. En général j'utilise la palette EGA complète (celle en 64 couleurs) comme référence car c'est un cube RGB limité mais relativement complet et très adapté pour des graphismes limités en 16 couleures..
Après on peut affiner avec la palette 4096 bien sûr, mais si l'écran n'a qu'une seule palette unique de 16 encres et que le dessin à besoin de contraste et de plusieurs gammes de couleurs différentes, le EGA "r2g2b2" suffit largement je trouve.
Parceque bon, tu as le noir, le Blanc, tu met 2 gammes en 3 teintes (3 Gris et 3 rouges par exemple) et pof, déjà 10 encres... te restent que 6 slots... en général si tu veux varier et avoir un rendu "coloré" tu prends alors 3 gammes en 2 teintes (de toute façon tout peut de marrier avec les noir&Blanc en ombre/éclaircissement)
après là moi je suis sortis du EGA avec les gris principalement, le EGA n'en ayant que 2.

Comme je le dit souvent si le EGA avait eut accés à sa vrai palette en "basse résolution" (320x200x16 et 640x200x16), il aurait très souvent égalé l'Atari ST graphiquement pour les jeux.

[StaxX]

ah oui, avec l'image recadrée c'est nettement mieux !
je vais tenter une version Atari 8bit tiens !

[XorionII]

j'adore vous lire ! tous ces aspects techniques, c'est passionnant ! on en redemande.
Moi je suis plus modeste, je me sers de mes yeux et de mes oreilles, et le C64 défonce ce pauvre CPC !
à l'époque quand je voyais les versions CPC j'étais plié en deux tellement c'était faible par rapport au C64. rien que lorsque y'a un scrolling ! aie aie
un seul exemple : Green beret. fabuleux sur C64
tellement insupportable sur CPC avec ce passage d'un écran à l'autre (comme pour bcp de jeu).

cela dit si on voulais programmer, le BASIC du CPC était bien plu sympa et accessible à un novice que celui du C64. Pour ça que je suis passer au C128 à un moment pour avoir un basic plus simple.

[Fabf]

MacDeath, tu la sort d'où cette résolution pour ta mini prod perso?
384x270x17 couleurs

[MacDeath]

Non, y'a pas 17 couleurs, c'est une erreur d'encodage là je l'ai repompé sur un site car j'avais la flemme de chercher dans mon HDD (que j'ai re-rangé il y a peu suite a re-instalation et plantages divers).

Quand à la résolution c'est en fait du 192x272 je crois, soit une résolution d'amstrad en Mode0 Overscan...

Mais en fait la résolution horizontale est doublée pour "émuler" le rendu des pixels de ratio 2x1.

tu as un making-off complet de cette image par là :
http://cpcrulez.fr/forum/viewtopic.php?f=3&t=4892

[fzu2801]

C'est la qu'on voit la supériorité graphique du CPC ... non parce-que mettre des mode full bitmap à l'époque c'était bien plus révolutionnaire que ce qu'on en pense ...

[MacDeath]

Enfin là c'est du PLUS d'ailleurs, qui revient au même au niveau de la résolution, mais avoir la palette 4096 de type Amiga/STe ça change quand même pas mal la donne.

Cette image aurait du mal à être affichée sur un CPC car des pans entier de la palette ne sont pas dispos et j'ai quand même mis pas mal de longs dégradés de couleurs bien contrastés.

Mais je ne composais pas avec le CPC en vue mais bien le PLUS.
à la rigueur ça pourrait passer avec une palettre de 512 couleur type ST/Megadrive.

Toutefois je suis d'accord, l'overscan/fullbitmap, c'est assez bon en mode0 et pouvoir redimensionner l'écran de cette sorte (ou full screen vertical genre 256x256... ou full screen horizontal seulement... ça n'a hélas pas été assez exploité, au lieux de ça réduction en 256x192 Spectrum et là le Mode0 n'a pas assez de place pour s'étendre et faire pardonner les gros pixels.

Le truc c'est que cette feature du CPC fut presque accidentelle en fait (pas tellement documenté à la sortie de la machine) et que ça sauve la machine au final.
Il aura fallut attendre Arkanoid pour montrer les possibilités en la matière.

[fzu2801]

Cette image aurait du mal à être affichée sur un CPC car des pans entier de la palette ne sont pas dispos et j'ai quand même mis pas mal de longs dégradés de couleurs bien contrastés.

Elle donnerait ça (sans travail de graphiste ...) et évidemment tu aurais tramé pour le fond ...

[drfloyd]

L'overscan vertical, genial sur cpc, on aurait pu adapter tous les jeux d'arcade du debut des annes 80... Comme ca été fait avec Arkanoid et avec le fabuleux Donkey Long, trop méconnu sur CPC

[fzu2801]

L'overscan vertical, genial sur cpc, on aurait pu adapter tous les jeux d'arcade du debut des annes 80... Comme ca été fait avec Arkanoid et avec le fabuleux Donkey Long, trop méconnu sur CPC

J'imagine Pac-Man ...

Imaginez 1943/light force / autre shoot'em up vertical en overscan vertical sur 128 de large et 256 de haut dont 248 d'apparent (et donc avec scrolling hard (si si ça fait 16ko)) .. ça aurait eu une autre gueule que ce qu'on a eu ...

[youki]

Oui, c'est le pb avec le CPC.... on ne peut qu'"imaginer"...
Avec le C64 , on a.

[fzu2801]

Oui, c'est le pb avec le CPC.... on ne peut qu'"imaginer"...
Avec le C64 , on a.

? Tu as des overscan commerciaux ? Non parc-que sur arkanoid et donkey kong le CPC est intouchable ... je crois que les prehistorik sont en oversan horizontaux aussi ...malheureusement la machine a trop souvent subis des speccy port ... même dissimulé en mode 0 colorés ...

[StaxX]

Sur Atari 8bit, pour le moment ça donne ça avec RastaConverter:

à gauche l'image originale, au centre l'image en cours de calcule et à droite ce à quoi elle devrait ressembler au final...

[MacDeath]

Just pour finir vite fait avec ça, voici une version recoloriée à la main en palette CPC classique (je crois que y'a pas trop d'erreurs) mais le fond doit êtrre bossé séparément... donc je l'ai enlevé.

Le problème est que j'utilise des teintes très foncées par moment (gris, marron) et qu'il n'y a pas toujours de moyen acceptable de les refaire en palette réduite, bref il faut se retaper du vrai re-pixel car la texture complète de certains élément est à revoir..



Les drapés rouges s'en tirent honorablement juste en remplaçant systématiquement par de la trame...
Rouge très foncé = Rouge foncé+Noir
Puis rouge+Rouge foncé, puis rouge+rouge pastel, comme sur la version Atari en fait (un peu).

Pour les effets métaliques ça passe moins bien car le gris unique reste un handicap dans ce style d'image et le bleu foncé ça le fait pas du tout. Après en passant le "métal gris" en cyan et le marbre en gris, il doit y avoir moyen de faire quelque chose aussi mais l'image devient hyper plus colorée... ça plait pas toujours.

Par contre je sais que le gris se marrie parfois bien en trame avec le bleu pastel et le cyan pastel, et les noir et blanc bien sûr mais sur le fond avec les trames il faut vraiment tout refaire de toute manière car trop de tramage entre gris hyper foncé et Noir.

Hey c'est pas mal ce rastaconverter... l'Atari8bitr est vraiment sympa, dommage qu'il fut aussi bordélique de gérer lesm odes vidéos.

J'imagine Pac-Man ...

il y a eut un émulateur du PacMan arcade sur CPC...

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

Mode1 et trames, mais résolution fidèle à l'originale et véritable émulation grace au Z80.




Et oui c'est regrettable qu'il n'y ai pas eut de bons shooters verticaux en 256x256/128x256 (en fonction du mode) car en effet le scrolling vertical pose un peu mons de problèmes sur CPC.
Entre les relicats de code Spectrum ou la limitation au format 464... ça n'aide jamais.

[StaxX]

Hey c'est pas mal ce rastaconverter... l'Atari8bitr est vraiment sympa, dommage qu'il fut aussi bordélique de gérer lesm odes vidéos.

oui malheureusement... La PS3 des années 80 comme dirait le Doc !
Mais une fois maîtrisé ça fait mal !

[fzu2801]

Pas mal le pac-man ...