Hardcore Retrogaming

Le Kernel
Ce qu'on appelle le Kernel dans le contexte de la 2600 c'est ce petit bout de code CPU de quelques dizaines d'instructions au mieux qui va gerer l'affichage en alimentant le TIA pendant le balayage de l'ecran.

Si on devait resumer la programmation sur 2600 c'est sans hésité cela qui caracterise le mieux la 2600. La programmation du Kernel c'est une demarche intellectuel vraiment a part, y a le Kernel et le reste du code.
C'est meme quelque chose qu'apriori on ne retrouve sur aucune autre machine, ni la Channel F ni la NES ou autres donc si on veut s'interresser a la programmation Atari 2600 c'est la dessus qu'il faut se pencher, c'est la qu'est le fun.
Dailleurs quand on a une idée de jeu 2600 la premiere chose a faire c'est le Kernel. C'est lui qui va definir ton jeu de par les fortes contraintes d'affichages qui sont omnipresentes. Pas la peine de partir sur une idée de jeu si tu n'as pas dabord verifier que tu auras un Kernel qui poura afficher les elements dont tu as besoin.
Le Kernel est vraiment comme un puzzle, chaque instructions doit resulter d'une longue reflexion et toutes les notions de timing doivent etre parfaitement maitrisées.


----------------------------------------------------------------------------


Sur Combat le Kernel est simple dans le sens ou il utilise pas vraiment de trick si ce n'est que (surtout dans ma version boosté) il a fallu quand meme que je combine tous les elements graphiques (les elements playfield PF0,PF1 et PF2 + les sprite P0 et P1 + les missiles P0 et P1 + la balle + la possibilité de switcher le playfield avec le meme Kernel) ce qui au final a demander des efforts pour tout faire entrer, en général t'evite de tout utiliser en meme temps.


Sur Space Invaders c'est un Kernel plus complexe car faut passer par des tricks, la 2600 etant faite pour afficher seulement 2 sprites (8x1) c'est pour ca que je m'y interresse.
Space invaders necessite l'affichage de beaucoup de sprites a l'ecran et notement de 6 sprites sur la meme scanline (+ au moins un missile).
Faut se poser la question du niveau d'independance de ces sprites qui heureusement ne le sont pas enormement. Ils ne sont pas visuellement independant (ils ont la meme aparence sur toutes la lignes) et ne sont pas independant non plus dans leur mouvement (ils se deplacent a l'unisson) mais sont independants en ce qui concerne leur vie et leur mort, faut pouvoir gerer individuellement leur affichage (c'est la que se trouve la difficulté).


Moi ce qui m'interresserait c'est pas de faire une copie conforme bien sure sinon l'excercice est moins motivant.
j'ai 2 idées pour Space invaders, soit tenter de faire une version qui se raproche + de la version arcade (qui a des lignes de 11 aliens au lieu de 6 dans la version 2600) soit une autre idée que je devoilerais pas puisque l'interet est dans la surprise (je pense qu'il y a un truc a faire en reprenant des vieux jeux comme ca srtictement a l'identique mais en changeant un truc pour prendre le joueur a contre-pied)
Je vais de toute facon commencer dabord par la premiere idée.


------------------------------------------------------------------


Pour augmenter le nombre de sprite sur une meme ligne (tout en pouvant gerer individuellement leur affichage) j'ai 3 idées de kernel toutes radicalements differentes et avec des inconvenients differents, difficile de se décider.

- Ma premiere technique serait de reprendre la methode de l'original et simplement de répartir le kernel sur 2 frames et donc afficher 2x6=12 sprites mais en flickering (6 sur une frames, 6 sur une autres), ca au moins c'est quasi sur que ca marchera (meme si ca sera pas facile quand meme) et le resultat sera correct modulo le flickering

- la seconde idée que j'ai eu et que j'aime beaucoup utilise des trick de timing et de reset des sprites compliqué a expliqué et surtout de combiner ca a l'idée de placer le Kernel en RAM au lieu qu'il soit en ROM
Sur atari 2600 on met pas de code en RAM, le code est en ROM et la RAM sert juste pour les variables mais un kernel d'une seul scanline ca peut tenir en RAM. Ca me prendra alors une bonne moitié de la RAM et donc ca me laissera l'autre moitié pour le jeu, ca peut le faire (sur tank2600 j'ai utilisé seulement la moitié de la RAM)
Et surtout avoir le Kernel en RAM combiné a la programmation en assembleur ca permet un truc enorme qui est de produire du code qui va pas juste produire et modifier des datas mais produire et modifier de l'op-code et donc modifier du code avec du code!
Quelle interet de modifier son propre code avec du code? normalement quand on veut un code dynamique on se contente d'y mettre des branchements conditionnels (si "ceci" alors executer tel code sinon executer tel autre code) sauf que ces branchement conditionnels ca prend du temps d'execution qu'on a pas ici.
Avec un Kernel en RAM je peux remplacer ces branchements conditionnels (qui ici servirait a decider si tel ou tel sprite de la ligne est vivant ou mort et donc si on doit l'afficher) par des modifications direct du code du Kernel pendant l'execution du jeu et donc me passer de ces branchement qui de toute facon ne pourait jamais entrer dans le Kernel donc ca ouvre de nouvelle possibilité.
Reste qu'il faut quand meme trouver le moyen d'afficher tous ces sprites et pour l'instant la solution que j'ai n'est pas completement satisfaisante, je peux afficher les 11 sprites de la version arcade (et cette fois sur la meme frame, sans flickering) et controler individuellement l'affichage de chaque sprite (si j'arrive a mettre mon kernel en RAM) mais ca me cause des problemes d'alignements. les sprites ne sont pas parfaitement espacés, un coup y en a un 2 pixels trop a gauche, l'autre 2 pixels trop a droite... et de plus ca pose aussi des problemes pour afficher l'explosion de l'ennemie quand on le touche.
Ca peut sans doute marcher comme cela mais ca sera pas propre (probablement moins finalement que la methode avec flickering) et pour des raisons complexes de timing ce n'est apriori pas soluble mais juste parce que j'adore cette idée de Kernel en RAM ca me donne quand meme envie d'essayer meme si ca me parait beaucoup de boulot pour pas grand chose si le resultat est trop crade.

- la 3eme technique que je peux pas expliquer non plus en 2 lignes me permetrait d'afficher 8 sprites sur la meme frame (sans flickering mais 8 c'est pas comme l'arcade quand meme) et sans probleme pour gerer l'explosion des ennemies mais des espaces trop grand entre les sprites.
Au final pas interressant a utiliser ici mais quand meme interressant par le faite que c'est encore une autre methode completement differente et ingenieuse qui merite d'exister.




Pour l'instant je sais pas trop par quoi commencer pour ce space invaders mais en tout cas je suis pret a y aller.
J'ai pris le temps de creuser certain element notement le fonctionnement interne du systeme de positionnement horisontal des elements graphiques. J'ai tout bien compris, les systemes des compteurs internes, de syncronisation, pourquoi y a pas de foutu registre de position horisontal, comment fonctionne en interne le HMOVE et pourquoi il crée une ligne noire de 8 pixels en debut de scanline ect... j'ai tout capté. Pour l'instant j'ai plus vraiment de point d'interrogation sur le hardware Atari 2600 (meme le bank switching que j'ai pas encoré exploré j'ai quand meme une idée asser precise de comment ca marche).
J'ai aussi revu ma facon d'organiser le code que ce soit visuellement ou structurellement pour partir sur une meilleur base, me manque plus que l'experience que rien ne peut remplacer...

ouah ! upsi, c'est quand que ton cerveau prend du repos ???
sérieux, tu m'impressionnes dans ta démarche

Doc 42 a écrit:

toujours aussi passionnant de lire tout ça   

En fait si on grossi un peu le trait, la Channel F est un peu l'ancètre des CPU CISC (8086,286,etc..) et du PC (bios, RAM++, concentration des taches au niveau CPU)
et la 2600 l'ancètre des machines à multiples copro types Atari ST , Amiga, et les consoles 8 et 16 bits.
 (surtout que la boite ayant fait ce proc -MOS Technology- a été racheté par commodore)
marrant de voir comment tout a débuté...

ce 6502 c'était un sacré proc...  j'ai pas résisté à relire des trucs sur ce CPU et c'est vraiment le coup de génie de l'époque (74-75) aussi puissant mais bien moin cher que la concurrence (et a une fréquence inférieur ce qui est positif à plusieurs niveaux) sans compter qu'il pouvait s'utiliser avec des RAM peu rapide donc là aussi moin cher.

une pub de l'année de notre naissance :

Spoiler:

Et je découvre que le T800 de Terminator (1984) affiche du code asm 6502   

c'est vrai qu'on est né en meme temps que les CPU
l'année 1974/1975 c'est l'année des CPU
le 8080 d'Intel
le 6800 de Motorola
le F8 de Fairchild
le 6502 de MOS
le Z80 c'etait en 1976

fdroopy a écrit:

ouah ! upsi, c'est quand que ton cerveau prend du repos ???
sérieux, tu m'impressionnes dans ta démarche

en attendant aussi j'ai toujours pas joué a Killzone

Sur Atari 2600 y a eu un accessoire tiers interressant qui s'appelait le Supercharger




On enfilait ca dans le port cartouche puis on branchait la prise jack sur n'importe quelle lecteur de cassette audio et on pouvait alors charger des jeux a partir de cassette audio (comme sur les micro-ordinateur) dans une RAM de 6Ko
Ca boostait pas mal les possibilités des quelques jeux qui utilisait cette accessoire (j'ai lu un peu les details techniques, apres calcule je dirais que ca donne un debit aproximatif de 0.4Ko/s + des phases de préparation avant et apres)
C'est un peu le 64DD ou le disk system de l'Atari2600 (enfin pas vraiment puisque c'etait pas un accessoire Atari, juste un editeur tiers)

Frogger version classic




Frogger version Superchager




Le truc sympa c'est qu'en suite ca a servie en quelque sorte de devkit pour le homebrew, ca permetait de programmer ses jeux sur PC et ensuite de les convertir en fichier audio .WAV et de les envoyer dans le supercharger pour y jouer.
Y a eu aussi des compiles de jeux sur CD audio



des manettes wirless






Un des derniers jeux d'Atari que j'ai decouvert et que je trouve tres impressionnant autant pour la physique de la balle que pour la definition de l'affichage.
La 2600 est vraiment pas faite pour afficher des graphismes aussi fin (seul les sprites ont cette precision donc le flipper est a priori un assemblage de sprite 8x1 monochrome tres ingenieux, il a fallut organiser chaque ligne du flipper pour que l'agencement des pixels soit compatible avec une combinaison de sprite et de couleur)





Sinon j'aimerais bien aussi avoir le temps d'essayer de faire une demo 3D, juste faire tourner un cube en flat 2 couleurs en 3D avec le joystick. Je me dis que c'est peut etre possible, dans une fenetre de 48x48pixels en flickering pour avoir les 2 couleurs reste toujours le probleme de l'absence de VRAM
Pour faire de la 3D faut pouvoir rasteriser les polygones dans un buffer, je pourais me faire un semblant de framebuffer 48x48 en RAM mais il me faudrait au moins 350 octets de RAM en tout (300 pour le framebuffer et une cinquantaine pour le reste) mais y en a que 128 dans la 2600

Mais dans la liste des nombreuses cartouches customs qui ont ete commercialisées (avec different mode de bankswitching pour étendre les capacités) y avait notement les FA de CBS (les noms des types de cartouche sont souvent liés a leur systeme de bankswitching et notement au hotspot, ces adresses particulieres qu'on utilise pour faire switcher les banks, FA est une adresse en hexadecimal, y avait aussi les cartouches F4, F6, F8...) qui ont servies pour quelques jeux edités par CBS.
J'en ai trouvé seulement 3 dont un dans une sorte de raycasting facon wolfenstein + une 4eme resté a l'etat de prototype d'une sorte de simulateur de vole.

L'interet de ces cartouches FA de CBS c'est qu'au dela du tripple bank switching (donc 12Ko) elles ajoutaient 256 octets de RAM (les cartouches "superchip" d'Atari ajoutait seulement 128 octets de RAM), du coup 128 + 256 = 384 octets de RAM, ca pourait coller pour faire une petite demo 3D
Reste a voir si y a suffisement de temps CPU (toujours dans le blanking vertical), va falloir faire des multiplications 16bit avec un CPU qui ne fait que des additions 8bit mais bon y a seulement 8 vertices dans un cube, meme si je suis obligé de rafraichir a 60fps ca parait pas insurmontable comme charge, la rasterisation reste probablement la charge la plus lourde.

Le probleme c'est aussi les couleurs, me faudrait 3 couleurs (+ background) pour faire un cube 3D correct (ou simuler le lighting des 3 faces visible) or pour en avoir 2 je vois deja pas comment faire sans bidouiller avec le flickering (2 frames monochrome) et a 2 couleurs ca va pas rendre terrible
Sinon le faire en wireframe.
enfin tout ca c'est si j'avais le temps...

impressionnant le flipper !

C'est une cartouche F6 (donc une cartouche Atari a quadruple bankswitching = 16Ko mais pas de superchip donc pas de RAM suplementaire)
Le systeme de collision de la balle a pas du etre facile

Le truc a savoir avec ces cartouches qui integre de la RAM c'est que le port cartouche n'est pas cablé en signal W/R (write/read) contrairement a la RAM interne a la console par exemple et ce signal W/R envoyé par le CPU (selon le type d'instructions executés) est important pour que la RAM sache si c'est une phase d'ecriture ou de lecture du coup la RAM de ces cartouches ,qui est handicapé sur ce point, utilise une ruse.
Chaque octet de cette RAM est accessible par 2 adresses differentes, une adresse qui sert a lire et une qui sert a ecrire (au lieu d'avoir simplement une seul adresse couplé a un signal W/R). En faite ca revient a utiliser l'une des 13 lignes d'adressage comme un signal W/R mais en utilisant cette ligne d'adressage ont divise alors par 2 la gamme d'adressage avec donc cette effet mirroir ou chaque cellule RAM se retrouve avec 2 adresses.

Reste un inconvénient sans solution c'est que certaines instructions CPU combinent a la fois lecture et ecriture a une seul et meme adresse, par exemple l'instruction d'incrementation d'une valeur en memoire (INC $XX) qui consiste dabord a lire la valeur a l'adresse $XX puis incrémenter puis ecrire la nouvelle valeur a l'adresse $XX tout ca en une seul instruction CPU. Ce genre d'instructions ne peut pas fonctionner avec les upgrades de RAM dans les cartouches.

Faut aussi prendre en consideration que la RAM interne a la console de 128 octets a cette particularité d'etre dans la toute premiere page d'adressage c'est a dire dans les 256 premiers octets des 8Ko adressable par le CPU (c'est le cas aussi des registres du TIA, le chip video/audio) et y a des instructions CPU qui sont specifique a l'adressage de cette page 0 qui a l'avantage de pouvoir donc etre adresser avec une simple adresse 8bit au lieu d'une adresse 16bit et du coup ce sont des instructions qui en general s'execute en 3 cycles au lieu de 4 donc plus rapidement qu'on pourait le faire avec la RAM des cartouches dont la zone d'adressage se trouve dans la seconde moitié des 8ko (plutot page 16 et 17)

Tout ca implique aussi une emprunte sur la ROM car cette RAM integré aux cartouches vient prendre des pages d'adresse a la ROM qui donc perd certaine pages qui deviennent inacessibles et cela pour chaque bank car dans ces cartouches en général la RAM est accessible quelle que soit le bank sur lequel tu as switchés
Ca veut dire par exemple que sur la cartouche FA de CBS qui est composé de 3 banks de 4Ko, les 256 octets de RAM occupent en faite 512 octets (pour la lecture et l'ecriture) mais cela dans chacune des banks soit en tout 1.5Ko!
Donc au final les 256 octets de RAM font perdre 1.5Ko de ROM (donc en tout on a pas 12Ko de ROM mais 10.5Ko + ce que coute le bankswitching qui necessite de dupliquer plus ou moins de code dans chaque bank)


C'est aussi ce que j'aime dans cette demarche c'est d'aller jusqu'a apprehender le cablage electronique pour mieux comprendre, pas forcement une nécéssité mais ca aide, pareille pour le chip video, vaut mieux comprendre certain cablage et fonctionnement interne pour mieux anticiper les comportements.

N'ayant pas trouvé de solution pour afficher un cube en 3 couleurs j'ai préféré laisser tomber cette idée et partir sur Space Invaders comme prevu

Je suis donc partie sur la methode qui utiliserait du flikering pour afficher 12 aliens par ligne (6 sur les frames paires et 6 sur les frames impaires).
J'ai bien reussi a les afficher mais pour les deplacements ca va etre plus chiant que ce que j'imaginais et surtout je me suis rendu compte que pour les tires (alien ou du joueur) je pourais pas utiliser les elements graphiques "missiles" car ils sont intimement liés aux sprites Player0 et Player1 que j'utilise pour afficher les aliens et dans un mode particulier qui empeche de pouvoir afficher en meme temps un missile convenablement.
Ainsi je suis obligé d'afficher tous les projectiles avec l'element graphique "ball" et donc pour pouvoir afficher en meme temps sur la meme ligne un tire ennemie qui tombe et un tire du joueur qui monte va falloir encore utiliser du flickering (afficher le tire des aliens sur les frame paires et le tire du joueur sur les frames impaires).

Du coup je comprend pourquoi dans la version original y a du flickering sur les tires (ca scintille) et ca m'a donné envie de tester le mode 2 joueurs car je me suis demandé comment ils geraient la situation ou les 2 joueurs tire en meme temps (ce qui peut vouloir dire au moins 3 tires sur la meme ligne) et bien ils l'ont géré tout simplement en t'empechant de tirer en meme temps que l'autre joueur   

Comme pour dans "combat", c'est ca qui est marrant quand t'essais de refaire ces vieux jeu tu comprend bien mieux certain choix inevitable pour cause de limitation hardware, c'est la que c'est interressant.

Au final cette histoire de devoir passer par la "ball" ca me complique les choses car j'ai deja les aliens qui sont affichés en flickering, si jamais le tire du joueur est aussi en flickering ca veut dire que le tire du joueur ne sera jamais affiché en meme temps que l'autre moitié des aliens qui sont affichés sur les frames paires. Du coup ca m'empeche d'utiliser les features de collision cablé dans la TIA (en gros il te previent quand il trace sur le meme pixel differents elements graphiques ce qui peut servir de test de collision "free") et m'obligera a coder en plus le systeme de collision


------------------------------------------------------------------


Du coup ces complications m'ont données envie de laisser ca de coté quelques temps et d'aller faire un tour du coté de la seconde methode que j'avais en tete, celle du code Kernel qui s'autogénère en RAM et qui me permet alors d'afficher 11 aliens comme en arcade et cette fois sans flickering.
Meme si je sais que le resultat ne sera pas bon car les deplacements seront un peu chaotique (je peux pas gérer la positions des sprites au pixel pret avec cette methode) cette idée de coder un Kernel qui s'autogénère en RAM est tellement exotique que ca donne envie de le faire juste pour le fun (et parce que ca donne toute sa legitimité au faite de coder en assembleur qui permet ce genre de fantaisie) car a ma connaissance jamais on fait ca en programmation.

J'ai effectivement reussi a placer mon Kernel special en RAM et a l'executer ainsi. Pour l'instant il s'autogénère pas mais au moins ca fonctionne et en plus ca ne m'a prit que 44 octets de RAM, si on ajoute les 4 que je réserve a la pile ca me laisse 80 octets de RAM pour le jeu, plus que j'esperais (je visais plutot les 50 octets) donc au moins sur ce point c'est parfaitement viable, un Kernel en RAM c'est possible sans bouffer toute ta RAM.

Mon bute ne va pas etre de faire le jeu complet avec cette methode, je voudrais juste faire vite fait un proto fonctionnel qui montre une ligne de 11 aliens qui se deplace de droite a gauche et vice et versa et que lorsqu'on appuit sur le bouton cela fasse disparaitre un alien au hasard puis 2, puis 3... juste pour démontrer que ca fonctionne (et voir a quelle point les deplacements sont chaotique selon les aliens qui disparaissent)


J'ai aussi eu l'occasion sur ces tests de faire mon premier Kernel "auto-synchrone".
Normalement le Kernel doit etre synchronisé avec le balayage horisontal de l'ecran et pour cela y a une fonction du chip graphique qu'on nomme "WSYNC".
Quand ont active ce registre du TIA alors le CPU se met en standby jusqu'a ce que la ligne en cours ait finit de s'afficher et que le TIA envoie alors le signal de synchro horisontal, a ce moment le CPU reprend son boulot et donc de facon synchrone avec l'affichage.
Mais la solution ultime c'est de coder un Kernel dont le temps d'execution soit exactement celui du balayage d'une ligne horisontal c'est a dire 76 instructions CPU. Ainsi tu n'as pas besoin d'utiliser la fonction WSYNC et donc tu economises 3 cycles CPU ce qui te permet de placer une instruction de plus dans ton Kernel, c'est la classe.

J'avais pas encore tenté de faire un Kernel auto-synchrone alors j'ai essayé.
Suffit donc de compter le temps d'execution de chaque instruction jusqu'a arriver a tomber sur le bon chiffre de 76 (quite a rajouter un cycle en utilisant par exemple un adressage 16bit sur une instruction qui pourait se contenter d'un adressage 8bit pour faire perdre un cycle)
On a beau savoir qu'en theorie ca doit fonctionner le faite de voir fonctionner du premier coup son premier Kernel auto-synchro c'est emouvant   

puis ensuite je l'ai viré car j'avais pas besoin d'un Kernel aussi long qui au contraire d'en mon cas etait penalisant vu qu'il occupe de la place en RAM mais au moins j'ai vu que ca marchait vraiment (sur Tank2600 ca m'aurait servie de gagner 3 cycles CPU sur mon Kernel)

Upsi, je pense que c'est pour toi :
https://archive.org/details/consolelivingroom

fdroopy a écrit:

Upsi, je pense que c'est pour toi :
https://archive.org/details/consolelivingroom

marrant la premiere review que je clic (frogger) y a un commentaire de celui qui l'a programmé en 1982, 16 semaines en tout et restait que 3 octets sur la cartouche 4Ko
https://archive.org/details/atari_2600_frogger_1982_parker_brothers_ed_english_david_lamkins_pb5300

j'avais pas vu mais on peut jouer a tout les jeux en emulation dans le browser
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

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    (au lieu de 6 dans la version original et 11 en arcade)

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.

J'aimerais bien que tu expliques plus sur l' auto génération du kernel d'affichage (mode asm nerd) quand tu le souhaiteras. peut être que pour l'instant c'est trop en évolution pour disséquer le truc sous tous les angles à froid.
En tout cas tout ce qui touche comme ça aux prise de têtes lié à de l'algo + astuces vis à vis d'un hardware donné au plus bas niveau possible c'est aussi un truc qui me fait bien kiffer.

Désolé pour les graphismes... je trouve que tu t'en sort très bien déjà je ne pourrai qu'empirer le résultat... le low pixel art c'est un boulot encore plus chaud que l'asm sur un hard du jurassic comme la 2600 je trouve

oui je pourais c'est pas tres compliqué a expliquer je pense, la complication c'est toujours de le faire avec le moins de ressource possible (et d'avoir l'idée)


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

cool merci   j'attends ça avec plaisir

Pas mal l'élargissement de sprite, moi aussi je trouve que ça colle plus à l'image culte :


celui-ci est ici :

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.

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.

C'est beau ce que tu dis...

+2... vraiment intéressant.. cela me rappelle me slectures en école d'ingé

j'adore surtout etre entouré d'un bordel de feuilles papiers griffonées dans tous les sens que seul toi peu dechiffrer tellement ca ressemble a rien mais pour toi c'est plein de repère

Ce que j'aime ds ta démarche, c'est la recherche de trick, d'astuces.
De nos jours, quand tu codes, tu passes surtout ton temps a reprendre le taff d'un autre, ou a copier coller sur le net, a lire des procédures... etc... (pour ca que je continue a avoir une activité graph, + un peu management, sinon, je me ferais trop chier).
Quand j'ai commencé, au début du net, coder pour le net, c'était un peu pareil, t'étais avec ta bite et ton couteau, et tu testais, tu créais des trucs sans savoir vraiment si ca allait marcher, pas assez de recul, pas bcps de bouquins, juste des types qui trippaient.
C'était pas très technique, mais c'était marrant, ca demandais de l'astuce.
Maintenant, ca demande d'ouvrir un bouquin et de faire pareil. Je crois que c'est tjs comme ca quand on est au début d'une rupture (techno ou autre), et puis apres ca se normalise, ca s'organise, ca se simplifie tout en se complexifiant d'une façon parfois contre productive. (vieux con inside).
Au final, ce qui reste fun, c'est de pouvoir creer un truc de A a Z, et c'est aussi pour ca que les indies émergent maintenant. Outre l'aspect tech de l'emergence (logiciels, steam, free to play, facebook etc...), y'a un aspect humain, qui est je pense, que quand on taff ds l'industrie du "gros" jeu, on se farcit des tonnes de contraintes pour faire un tout petit bout d'un jeu sur lequel on a peu de liberté. C'est comme taffer en usine au final, visser des putains de boulons de merde, mais en s'epuisant mentalement au lieu de physiquement. Alors si on a ou si on peut se creer le moyen de revenir sur plus simple et libre, ou son travail compte vraiment, on y va. Ne serais ce que pour recharger psyché ^^.
Je comprends en fait que malgré tes capacités (que je trouve étonnantes), tu continues tranquille ds la poste, et t'amuses à côté.

c'est un peu pour cela que quand j'ai commencé à bosser, je préférais me taper du C/C++ avec des routines ASM optimisées pour les DSP car là il y avait du travail de recherche


Manu, en tout cas, ta dernière phrase est on ne peut plus juste...

manulelutin a écrit:

Ce que j'aime ds ta démarche, c'est la recherche de trick, d'astuces.
De nos jours, quand tu codes, tu passes surtout ton temps a reprendre le taff d'un autre, ou a copier coller sur le net, a lire des procédures... etc... (pour ca que je continue a avoir une activité graph, + un peu management, sinon, je me ferais trop chier).
Quand j'ai commencé, au début du net, coder pour le net, c'était un peu pareil, t'étais avec ta bite et ton couteau, et tu testais, tu créais des trucs sans savoir vraiment si ca allait marcher, pas assez de recul, pas bcps de bouquins, juste des types qui trippaient.
C'était pas très technique, mais c'était marrant, ca demandais de l'astuce.
Maintenant, ca demande d'ouvrir un bouquin et de faire pareil. Je crois que c'est tjs comme ca quand on est au début d'une rupture (techno ou autre), et puis apres ca se normalise, ca s'organise, ca se simplifie tout en se complexifiant d'une façon parfois contre productive. (vieux con inside).
Au final, ce qui reste fun, c'est de pouvoir creer un truc de A a Z, et c'est aussi pour ca que les indies émergent maintenant. Outre l'aspect tech de l'emergence (logiciels, steam, free to play, facebook etc...), y'a un aspect humain, qui est je pense, que quand on taff ds l'industrie du "gros" jeu, on se farcit des tonnes de contraintes pour faire un tout petit bout d'un jeu sur lequel on a peu de liberté. C'est comme taffer en usine au final, visser des putains de boulons de merde, mais en s'epuisant mentalement au lieu de physiquement. Alors si on a ou si on peut se creer le moyen de revenir sur plus simple et libre, ou son travail compte vraiment, on y va. Ne serais ce que pour recharger psyché ^^.
Je comprends en fait que malgré tes capacités (que je trouve étonnantes), tu continues tranquille ds la poste, et t'amuses à côté.

C'est clair que maintenant c'est forum, bouquin. Il y a très peu d'endroits(start up) où il y a des trucs innovants...

A part chez ceux qui ne font pas de multi et pousse le C/C++ et ASM jusqu'au bout comme Naughty Dog, cela doit être différent de cela...

En France dans le projet classique c'est horrible. Dans beaucoup de domaine, c'est encore des cycles en V... Alors comment se passe la mise en production? Pas trop de retour de bug mais le client ne comprend rien à l'application. Agilité, tu lui fait un logiciel, appli web professionnel qui répond à son besoin, pas une usine à gaz.

Le rôle de UX designer n'existe pas dans les projets classique.