oui, maintenant on ne gère plus sa mémoire comme ce fut le temps par le passé, c'est dynamique et de toute façon les machines sont tellement complexes et a une autre échelle et avec des électroniques variables (nombre de constructeurs) que l'on ne peut même pas vraiment s'amuser à aller gratter dans le hard
Le Qbasic est il un peu orienté objet ?
Citer :
je pense que les programmeurs de l'epoque avaient utilisé pour les sprites des "datas" ca simplifiait largement la donne pour les changements de couleurs et surtout la taille sur le disque. mon reve aurait été de reproduire le programme pas plus lourd que l'original
ils n'avaient pas le choix je pense les Graphismes étaient en Bitmap et non en vectoriel.
Et la Vidéo et le CPU étaient étroitement liés, partageant d'ailleurs la même RAM en fait.
le CPU faisant alors des opération sur des blocs de RAM (déplacement , modifications, du travail de blitter en somme...) et recomposant l'écran à afficher et la Vidéo (Gate Array et CRTC) se contentant de lire la plage "RAM vidéo" ainsi composé en mosaique depuis les tuiles stockées ailleurs, en mettant le CPU en mode Wait.
Il fallait donc juste que le CPU ait le temps de composer son image entre chaque affichage écran tout en gérant les paramètres abstraits et autres composantes du jeux (collisions, points de vie, séquence de jeux, musique), mais vu que la machine avait une synchronisation entre la vidéo et le CPU... ce qui n'est plus vraiment le cas sur les machines modernes.
Et utiliser un encodage en 2bit par pixels pour les sprites permet en effet que ça tienne moins de place, et de porter les sprites depuis les version C64 et PC CGA à l'identique (sans vraiment de retouche graphique).
Convertir du 1bpp en 2bpp était un genre de technique assez courant, utilisé par exemple pour la conversion de polices de caractères ou dans les portages spectrum où l'on recodait alors des graphismes 1bpp (spectrum et Mode2 CPC) en 2bpp (mode1), cela hélas en utilisant le CPU alors qu'il va chercher les datas graphiques (tuiles) dans la RAM pour les foutre dans la "RAM écran" (j’appelle ça la "pseudo VRAM", la bank RAM que la vidéo va lire).
ça pompe logiquement du CPU de faire ça, mais vu que le jeux n'a pas tant d'animations en même temps que ça (principalement 2 sprites de barbares, les têtes de serpent, le gobelin parfois...) et que mine de rien les tuiles du sprite de barbare ça fait un paquet de variantes/frames d'animes donc en fait pas mal de poids de Data.
le CPC en mode 64K... il ne possède en fait que 48K de vraiment dispo car 16K sont utilisés comme VRAM. l'équivalent d'un écran de 320x200x4 ou 160x200x16 c'est 16K. Donc de la "surface écran" de Datas Graphiques pures c'est assez lourd. une partie de ces Datas graphiques pouvant d'ailleurs rester dans la VRAM sans vraiment changer car ils ne sont pas susceptibles d'être modifiés (certaines parties du décors, le Logo Barbarian aussi).
Un autre aspect est que le CPU doit probablement faire aussi des manips pour afficher les sprites dans l'autre sens (le barbare regardant à gauche). ce genre de manip software était aussi très courante car ça permet de stocker 2x moins de Tuiles en RAM... Pour le moteur de Barbarian, c'est bon, comme je l'ai dit, peu d'animes en fait... mais quand tu avait un Shoot'hem up avec scrolling horizontal, plein d'objet à gérer et afficher à l'écran, bien plus de collision et de masques à gérer donc... c'est vite très lourd pour le CPU, et c'est pour ça que le format 64K de RAM fut pas vraiment en faveur du CPC.
Non seulement le CPU en chie a devoir faire plein de turcs en software de base : masques, sprites et tuiles à composer en mosaique dans la "VRAM", scrolling, gestion du score, des collision, etc...
Mais en plus il se tape des manips sur les dit Datas graphiques pour les retourner (flip horizontal ou vertical souvent) et dans pas mal de jeux en portage spectrum il doit encore se farcir de la convertion 1bpp en 2bpp... ouch. Alors qu'en 128K de RAM, ces manipes là peuvent être fait en amont car les datas graphiques sont simplement déjà encodés comme il faut (au bon mode, avec les 2 variantes de flip éventuelles) et il suffit alors de plutôt gérer des Bankswitchings quand tu vas chercher tes tuiles en RAM... Oh et les 128K permettent plus aisément de faire du double buffering aussi, logiquement.
L'idée était je pense que la RAM est une limitation ferme. Pas assez de RAM : pas de possibilité du tout de mettre ton truc. Alors que les cycles CPU c'est pas une contrainte tellement fixe. Si tu manque de temps CPU, bin tu ralentis le jeux tout simplement. C'est lent, mais ça marche à peu presque.
Et bon, les éditeurs auraient pu se sortir les doigts du cul et ne faire principalement que des version 128K (qui auraient éventuellement put être mieux que les jeux qui sont effectivement sortis)... ça aurait fait l'effet killer App et aurait plutôt forcé Amstrad à mettre 128K sur toutes ses machines, ou alors forcé les utilisateurs à acheter des extension de +64K pour leurs CPC464 ou 664...
Hélas le but d'un éditeur de jeux n'est pas de faire de bons jeux ou de tirer une machine vers le haut, mais en fait de faire du fric avec le plus de marge possible et le moins de coûts et délais possible. Faire un bon jeux ne nécessite pas de faire un jeux encore meilleur... et tant qu'il se vend au plus grand nombre d'utilisateurs. Car le CPC n'était pas le leader du marché sauf en France.
Mais avec juste 80K de RAM de base les CPC avaient de quoi réussir leurs portages spectrum48 sans encombre, les +48K (par rapport au spectrum48k) compensant largement la différence de poids des graphismes par rapport au spectrum et rendant caduque le besoin de tricks pour rentrer le jeux et les tuiles dans la RAM.
Après avec le Qbasic sur les machines modernes, les problèmes doivent être bien autres et pas forcément simples non plus à résoudre.
un utilitaire pour justement retoucher et encoder proprement les graphismes, c'est Graphix2.
c'est un descendant de Deluxe Paint 2 orienté rétro graphiques... il ne vas pas au delà de 256couleurs et peut générer les palettes classiques des vieilles machines (comme le CPC) et gère aussi les pixels à forme non carré.
vous verrez, ça n'est pas la plus belle version, mais le gameplay est le meme que sur CPC quand on joue au deux, on se dit qu'Amstrad avait une sacrée longeur d'avance sur les PC à cette époque là cette adaptation a été assez rapide, pas de probleme de palette couleurs cette fois petite nouveauté, on peut y joueur à deux joysticks pour en finir avec ce jeu, la semaine prochaine je m'attaquerais à la version AppleII qui etais plus colorée et avec de meilleurs sons bon jeu à tous @+ F.L
Inscription : 13 Jan 2010, 14:25 Message(s) : 2270
Oui, et si l'on va par la ça ne sert à rien de refaire quoi que se soit, puisque l'on peut quasi tout émuler.
Je trouve cette initiative vraiment intéressante. (en plus d'être une satisfaction personelle pour l'auteur) Une fois toutes les versions terminée, il serait sympa d'avoir tout dans le "même" programme et choisir la version à laquelle on veut jouer dans une menu "Version" de la fenêtre.
Je suis quand même surpris que la version PC CGA ait des sprites en "pixel wide".
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
oui, cela sent le portage des gfxs cpc sur pc... ce qui est plutôt une surprise mais Palace Soft. avait peut être confié le portage à un codeur qui n'a fait que reprendre les gfxs cpc ?!
salut à tous je remonte le sujet pour vous dire qu'un article sur mon remake de barbarian etait sorti cette semaine dans le dernier numéro du magazine pix'N'love. si vous voulez en savoir plus sur l'aventure de ce remake, je vous le conseille @+ françois http://www.editionspixnlove.com/Tous-no ... e.tpl.html
Inscription : 13 Jan 2010, 14:25 Message(s) : 2270
C'est cool !
Je devais avoir quelques pages sur la fabrication de la version boite de R-Type, mais vu que le numéro à 8/9 mois de retard, j'imagine que ça à du sauter...
ils en parlent dans une brève page 8. peut etre que ton article sera pour le prochain numéro. pour info, j'ai été interviewé pour barbarian fin aout 2012, je commencait à m'impatienter !
Inscription : 13 Jan 2010, 14:25 Message(s) : 2270
J'ai été interviewé fin Juillet 2012 au bouclage du numéro pour 2 pages, mais rien n'était certain. J'étais prévenu. Finalement la sortie a été mainte fois repoussée au profit d'autres ouvrages et j'imagine que son contenu a continué à évoluer dans le temps.
Je devrais le recevoir en début de semaine prochaine et lire ton interview. J'espère que les parutions recommenceront à devenir périodiques, en tous cas.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 5 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum