Hardcore Retrogaming

[JiHaisse]

Faut mettre ce topic en post-it.

[upsilandre]

Je pense pas que ca soit nécéssaire


Un lien qui permet de tester tous les jeux 2600 en emulation dans le browser sans rien a installer
https://archive.org/details/atari_2600_library

Combat
https://archive.org/stream/atari_2600_combat_-_tank-plus_tank_1977_atari_joe_decuir_steve_mayer_larry_wagner/atari_2600_combat_-_tank-plus_tank_1977_atari_joe_decuir_steve_mayer_larry_wagner.bin?module=atari2600&scale=2

Space Invaders
https://archive.org/stream/atari_2600_space_invaders_1980_atari_richard_maurer_-_sears_cx2632_-_49-75153/atari_2600_space_invaders_1980_atari_richard_maurer_-_sears_cx2632_-_49-75153.bin?module=atari2600&scale=2

[upsilandre]

J'ai bien avancé ce soir!
Quand meme une grosse prise de tete pendant au moins une heure juste sur un blocage avec le compilateur DASM. J'ai eu un probleme et j'arrivais plus a comprendre son comportement, pourquoi il voulait pas compiler et pas m'indiquer ou etait l'erreur, ca m'a permit de me pencher un peu plus dessus et mieux comprendre son fonctionnement et ses parametres, c'etait pas inutile au final (d'autant que j'imagine que ca sera le meme compileur pour la NES) mais ca m'a fait perdre pas mal de temps.

Sinon mon Kernel auto-généré avance, c'est une prise de tete absolu de faire du code qui doit générer du code, t'as l'impression d'etre en train de coder un compilateur justement mais c'est asser fun au final car ca fonctionne tel qu'on pouvait le suposer en theorie et quand la pratique match la theorie farfelu ca fait plaisir.
Alors ca avance mais vraiment tout doucement, chaque ligne de code est un casse tete (d'autant plus quand tu manque d'experience) mais je pense que c'est une gymnastique qui me sera bien utile pour la suite, ca oblige a encore mieux comprendre le fonctionnement.

Comme au final c'est plutot une demo tech qu'un jeu je suis passé a 14 sprites d'aliens par ligne sans flickering  8)  (au lieu de 6 dans la version original et 11 en arcade)

[upsilandre]

Je me suis pas mal acharné ces derniers temps, beaucoup de R&D toujours sur le Kernel a essayer divers methodes.
J'ai trouvé une 4eme methode pour mon kernel d'affichage des aliens ou plutot une variante de celle que j'etais deja en train de mettre en place donc toujours avec le defie du Kernel en RAM qui m'interresse mais cette fois grace a une astuce pour modifier les timing (en forcant un adressage 16bit sur l'instruction de reset de la position des sprites pour lui faire perde un cycle et avoir le bon timing) je n'ai plus les problemes d'alignement chaotique des aliens donc ca devient plus interressant car maintenant c'est propre et donc je peux aller au dela de la simple demo tech et faire un vrai jeu (ou au moins un prototype si j'ai la flemme d'aller jusqu'aux details comme le scoring)

En contrepartit les sprites des aliens sont plus espacés (un sprite tout les 12 pixels au lieu de 8 ) et etant donné l'amplitude de mouvement que je veux pour matcher la version arcade ca me limite a 10 sprites par ligne (au lieu de 14 sur ma demo tech chaotique) mais toujours sans flickering donc ca reste un exploit et c'est tres ressemblant a la version arcade.

En plus ca me permet de faire des sprites jusqu'a 8 pixels de large au lieu de 6 pixels auparavant (jusqu'a 12 sur la version arcade) c'est pas du luxe. ca me permet notement de mieux coller a la version arcade en faisant varier la taille des sprites (les aliens les plus haut sont ceux qui raportent le plus de point mais sont aussi les plus petits et donc les plus dures a toucher car protégés par ceux qui sont devant et plus large, l'une des subtilités qui n'existe pas dans la version 2600)

Mais une fois que je me suis fixé sur cette methode de Kernel il a fallu relever beaucoup de défies. Y a une quinzaine de fois ou je me suis dit non finallement c'est pas possible a faire puis je continu d'y reflechir et je trouve chaque fois une nouvelle solution qui en général me demande de repartir pas mal en arrriere pour une aproche differente puis vient un nouveau probleme a priori insoluble...
Je dois avoir deja une trentaine d'archive juste pour construire mon Kernel (j'ai pas du tout commencé a bosser sur les mecaniques du jeu, tout l'effort c'est le kernel et donc contourner les limites d'affichage. Au final le temps de dev d'un jeu 2600 peut etre infini selon le niveau d'optimisation qu'on a besoin)

Ce qui m'a le plus stressé comme defie c'est de faire tenir tout le code d'auto-génération du Kernel dans 8 scanlines qui est l'espace "vide" entre 2 lignes d'aliens car pour chaque lignes d'aliens je dois générer un nouveau Kernel en RAM qui correspond au particularité d'affichage de cette ligne (quelle sont les aliens affichés et leurs positions) et donc je dois le faire juste avant dans l'espace qu'il y a entre 2 lignes d'aliens et si je veux respecter la version arcade c'est 8 lignes d'espace pas plus et au debut quand je faisais des estimations a la louche j'imaginais plutot avoir besoin d'une trentaines de scanline.
Je me suis arraché les cheveux sur ce probleme (et j'y suis toujours), j'ai du tenter plusieurs aproches differentespour déférer un maximum de tache en amont mais sans non plus bouffer trop de RAM dont je manque aussi.

D'autant que ces 8 lignes de "vide" ne sont pas vide, il faut continuer de gerer l'affichage des missiles et donc cette espace vide est lui meme un Kernel qu'il faut syncroniser avec le balayage en meme temps que tu dois executer tout le code pour auto-générer le Kernel suivant.

On pourait imaginer une autre solution brute, stocker sur la cartouche toutes les versions possible de kernel selon la configuration des aliens et leur position mais faudrait stocker sur la cartouche 6608 Kernel different, faudrait environ 400Ko (une cartouche megadrive) au lieu des 4Ko dispo. Donc c'est a ca que me sert l'auto-génération du Kernel, a avoir le Kernel adapté a chaque situation mais avec peut d'espace.

Je commence a voir le bout (juste du Kernel), j'ai reussi a mettre a peu pret tout en place dans mon Kernel et ca rentre. Sauf si une éniéme mauvaise surprise je commence a croire que c'est possible et je pense pas que cela a deja ete fait ce qui rend le truc plus excitant mais le defi est enorme (heureusement qu'on ne sait pas ce qui nous attend quand on demarre un truc comme ca sinon on le ferait pas)

Les autres difficultés c'est bien sure la quantité de RAM bouffé en partie par mon Kernel et meme la quantité de ROM car pour optimiser le temps d'execution (meme en dehors du Kernel je sais pas si j'aurais asser de temps d'execution pour le reste) j'hesite pas a faire de bon gros paquet de code qui prennent de la place au lieu de faire des boucles (avec seulement 3 registres dans le CPU les boucles peuvent etre un peu couteuse) mais au moins la ROM j'aurais toujours l'alternative du bankswitching pour passer a 8Ko meme si je préfèrerais rester sur une cartouche normal de 4Ko.

Bref la tension est vraiment maximum partout, sur le temps d'execution (Kernel et hors Kernel) sur la RAM et la ROM, et généralement optimiser l'un c'est au detriment des autres donc toujours des choix corneliens a faire car il est difficile d'estimer ce qui va le plus te manquer a la fin donc j'essai d'etre sur tous les fronts ce qui nécéssite de passer pas mal de temps sur chaque ligne de code.
Par contre maintenant je connais par coeur le temps d'execution de la plupart des instructions et leur taille en octet, ca devient un reflexe de tout calculer 






J'ai passé aussi un peu de temps a etudier la version arcade (sur emulateur) pour prendre toutes les mesures, les tailles, les espaces, les deplacements, les sprites...

Pour les sprites j'en suis la



version arcade a gauche (j'ai juste zoomé les pixels 3x3) et la mienne a droite (avec des pixels de 5x3 pour respecter le ratio 2600). J'ai moins de pixels donc c'est pas evident mais ca ressemble quand meme bien mieux que la version 2600 tout en respectant le fait qu'ils ont pas tous la meme taille (celui du haut fait seulement 5 pixels de large)

la VO 2600 asser eloigné de la version arcade (dans le fond et dans la forme)



Si vous pensez avoir une meilleur composition de sprite en gif n'hesité pas a proposer.
C'est 5x8 pixels pour celui du haut mais on pourait monter a 6x8. Pour celui du milieu c'est 7x8 mais 8x8 serait pas genant si le précedent est en 6x8, et 8x8 pour celui du bas. Faut utiliser des pixels de 5x3 comme dans mon Gif pour respecter le ratio.
J'aimerais bien voir une serie 6x8, 8x8, 8x8 au lieu de 5x8, 7x8, 8x8 mais les tentatives que j'ai fais rendait pas terrible, j'etais plus a l'aise avec les valeurs impaires.

[upsilandre]

J'ai modifié un peu mes sprites, j'ai elargie celui du haut (6 au lieu de 5) et celui du milieu (8 au lieu de 7). Ca me permet un alignement plus juste et je trouve que celui du milieu (qui est emblematique du jeu) a une meilleur gueule en etant un peu plus large.

[Hobes]

Je ne pense pas qu'on puisse faire beaucoup mieux niveau sprite avec quelque chose d'aussi petit. Faudrait un peu plus de pixels et de couleurs pour faire un truc intéressant. Là en deux secondes :



Une base pour la version Megadrive

[upsilandre]

pas mal 
sur 2600 y a meme pas de pixel art

[upsilandre]

Y a un autre truc qui me complique beaucoup les choses c'est que le systeme d'affichage deja complexe ne suffit pas a repondre a certain cas particuliers qui necessitent une autre methode et faut alors combiner les 2 selon le cas sans que ca se voit a l'ecran!
Et cela complique autant la gestion de l'affichage que la gestion des deplacements aussi qui doivent etre traité differement selon les 2 cas.
Deplacement qui eux meme ne sont pas si simple dans space invader, ce n'est pas juste une pattern prédefinie. L'amplitude des deplacements change selon le contexte, quand on detruit une colone complete on donne plus d'amplitude aux survivants ect... jusqu'a ce que le dernier survivant qui peut etre n'importe lequel des aliens du depart, ait une amplitude de mouvement total. ca rajoute encore pas mal de contraintes.





Sur cette image random j'ai illustré les differentes categories d'aliens du point de vue du Kernel.
Y a les colones "P0" qui sont les sprites qui utilisent le sprite hardware "Player 0" que je reset avec un timing tres particulier et une configuration des registres d'etat particuliere du TIA pour reussir a en faire des copies successives sur la meme ligne, et les colones P1 qui utilise le sprite "Player 1".

Sauf que la methode d'affichage fonctionne seulement si y a plusieurs sprite P0 ou P1 sur la meme ligne. Quand il n'y a plus qu'un seul sprite P0 ou P1 sur la meme ligne comme c'est le cas des 2 specimens que j'ai entouré en rouge alors je suis obligé d'utiliser une autre methode completement differente pour l'affichage et la gestion du positionnement qui doit parfaitement s'integrer a la premiere.

Tout ca rend l'optimisation (RAM, ROM, Cycle CPU) compliqué car c'est toujours de ca qu'il sagit (si y avait pas de contrainte de ressource rien ne serait compliqué).
Notement j'ai beaucoup reflechie a la facon dont je dois encoder les informations d'etat des aliens (lesquels sont present ou absent, lesquels sont P0 et P1 et a la fois seul sur la meme ligne) et les informations de deplacement et positionement (selon qu'ils sont seul P0 et P1 sur leur ligne ou pas)
Comment encoder cette information de la facon la plus econome en RAM mais tout en s'assurant quelle reste facile et rapide a exploiter (notement par le Kernel qui est limité a des traitements rudimentaires)
Y a toujours des informations qu'on peut déduire d'une autre ou plusieurs informations qu'on peut encoder dans un meme octet sur des bits differents mais au prix de quelle quantité de traitement, de quelle complexité? (et cout en ROM)
La recherche aussi d'une certaine "universalité" notement pour pouvoir précomputé au maximum le "RAM kernel" en debut de frame et reduire au maximum la tache de construction qu'il faut faire entre les lignes d'aliens


Des tatonnement qui m'ont deja value de recommencer une fois presque a zero car c'est au fur et a mesure de la progression qu'on constate les failles de certain choix... et c'est ce que je vais faire a nouveau (recommencer a zero ou presque) car j'ai trouvé une autre facon d'encoder l'information et de gerer tout ca qui pourait me faire economiser pas mal de RAM (au moins une douzaine d'octet ou plus), beaucoup de ROM (ca devrait régler définitivement ce probleme) tout en reduisant la complexité de l'ensemble donc que du win-win qui fait que je peux pas me permetre de ne pas en tenir compte.

Je suis en congés cette semaine, c'est pour ca aussi que je vais me permetre ce luxe de recommencer meme si ca m'enchante pas trop mais le niveau d'optimisation que ca pourait me permetre d'atteindre suffit a me motiver.

[upsilandre]

J'ai bossé la journée la-dessus et meme si j'ai pas encore terminé de tous ratraper, les effets benefiques de cette nouvelle aproche sont deja stupéfiant a tous les niveaux et meme plus que j'imaginais. Je regrette pas l'effort.
Au debut ca m'a fait mal au cul d'effacer ou modifier la majorité de mon code mais maintenant c'est un regale de voir le resultat, mon code est tellement plus beau maintenant, c'est comme un petit bijou!
C'est dans ces moments la qu'on prend son pied, cette jouissance du codeur que seul ceux qui ont deja codé connaissent .

J'ai gagné pas mal de RAM (17 octets ce qui est beaucoup car j'ai seulement 75 octets pour gérer le jeu, le reste c'est le ram-kernel) et j'ai beaucoup simplifié le code ce qui m'a fait gagner beaucoup en ROM (juste avant j'etais deja a quasiment 2Ko de code soit deja la moitié de la cartouche, j'ai divisé ca par plus de 2! donc maintenant je suis a l'aise), et donc gagné en temps CPU et en clareté. ultra bénéfique a tous les niveaux.

J'y retourne. Me reste encore a refaire le code des deplacements lateraux et de l'anim et je serais revenu ou j'en etais juste avant mais avec encore de meilleur base qui cette fois seront les bonnes je pense. Plus motivé que jamais.

[upsilandre]

En tout cas j'ai deja depassé l'etape ou j'en etais avant mon reboot, j'ai maintenant mon paquet de 50 aliens qui s'affiche sans bug quelque soit la combinaison d'aliens vivants et morts et donc quelque soit les cas particuliers et ils se deplacent lateralement et s'animent sans bug en adaptant l'amplitude de deplacement au contexte.
Ca au moins c'est fait et bien fait car le code pour l'instant est tres propre (grace au reboot).

Un petit bilan des ressources que j'utilise a ce point d'avancement:
- 988 octets de ROM (sur les 4Ko), 90% code, 10% data
- 69 octets de RAM (sur 128), 74% pour le Kernel
- 25% du temps CPU de la phase de blanking vertical (c'est a dire or phase d'affichage)

Pour l'instant ca tient la route mais il reste difficile de dire si ca sera suffisant car il reste beaucoup a faire.
Prochaine etape, integrer l'affichage des missiles (dans un premier temps celui du joueur) ce qui peut etre un bon bordel car les missiles vont devoir traverser une douzaine ou quinzaine de Kernels differents (rien que l'affichage des aliens c'est une alternance de different Kernels , les kernels qui affichent les aliens et ceux qui sont entre les lignes d'aliens, va falloir traverser cette succession de 10 Kernel sans bug).
J'ai bien sure deja du y penser en amont car fallait que je prenne cela en compte dans la mise en place de mes Kernels mais j'ai quelques craintes.

Pour ca je vais peut etre dabord commencer par ajouter le sprite du player et son controle (deplacement et tire), ca facilitera ensuite les phases de test de l'affichage du missile que je pourais tester ingame.

[upsilandre]

L'art de l'alignement du code et des datas

Y a certaines instructions qui ne prennent pas le meme temps d'execution selon le contexte. Sur n'importe quelle machine on s'en fouterait pas mal mais sur 2600 y a tellement souvent des dependances de timing au cycle CPU pret que c'est important a comprendre.

Le cas le plus classic c'est l'instruction de branchement conditionnel, quand la condition est remplis et qu'il y a branchement ca prend 1 cycle de plus que quand y a pas branchement mais ca concerne aussi notement toutes les instructions qui utilisent un adressage indexé.

Par exemple le code lda $FE12,x ca veut dire charger dans l'accumulateur (lda = load A, c'est l'operateur) qui est l'un des registres 8bit du CPU, la valeur qui se trouve a l'adresse $FE12 (l'operande) une adresse 16bit en hexadecimal qui pointe vers la fin de la cartouche a laquel le CPU va ajouter la valeur du registre 8bit X (l'index).
donc si y a 0 dans X on va charger dans A la valeur qui se trouve a l'adresse $FE12. Si y a 1 dans X on va charger l'octet d'a coté ($FE13) ect...
L'adressage indexé on l'utilise tres souvent d'autant que dans le CPU 6502 y a pas de registre 16bit qui pourait servir de pointeur direct qu'on pourait alterer a sa guise donc on passe souvent par ce type d'indexation 8bit.

Mais c'est une indexation de 8bit donc ca permet juste de s'eloigner de 256octets au dela de l'adresse orignel indiqué dans l'operande mais l'avantage aussi c'est que pour le CPU la plus part du temps ca simplifie le traitement, il va juste additionner l'index de 8bit au seul 8bit de poid faible de l'adresse 16bit...
Mais lorsque l'indexation est a cheval entre 2 pages ca implique une retenu lors du calcule d'indexation qu'il va cette fois falloir reporter sur les 8bit de poid fort de l'adresse 16bit ce qui va ajouter un cycle d'execution pour cette instruction et peut donc te poser des problemes un peu imprevisible car ca dependera donc de la facon dont tu as aligné tes datas (faut préciser aussi que par commodité on ne manipule pas directement les adresses en general mais des labels, des mnemoniques, qui sont des mots qu'on choisie et qu'on associe a des zones de code et de data et c'est ensuite au compilateur d'associer des adresses a ces mots donc on ne visualise pas directement ces adresses quand on code).

Je vais prendre l'exemple qui m'est arrivé (y a deja quelques semaines).
Mon kernel qui affiche les aliens doit a chaque nouvelle ligne de balayage charger la ligne du sprite correspondant donc bien sur j'utilise un adressage indexé avec comme operande l'adresse originel du sprite puis comme indexe la ligne du sprite a afficher (0,1,2,3,4,5,6 ou 7).
Il se trouve que j'ai un sprite (8 octets) qui se trouvait pile entre 2 pages, genre il demarre a $F0FC et termine a $F103 donc on passe de la fin de la page $F0xx au debut de la page $F1xx (y a 16 pages sur une cartouche 4k) du coup la seconde moitié de mon sprite s'est retrouvé decalé de 3 pixels (un cycle CPU = 3 pixels de deplacement du canon a electron).
Heureusement c'est asser simple a regler. On peut indiquer au compilateur a quelle endroit de la cartouche on veut placer ceci ou cela , donc j'ai forcé l'alignement de mes datas sur une page precise ($FE00). J'ai pour l'instant reservé juste les 2 dernieres pages de la cartouche pour mes datas.


Mais y a pire, le probleme peut se poser aussi pour du code. J'evoquais les branchements conditionnels qui prennent un cycle de plus quand le branchement doit etre executé mais ils prennent un second cycle de penalité si ce branchement n'est pas sur la meme page (donc un branchement conditionnel classic peut prendre 2,3 ou 4 cycle selon le contexte) pour les meme raison que précedement.
Le branchement conditionnel utilise donc aussi un indexe de seulement 8bit, la seul difference c'est qu'il est signé donc ca permet de faire un branchement jusqu'a 127 octets en avant ou 128 octets en arriere, alors que l'adressage indexé classic c'est 256 octets en avant.

Et il se trouve que j'ai eu aussi ce probleme y a quelques jours, un truc de dinge.
Le branchement d'une routine strategique qui sert justement a  a selectionner un moment precis du balayage horisontal pour ensuite positionner un sprite et qui donc est une routine de timing s'est retrouvé pile entre 2 pages alors que c'est une boucle de seulement 2 instructions! Y avait une instructions a la fin d'une page et l'autre instruction au debut de l'autre et du coup le timing etait faussé et le positionnement du sprite aussi 
C'est asser imprevisible car t'es tout le temps en train de modifier et ajouter du code ce qui deplace tout le code qui suit. Ici je me suis juste contenté d'ajouter du code, vouloir aligner strictement certain bout de code ca serait des contraintes plus qu'autres choses. Faut juste garder a l'esprit que ca peut arriver.

Heureusement dans les 2 cas j'ai vite cerner d'ou venait le probleme et maintenant je suis prevenu.

[upsilandre]

J'ai integré le joueur toujours en respectant les codes graphiques du jeu d'arcade et j'ai donc ajouté aussi le tire du joueur.
Quand le missile traverse les lignes d'aliens il y a 2 types d'affichages differents (quand il traverse les lignes d'alienes et quand il traverse les lignes intermediaire entre les aliens)
J'ai reussi a bien gérer ces transitions sans que ca se voit mais il a fallu quand meme que je modifie un peu mon ram-kernel, heureusement ca n'a pas ete des modifications lourde de consequence. C'etait ma crainte mais au final j'ai juste eu a remplacer une instruction par une autre et changer l'ordre de certaine instructions, sans consequence.
Et j'ai reussis a le faire en economisant les 5 octets de RAM tampon que j'avais prevu d'utiliser pour l'affichage du missile en zone aliens (grace au faite que j'ai encore du temps CPU dispo entre les lignes aliens)

la ROM V0.1
http://www.petit-fichier.fr/2014/01/14/siv0-1/

[upsilandre]

J'ai ajouté de facon aleatoire des tires aliens juste pour tester l'affichage de 2 missiles simultanés sur la meme ligne comme ca sera le cas au final. Donc quand le joueur ne tire pas alors les missiles aliens sont affichés normalement mais quand le joueur tire alors les missiles aliens et joueur sont affiché en flickering en alternance comme prevu, ca marche bien et sur mon plasma ou ma vieille TV ca reste discret (comme dans la version officiel 2600).

J'ai continué a ameliorer l'affichage des missiles car sur les 14 kernels que traversent les missiles y avait encore des transitions bugé dans la partie inferieur que j'avais pas bossé (juste au dessus du joueur, au niveau du joueur et en dessous du joueur, et aussi tout en haut de l'ecran) maintenant c'est nickel. Restera a ajouter encore les boucliers et donc encore de nouvelle fragmentation vertical de l'affichage a gérer.

Mais surtout j'ai ajouté les tests de collision avec les aliens et on peut donc maintenant les eliminer et donc commencé a vraiment tester le jeu. J'ai aussi ajouté l'acceleration des aliens au fure et a mesure qu'on les elimine.
J'ai deja commencé aussi a calibré au mieux par raport a la version arcade. Amplitude de deplacement joueur et aliens, vitesse de deplacement, vitesse des missiles.
Ca ressemble deja pas mal a la version arcade.

Pour ceux qui veulent chercher des bugs
ROM V0.2
http://www.petit-fichier.fr/2014/01/15/siv0-2-1/

[Hobes]

J'imagine que c'est parce que c'est une version encore en cours de développement mais j'ai relevé :

- des tirs aliens qui partent de tout à gauche (ou droite) ce qui est surprenant car il n'y avait pas d'aliens à cet endroit là
- l'espace vide entre le bord de l'écran et le joueur qui est plus grand à gauche qu'à droite (à quoi sert-il d'ailleurs ?)
- l'accélération des aliens m'a paru un peu surmultiplié (on part d'un tempo très lent à quelque chose d'assez rapide)
- sans que ces aliens descendent, c'est déjà très difficile, niveau réglage c'est comme à l'époque ?

[upsilandre]

- des tirs aliens qui partent de tout à gauche (ou droite) ce qui est surprenant car il n'y avait pas d'aliens à cet endroit là

Comme j'expliquais un peu plus haut j'ai ajouté ces tires aleatoires juste pour tester l'affichage multi-missile (et le flickering), le bute final etant que les tires viennent bien sure des aliens eux meme selon leur position et leur hauteur 

- l'espace vide entre le bord de l'écran et le joueur qui est plus grand à gauche qu'à droite (à quoi sert-il d'ailleurs ?)

Ca c'est le probleme du mode d'affichage et des trick que j'utilise, je ne peux pas deplacer les aliens a l'extreme gauche (au mieux je peux afficher les aliens 19 pixels apres le bord gauche de l'ecran pour des questions de timing) donc je suis obligé de décentrer la zone de jeux sur la droite (pour centrer la zone de jeu faudrait que je la deplace de 10 pixels sur la gauche ce qui n'est pas possible ou alors que je reduise l'amplitude de deplacement des aliens sur la droite mais ca ne serait plus conforme a la version arcade, ou que je n'affiche que 9 aliens au lieu de 10 mais idem...).
J'aurais voulu ajouter une petite bande vertical de couleur sur le coté gauche pour mieux délimiter la zone de jeu (d'ailleur le jeu d'arcade utilise un ecran incliné donc avec un ratio plutot 3/4 que 4/3) mais ce n'est pas possible, je ne peux strictement rien ajouter graphiquement dans toute la zone ecran ou y a les aliens (et une bande aurait de toute facon fait aparaitre le bug du HMOVE qui prolonge le blanking horisontal de 8 pixels chaque ligne ou tu l'utilises et qu'on voit dans pas mal de jeu, au moins dans le noir on voit rien). J'essayerais quand meme d'illustrer la zone de jeu décentré avec d'autres repères visuels.

Pour ce qui est de l'espace vide qu'il y a quand meme entre le joueur et les limites de la zone de jeu ca je l'ai repris du jeu originel. En effet le gameplay d'origine t'empeche de pouvoir toucher la colone d'aliens quand elle est tout a gauche ou tout a droite (sur la version 2600 c'est encore plus marqué, les aliens sont vite hors de porté de tire, la j'ai juste repris la configuration arcade) ca fait partie des contraintes du gameplay.

- l'accélération des aliens m'a paru un peu surmultiplié (on part d'un tempo très lent à quelque chose d'assez rapide)
- sans que ces aliens descendent, c'est déjà très difficile, niveau réglage c'est comme à l'époque ?

je pense aussi que c'est plus difficile du fait justement que les aliens ne descende pas car quand ils descendent ca augmente ta cadence de tire (plus tu touche rapidement plus vite tu peux retirer, le gamedesign c'est "un seul tire a l'ecran") et puis ca aide a mieux viser quand il se raproche surtout les petits tout en haut pour les shooter c'est pas evident si ils ne descendent pas d'autant que c'est souvent les derniers et donc aussi les plus rapide.
De toute facon c'est juste des configurations de test provisoire, c'est a regler a la fin et malheureusement j'en suis loin  :cry2:

Cette version c'est surtout pour tester
- que les aliens touchés par un tire disparaissent bien (et pas un autres)
- que les deplacements aliens s'adaptent bien au contexte (quand on detruit une colone)
- qu'il n'y ai pas de bug d'affichage (a part pour les tires aliens qui sont souvent hors zone de jeu la ou ils ne doivent pas etre)