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 penseles 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é.
