R-Type, reboot sur Amstrad CPC !

Publié le par Dr Floyd

Ça y est le fameux R-Type 128k de Easter Egg pour Amstrad CPC6128 est terminé ! Bien meilleur que le jeu original, en mode 0, et donc en 16 couleurs, il est vraiment sublime, et aurait fait un carton monstrueux en 1987 sur un ordinateur en manque réel de bonnes adaptations d'arcade ! La ROM du jeu est téléchargeable ici.

A noter qu'une version disquette est prévue pour plus tard !

Publié dans NEWS

Pour être informé des derniers articles, inscrivez vous :

Commenter cet article

D
Celui ci par exemple :<br /> <br /> http://www.gamopat-forum.com/t40171-le-hardware-du-cpc-face-aux-concurrents
Répondre
J
Doc, dans quel rubrique de préférence ?
Répondre
P
merci pour les précisions, jackwa ça fait plaisir aux neurones pour une fois
Répondre
O
Merci pour la news. Jeu testé, et approuvé. Si j'avais encore eu un Amstrad sous la main, j'aurais sans doute acheté la disquette à venir...
Répondre
D
Jackwa il faut absolument que tu viennes discuter de tout ça sur le forum de Gamopat
Répondre
E
Wahoo, elle est cool ta vie !
Répondre
J
J'ai repris la programmation sur atari STe.<br /> <br /> Pourquoi ?<br /> * Le processeur 68000 (ST) c'est du bonheur face au Z80 (CPC)<br /> * Enfin assez de mémoire disponible... ;-)<br /> <br /> Mais aussi le STe n'a jamais réellement été exploité.<br /> * son DMA<br /> * Scrolling Hard<br /> * Blitter (quoi que le CPU fait aussi vite voir plus, mais avec des sprites prédécallé et donc un "coût" en RAM)<br /> <br /> J'ai actuellement un méga STE avec 4 Mo de RAM sur écran LCD (péritel) et 1 Go de disque dur sur carte SD (UltraSatan)
Répondre
T
Bon ben moi .....je retourne sur la version Amiga ....d'ailleurs chouette histoire à propose de cette version qui en fait a été développée par une firme allemande suite à la plainte de Konami pour<br /> plagiat avec le fabuleux Katakis !
Répondre
F
Je ne suis pas sur que le dual playfield soit une meilleure garantie de performance dans ce cadre.En plus , on aurait perdu beaucoup de l'aspect graphique ce qui est pourtant le point fort du<br /> CPC.Les sprites ne sont pas vraiment un problème , la difficulté ici est le scrolling au pixel qui , comme chacun le sait , est une plaie sur CPC (on pourrait d'ailleurs discuter longuement des<br /> techniques qu'il est possible de déployer à ce propos)<br /> A propos du framerate , j'en suis satisfait vu que le but était d'avoir quelque chose d'équivalent à la version Spectrum en terme de vitesse tout en ayant le double de données graphiques à traiter<br /> (et sans avoir l'avantage d'un display à base de caractères).D'ailleurs ce n'est évidemment pas visible mais la vitesse est pondérée afin de garder un framerate le plus constant possible , surtout<br /> dans les phases où il n'y a plus besoin de rafraichir le scrolling.<br /> Enfin , on pourrait discuter à loisir des différentes options qu'il aurait été possible de choisir et des choix techniques qu'il a fallu faire sur ce projet.Ca serait même un plaisir de causer<br /> technique sur CPC (voire autre) et je ne me refuse jamais à apprendre de nouvelles choses ou à partager de nouvelles idées ;)<br /> <br /> @+
Répondre
J
Je ne connais pas personnellement easter egg et je ne pense pas a avoir quelque chose a apprendre a un programmeur de son niveau.<br /> Maintenant je peux rentrer en relation avec lui, pourquoi pas.
Répondre
O
@JackWa : pourquoi ne pas soumettre cette idée à Easter Egg directement ?
Répondre
M
Perso je regrette les vagues de portages en 4 couleurs de l'époque. Cette nouvelle version de Rtype poutre du ponay! Ca me donne presque envie de refaire les brocantes pour dégoter un 6128.
Répondre
J
Un inconvéniant tout de même :<br /> Les sprites s'entre effacent quand ils se superposent, on vois les morts vivants qui clignotent quand ils se superposent.
Répondre
J
Des "sprites" très rapide sur l’Amstrad ?<br /> <br /> <br /> <br /> <br /> En temps normal, comment fait-on ?<br /> <br /> 1. On construit le décor<br /> <br /> 2. On efface les anciens "sprites" en reconstruisant le décor.<br /> <br /> 3. On efface la zone où il y aura un "sprite" à l'aide d'un "masque" (sorte d'ombre du sprite qui va être affiché)<br /> -> Avec la fonction logique : Destination = Destination AND (NOT masque)<br /> -> remarque la fonction logique NOT masque peut être traité en avance.<br /> -> Nous obtenons alors à l'écran un "trou" de la forme du "sprite"<br /> <br /> 4. Affichage du sprite avec la fonction logique :<br /> -> Destination = Destination or source (source c'est le "sprite")<br /> <br /> <br /> Il faut répéter l'opération pour chaque "sprite"<br /> En général, la technique est tellement lente qu'il faut utiliser le "page flipping" (2 pages graphique) une page affiché à l'écran, l'autre page en construction, puis quand une page est construite<br /> on "flip", c'est à dire la page affiché à l'écran devient la page que l'on vient de construire et l'ancienne page affiché devient la page à reconstruire.<br /> <br /> Pour résumer :<br /> ============<br /> <br /> * Nous avons 2 pages écran (16x2 = 32ko, la moitié de la ram d'un CPC)<br /> * Chaque "sprite" occupe 2x sa taille en mémoire. (Le sprite + son masque)<br /> >>Et si l'on veut faire du déplacement de "sprite" au pixel près, il faut prédécaller encore une fois le sprite et son masque d'un pixel.<br /> >>Car dans 1 octet affiché à l'écran graphique il y a 2 pixels. Ce qui signifie que chaque sprite prend 4x sa taille en RAM au total ! ! !<br /> <br /> Beaucoup de mémoire consommé et une routine lente pour l'affichage, vu le nombre d'opération logique à faire avec le pauvre Z80.<br /> <br /> <br /> <br /> <br /> Et sur Ghost'n Goblins on fait comment ?<br /> <br /> Il faut juste une petite astuce de mathématique des logiques...<br /> <br /> En mode 0 (16 couleurs), l'encodage des couleurs se fait sur 4 bits.<br /> On peut donc réserver 2 bits pour le décor et 2 bits pour les "sprites"...<br /> <br /> Ce qui nous donne en :<br /> 4 couleurs (2 bits) pour le décor.<br /> 4 couleurs (2 bits) pour les sprites - 1 couleur pour la transparence des "sprites" = 3 couleurs.<br /> Résultat un jeu en seulement 4+3=7 couleurs !<br /> <br /> Mais alors comment on fait ?<br /> <br /> Il faut faire un choix très astucieux pour les couleurs. On a dit 2 bits pour le décor et 2 bits pour les sprites<br /> Si il y a une couleur dans les bits Sprites, affiché la couleur du sprite.<br /> <br /> <br /> Pas compris ?<br /> <br /> <br /> Pour le décor :<br /> <br /> 00 couleur décors 1<br /> 01 couleur décors 2<br /> 10 couleur décors 3<br /> 11 couleur décors 4<br /> <br /> Pour le Sprite :<br /> <br /> <br /> 00 couleur sprite transparente (décors visible)<br /> 01 couleur sprite 1<br /> 10 couleur sprite 2<br /> 11 couleur sprite 3<br /> <br /> Ce qui nous donne :<br /> bit 3-2 pour le décors et bit 1-0 pour le sprite. Si les bits de sprite sont à 0, prendre la couleur du décor.<br /> <br /> ----------- 2 bits décors<br /> ||<br /> ||--------- 2 bits sprites (si 0 alors couleur = décors)<br /> ||||<br /> 3210 bits<br /> <br /> <br /> 0000 Décors couleur 0<br /> 0001 > Sprite couleur 1<br /> 0010 > Sprite couleur 2<br /> 0011 > Sprite couleur 3<br /> 0100 Décors couleur 1<br /> 0101 > Sprite couleur 1<br /> 0110 > Sprite couleur 2<br /> 0111 > Sprite couleur 3<br /> 1000 Décors couleur 2<br /> 1001 > Sprite couleur 1<br /> 1010 > Sprite couleur 2<br /> 1011 > Sprite couleur 3<br /> 1100 Décors couleur 3<br /> 1101 > Sprite couleur 1<br /> 1110 > Sprite couleur 2<br /> 1111 > Sprite couleur 3<br /> <br /> Voilà comment il faut définir les 16 couleurs de la palette.<br /> <br /> <br /> <br /> Mais comment on affiche maintenant ?<br /> <br /> <br /> Très simple avec la fonction logique XOR (OU EXCLUSIF)<br /> Mais pourquoi XOR ? (car la même routine va servir à afficher et à effacer les sprites à l'écran !)<br /> Magique ?<br /> <br /> Fonction logique XOR :<br /> <br /> 0 XOR 0 = 0 --> On ne fait rien.<br /> 0 XOR 1 = 1 --> Affichage du sprite<br /> 1 XOR 0 = 1 --> Affichage du sprite<br /> 1 XOR 1 = 0 --> si on réaffiche le même sprite sur un sprite existant, il s'efface.<br /> <br /> <br /> Pour résumer :<br /> ============<br /> <br /> 1 seul page vidéo (16ko)<br /> Sprite stocké en simple en mémoire sauf en cas d'affichage au pixel près alors stockage en double, mais sans masque.<br /> Routine d'affichage rapide (une seule opération logique) qui sert en plus à effacer le sprite !<br /> Inconvénient : seulement 7 couleurs (y'en a qui n'ont pas remarqué sur ghost'n goblins !!! tellement l'animation est bonne.)<br /> Les sprites s'entre effacent quand ils se superposent.<br /> <br /> Voilà, c'est une astuce simple, mais difficile à expliquer... lol<br /> <br /> Pour des infos complémentaires, je suis dispos.
Répondre
O
Je viens de l'essayer, il est vraiment excellent, et la vidéo ne lui rend pas justice.
Répondre
O
Retour en 84, on vous propose le jeu commercial et celui-ci.<br /> Lequel vous choisissez ?<br /> <br /> Alors il faut saluer la prouesse technique de Easter Egg.<br /> <br /> Quant aux autres, ... haters gonna hate, innit ?
Répondre
B
Seul petit problème, on est plus en 1984...
Répondre
D
Oui explique nous !<br /> <br /> Sur la vidéo le rendu ultra saccadé est dû je pense à la mauvaise qualité de la vidéo.
Répondre
J
Déjà il n'y a aucune prouesse technique,la quantité de donné a gérer est la même ...<br /> Ahh bon ?<br /> mode 1 : 320x200 en 4 couleurs pour l'original.<br /> mode 0 : 160x200 en 16 couleurs pour le remake.<br /> Et si l'on veux afficher des "sprites" avec un déplacement au pixel près, en génèral sur CPC on prédécale les "sprites" en mémoire. En mode 0, chaque sprite éxiste en double, en mode 1 il devrait<br /> exister en quadruple !<br /> Donc faire un jeu en mode 1 est même plus compliqué.<br /> <br /> Il existe par contre un moyen de faire des "sprites" rapide en mode 0, on le trouve dans le jeu Ghost'n Goblin's<br /> <br /> Vous voulez que je vous explique ?
Répondre
A
y'a bon la vitesse d'animation de environ 4 fps ;)
Répondre