Re: Mr ToutLeMonde et la programmation NES...

par vincent2105 Sam 28 Jan 2017 - 12:02

Merci pour ton soutien upsilandre Wink

Bon, ça y'est, j'ai ma routine de détection d'attribut en fonction de la position du joueur dans la nametable de la worldmap. Pour l'instant, je ne traite que la palette (le bleu devient gris foncé, du coup la mer devient montagne), mais par la suite je bankswitcherai la bank chr rom pour avoir des tiles plus adéquates (je suis parti avec 4 banks d'1 ko pour le background et 2 banks 2ko pour les sprites).

Comme dit précédemment, je vais pouvoir donner 4 skins différentes à mes nametables, du coup mes 16 paysages cotiers vont donner l'illusion d'avoir 64 nametables différentes. Ca me permet en outre d'avoir des briques bien organisées pour créér des maps.

par vincent2105 Sam 28 Jan 2017 - 17:03

Prochain casse-tête, l'embarcation et tout ce que cela implique... La, ça va m'occuper un moment, mais ça va être un gros plus à mes yeux. Je vais faire en sorte qu'on puisse accoster partout (sauf sur les recifs), si j'y arrive je déploierai la carte d'une taille de 32x30 actuellement à 89x89 (maximum autorisé par mes routines).

par vincent2105 Sam 28 Jan 2017 - 23:25

Aie, cette fois, c'est la panne.

Va falloir que je potasse sérieusement cette page : https://wiki.nesdev.com/w/index.php/The_frame_and_NMIs . J'ai bien peur d'en demander trop à notre bonne vieille nes... j'espère me tromper et trouver une solution.

Quelque soit la série d'instruction que j'écrive, je me retrouve à modifier les palettes de couleur :/ (grosso modo 3 instructions sur des variables bidons ca passe, si j'en rajoute une, ça déconne).

par upsilandre Dim 29 Jan 2017 - 12:50

J'ai pas bien compris ton probleme (un probleme pour faire tenir ta routine NMI dans le Vblank?) mais n'hesite pas a mettre une ROM avec le bug, je pourrais toujours regarder, moi ca m'amuse.

par vincent2105 Dim 29 Jan 2017 - 14:23

J'ai pas bien compris ton probleme (un probleme pour faire tenir ta routine NMI dans le Vblank?)

Oui, je pense que c'est ça.
Mais te prends pas trop la tête dessus, j'ai vraiment un tas de trucs à comprendre sur le wiki que j'ai mentionné plus haut. Et pas dit non plus que je le continue bien longtemps, il m'arrive souvent de faire table rase pour partir sur autre chose.

Tiens voila les ROMs :
MAP OK
MAP PROBLEME (suite ajout sprite radeau)

par upsilandre Dim 29 Jan 2017 - 16:27

J'ai regardé. Deja y a un gros probleme avec ta pile qui part totalement en cacahuete dès le debut et qui du coup envoie le CPU au pif executer du code dans la RAM (heureusement ca tombe sur des valeurs nulle donc ca donne une boucle d'interruption break qui tourne sur elle meme a l'infini jusqu'a ce que l'interruption NMI vienne relancer ta boucle de programme, du coup c'est a peu pret transparent mais seulement parce que tu utilises pas le premier octet de RAM sinon ca planterait completement dès le debut)
En virant ton bout de code de sauvegarde des registres en debut de NMI (PHA, TXA, PHA, TYA, PHA) ca regle le probleme. Quand tu utilises des instructions qui vont mettre des truc dans la pile (PHA) faut faire ultra gaffe car si tu retire pas ce que t'as mis ca va faire ensuite tout planter car c'est la que sont stocker les adresses de retour de tout tes subroutine et des interruptions et t'utilise beaucoup de subroutine.
J'ai pas trouvé a quelle endroit tu "pop" ce que t'as "push" dans ta pile ce qui explique le plantage. Normalement juste avant le RTI de l'interuption NMI du doit pop (avec PLA) ce que t'as PHA (PLA, TAY, PLA, TAX, PLA). Je pense que t'as oublié de le mettre mais de toute facon c'est pas la cause de ton probleme actuel.

Pour ce qui est de la palette effectivement j'ai regardé et tu modifie la palette a la limite de la fin du Vblank du coup parfois t'es hors du Vblank (ca se joue a quelques cycles donc effectivement suffit que t'ajoute une instruction ailleurs qui te semble n'avoir aucun lien pour que le bug arrive quand meme) donc ca foire car le PPU va utiliser aussi le registre d'adressage en meme temps que toi.
Ce qui est bisarre c'est que a chaque changement d'ecran tu fais 2 appels a t'as subroutine qui charge la palette. Un premier appel suffisamment tot dans ta routine NMI et qui donc passe tres bien puis t'en fais un second (au milieu d'un groupe de 6 ou 7 JSR qui d'ailleurs est copier/coller plusieurs fois dans ton code) qui fait la meme chose mais qui le fait trop tard (du coup c'est la que ca fou la merde). J'ai enlevé ce second appels (et ses copies) juste pour tester et effectivement le bug disparait. Si tu veux faire des changements de palette faut tout inclure dans ton premier (et alors unique) appels a ta subroutine de chargement de palette.
Et plus globalement faut vraiment optimisé tout ce qui est sensible (acces a la VRAM, Palette et Sprite ram) dans ta routine NMI et que tout ca soit bien placé en priorité au debut car le Vblank ca dure vraiment pas longtemps (beaucoup moins que sur Master System).

par vincent2105 Dim 29 Jan 2017 - 16:44

Whaou !! merci upsilandre pour ton analyse ! Je vais tacher d'en tirer parti. Pas grand chose à rajouter, sinon un grand MERCI Very Happy

par vincent2105 Dim 29 Jan 2017 - 17:00

Si une question :

J'ai enlevé ce second appels (et ses copies) juste pour tester et effectivement le bug disparait. Si tu veux faire des changements de palette faut tout inclure dans ton premier (et alors unique) appels a ta subroutine de chargement de palette.

Est ce que les "montagnes" apparaissent en noir lorsqu'on est en jeu ? (donc pas en train de regarder la worldmap). Je doute. Confused

Par exemple, aux adresses et avec les valeurs suivantes, tu devrais avoir une zone montagneuse et pas la mer :
$6000 : #9 (position X)
$6001 : #4 (position Y)
C'est bien le cas ?

par upsilandre Dim 29 Jan 2017 - 17:14

Non les montagnes n'ont pas la bonne couleur. C'est certain que tu vas pas regler le probleme juste en enlevant ce que j'ai retiré (c'etait juste pour situer le bug) car j'imagine bien que les autres appels a ta subroutine ont une fonction.
Va falloir que tu trouve comment charger la bonne palette directement avec ton premier appel a ta subroutine de palette pour pouvoir virer les autres. C'est certain que tu ne doit avoir qu'un seul appel a ta subroutine de chargement de palette .

edit: j'avais meme pas vu que tu utilisais une extension de RAM. Pourquoi tu met tes 2 variables X,Y de ta map dans l'extension de RAM ($6000, $6001) plutot que dans la RAM?

par vincent2105 Dim 29 Jan 2017 - 17:50

Va falloir que tu trouve comment charger la bonne palette directement avec ton premier appel a ta subroutine de palette pour pouvoir virer les autres. C'est certain que tu ne doit avoir qu'un seul appel a ta subroutine de chargement de palette .

J'ai parcouru mon code, je ne pense pas pouvoir charger la palette aussi tôt dans le nmi que le premier appel. Par contre, je pense pouvoir le faire avant 1 routine conséquente qui me permet de trouver la bank et l'adresse à laquelle se trouve la nametable à afficher (environ 70 instructions) Je m'apercois qu'il y'a vraiment moyen d'optimiser. C'est bien, la je prends vraiment "conscience" de mon code, jusque là, je rajoutais des subroutines, tant que ça marchait, ça m'allait.

edit: j'avais meme pas vu que tu utilisais une extension de RAM. Pourquoi tu met tes 2 variables X,Y de ta map dans l'extension de RAM ($6000, $6001) plutot que dans la RAM?

J'avais l'intention d'utiliser les sauvegardes. De mémoire, ça se passait à partir de ces adresses uniquement. Je vérifierai.

par upsilandre Dim 29 Jan 2017 - 17:53

vincent2105 a écrit:J'ai parcouru mon code, je ne pense pas pouvoir charger la palette aussi tôt dans le nmi que le premier appel.

Du coup faudra alors viré ce premier appel, ca fera gagner encore des cycles

J'avais l'intention d'utiliser les sauvegardes. De mémoire, ça se passait à ces adresses uniquement. Je vérifierai.

A oui c'est vrai je me souviens tu voulais faire des sauvegardes donc ca se comprend.

par vincent2105 Dim 29 Jan 2017 - 17:59

Oui mais ce qui me tracasse, si je me trompe pas on a 2200 cycles de vblank, et la je suis déjà au bout :/
Je dois pouvoir gagner disons 150/200 cycles en déplacant l'appel de cette routine et supprimant le doublon, mais quand même... Me reste vraiment plus grand chose.
J'ai regardé un peu le wiki, apparemment ils parlent de bufferiser, mais pour l'instant, c'est flou.

par upsilandre Dim 29 Jan 2017 - 18:09

normalement oui tu prépare tout avant et au moment du NMI tu fais juste des transferes (en sachant deja de ou a ou tu deplace les data car c'est deja préparé a l'avance)

Mais de toute facon dans ton cas il devrait meme pas y avoir a se poser toutes ces questions car les seuls changement que tu fais (que soit tilemap, tileset, palettes) se font au changement entre 2 ecrans donc quand tu change d'ecran tu devrais mettre le PPU sur Off et a ce moment la t'as tout le temps que tu veux pour faire ce que tu a a faire , y a plus de Vblank, et donc aucun probleme. Et une fois que t'as terminé tu remet sur ON le PPU.
D'ailleurs j'ai vu que t'avais aussi une routine qui test le flag du Vblank dans le registre 2002 pour attendre le Vblank, j'ai pas bien compris pourquoi tu l'utilise (a part au reset) et tu semble l'utiliser souvent pour attendre le Vblank alors que lorsque t'es en phase d'affichage y a l'interuption NMI qui sert deja a ca et quand t'es hors affichage (PPU off) t'as plus besoin d'attendre le Vblank.

La seule routine sensible dans ton ca et qui devrait etre en debut de NMI c'est la routine de chargement de la liste de sprite (car les sprite bouge tout le temps) mais le reste devrait etre fais le PPU OFF pendant la transition entre 2 ecran et donc sans contrainte. T'as la chance justement d'etre dans un contexte assez simple car tres statique (pas de scrolling) faut en profiter. Peut etre que ton probleme c'est juste que tu rallume le PPU trop tot avant d'avoir finit.

par vincent2105 Dim 29 Jan 2017 - 18:27

Je pense que t'as raison sur toute la ligne.
J'ai bêtement copié / collé mes routines de chargement de palette et background (ce que je fais pour tous mes projets) sans vraiment savoir ce qu'il se passe au niveau des registres. effectivement, chacune lit $2002. Pour le reste je regarderai

Sinon, je lance le DMA (sprites) au tout début du nmi, donc ça c'est bon.

J'ai un sacré nettoyage à faire, mais comme tu le dis ça doit fonctionner, car tout peut ce faire ppu off. Allez, y'a de l'espoir

par upsilandre Dim 29 Jan 2017 - 18:35

Oui normalement ca devrait etre simple. Dans ton nmi devrait juste y avoir le chargement des sprites qui est la seul priorité dans ton cas et juste apres tranquillement tu test un flag en RAM qui te sert d'indicateur pour savoir si t'es entrer dans une transition d'ecran et si c'est le cas alors tu lance ton code alternatif qui commence par mettre le PPU (et le NMI) sur OFF et va calculer/charger tout ce qui est tilemap, tileset et palette avec le temps que tu veux pour finir par rallumer le PPU et le NMI a la fin

Mais c'est certain qu'il y a du gros nettoyage a faire, c'est un peu le bordel Razz

par vincent2105 Dim 29 Jan 2017 - 20:47

Oui je reconnais Mr. Green

mais pas ce soir, je suis naze $I don\'t want that$ , je risquerais d'aggraver la situation...

par vincent2105 Dim 29 Jan 2017 - 22:08

Finalement, j'ai déplacé ma routine de chargement de palette comme je l'avais dit tout à l'heure et j'ai rajouté "pla, txa, pla, tya, pla" en fin de NMI. (et j'ai viré l'appel en doublon de la subroutine)
Maintenant ça fonctionne.
Néanmoins, je peux pas être satisfait maintenant que tu m'as fait ouvrir les yeux sur le reste. Y'a encore du pain sur la planche...

par vincent2105 Lun 30 Jan 2017 - 9:43

Deja y a un gros probleme avec ta pile qui part totalement en cacahuete dès le debut et qui du coup envoie le CPU au pif executer du code dans la RAM (heureusement ca tombe sur des valeurs nulle donc ca donne une boucle d'interruption break qui tourne sur elle meme a l'infini jusqu'a ce que l'interruption NMI vienne relancer ta boucle de programme, du coup c'est a peu pret transparent mais seulement parce que tu utilises pas le premier octet de RAM sinon ca planterait completement dès le debut)

Bon, j'ai pas fini de me taper la honte, mais si j'ai bien compris, c'est la structure du code (que je suis depuis le début dans les tutos) qui serait à remettre en cause.

tutoriel
cette partie là en particulier :

Game Layout

The Pong game engine will use the typical simple NES game layout. First all the initialization is done. This includes clearing out RAM, setting up the PPU, and loading in the title screen graphics. Then it enters an infinite loop, waiting for the NMI to happen. When the NMI hits the PPU is ready to accept all graphics updates. There is a short time to do these so code like sprite DMA is done first. When all graphics are done the actual game engine starts. The controllers are read, then game processing is done. The sprite position is updated in RAM, but does not get updated until the next NMI. Once the game engine has finished it goes back to the infinite loop.

Init Code -> Infinite Loop -> NMI -> Graphics Updates -> Read Buttons -> Game Engine --\

Le code de l'exemple : pong_zip

Grosso modo, ils préconisent

- reset
- boucle forever (vide)
- routine NMI
et c'est tout !
Autrement dit, tout est dans la routine NMI, en mettant la partie "logique" après la partie "affichage".

J'imagine que le RTI est simplement ignoré si on dépasse la durée du vblank, et que le reste est traité normalement.

Maintenant qu'on en parle, j'aimerais faire ça comme il faut.

par upsilandre Lun 30 Jan 2017 - 10:20

Je fais un petit rappel quand meme, l'homme le plus expérimenté sur NES ici c'est toi Cool

moi je suis arrivé apres et j'ai toujours pas fais grand chose donc imagine pas que je suis le spécialiste (c'est d'ailleurs curieux que sur Gamopat on ait pas de spécialiste NES, quand on pense Atari2600, Coleco, SMS, Megadrive, PCE, Amstrad, Atari, Amiga... on a des noms de spécialiste Gamopat qui nous viennent meme pour moi qui suis la depuis pas longtemps, mais sur la NES, console pourtant culte, on est livré a nous meme What a Face

peut etre parce que elle est trop culte justement et qu'ils sont tous sur les sites anglophones, reste plus que les 2 pécores allergique a l'anglais)

Mais de ce que j'ai pu voir y a pas de structure type, chacun a sa methode. Certain effectivement mettent tout dans la routine NMI qui sert donc juste a donner le top signal de syncho pour demarrer les taches prioritaires et faire le reste a la suite (dans ce cas pas besoin de PHA, PLA. Mais faut etre sure d'etre dans la frame, faut pas deborder sinon ca risque de planter car le RTI doit etre absolument executer a chaque frame pour que la pile soit correctement géré). D'autre utilisent la routine NMI juste pour activer un flag ou incrementer un compteur de frame et en sorte aussitot. Et d'autre font des truc intermediaire.

En fait dès que tu veut prendre en consideration la possibilité que ton jeu puisse avoir des chutes de framerate (et si on fait un code propre c'est ce qu'on devrait faire) c'est la que les questions se pose vraiment et qu'il y a des choix a faire sur ce qu'on place ou pas dans le NMI car dans ce cas ce n'est plus la meme chose d'etre ou pas dans le NMI (par exempel la question des inputs, ou d'un compteur de frame qui te sert a timer tes animations, faut savoir quelle comportement on veut quand le framerate baisse).
Mais a partir du moment ou on fait un jeu "dans la frame" alors y a moins de question a se poser.

par Ned_Flanders Lun 30 Jan 2017 - 10:26

Peut-être que vous parlez pas anglais mais il n'empêche que je ne comprends pas un broc de ce que vous parlez ! Alors j'imagine même pas en anglais ! Mr. Green

par upsilandre Lun 30 Jan 2017 - 10:38

C'est pour ca que des fois je met des Gifs, je pense a tous les types de lecteur Mr. Green

par Ned_Flanders Lun 30 Jan 2017 - 10:58

Le problème c'est que le nombre de gif n'est pas proportionnel à la complexité de vos propos ! Mr. Green

Même si c'est super appréciable ! Bonne continuation Wink

Je continuerai à cliqué pensant être moi aussi un Mr. Toutlemonde :)

par vincent2105 Lun 30 Jan 2017 - 11:46

Je fais un petit rappel quand meme, l'homme le plus expérimenté sur NES ici c'est toi Cool moi je suis arrivé apres et j'ai toujours pas fais grand chose donc imagine pas que je suis le spécialiste (c'est d'ailleurs curieux que sur Gamopat on ait pas de spécialiste NES, quand on pense Atari2600, Coleco, SMS, Megadrive, PCE, Amstrad, Atari, Amiga... on a des noms de spécialiste Gamopat qui nous viennent meme pour moi qui suis la depuis pas longtemps, mais sur la NES, console pourtant culte, on est livré a nous meme What a Face peut etre parce que elle est trop culte justement et qu'ils sont tous sur les sites anglophones, reste plus que les 2 pécores allergique a l'anglais)

Bah j'estime que tu es beaucoup plus calé que moi, et c'est vrai que je me suis lancé la dedans y'a 2 ans 1/2 mais par intermittence, j'y ai pas touché pendant quasiment un an, la j'ai repris depuis 15 jours après une grosse pause de 3 mois je pense. Mais je programme pas dans de bonnes conditions, je suis buraliste, donc je programme ou j'écris des posts entre 2 clients (là ça fait 45 minutes que j'écris ces 4 lignes :p ) ou le soir après 11 de boulot $I don\'t want that$ ... Mais la je suis motivé, faut battre le fer tant qu'il est chaud
Bref j'ai des tas de trucs à apprendre de toi (j'ai été bluffé par ton debuggage, j'ai jamais utilisé fceux a cette fin, je sais pas comment procéder)

Ned_Flanders a écrit:Le problème c'est que le nombre de gif n'est pas proportionnel à la complexité de vos propos ! Mr. Green

Même si c'est super appréciable ! Bonne continuation Wink

Je continuerai à cliqué pensant être moi aussi un Mr. Toutlemonde :)

Merci Ned_ ça fait plaisir de voir que le sujet intéresse :)

par upsilandre Lun 30 Jan 2017 - 13:09

Sur la théorie ca va je suis calé, je commence a vraiment bien connaitre la machine.

par Ned_Flanders Lun 30 Jan 2017 - 16:12

vincent2105 a écrit:
Ned_Flanders a écrit:Le problème c'est que le nombre de gif n'est pas proportionnel à la complexité de vos propos ! Mr. Green

Même si c'est super appréciable ! Bonne continuation Wink

Je continuerai à cliqué pensant être moi aussi un Mr. Toutlemonde :)

Merci Ned_ ça fait plaisir de voir que le sujet intéresse :)

Disons que j'ai toujours effleuré le rêve de programmer un jeu vidéo (étant gosse) et les étude et la "vie" on fait que je n'ai jamais pu réaliser cela.

Et maintenant étant bien accros à la NES ce serai un aboutissement de pouvoir sortir un homebrew sur cette belle machine...mais j'y connais absolument rien et plus je regarde vos post plus ça me démoralise ! Mr ToutLeMonde et la programmation NES... - Page 25 435303

Mr ToutLeMonde et la programmation NES... - Page 25 435303

Alors je vais continuer à regarder vos posts (et vos gif) comme un Français regarde un manga écrit en Japonnais ne s'attardant que sur les dessin ! Mr. Green

par upsilandre Lun 30 Jan 2017 - 16:26

C'est certain qu'il faut commencer par le commencement sinon tu peux pas capter (Je rappel que le topic date de 2014, je précise parce que moi je l'ai découvert récemment) mais si je ne m'abuse Vincent jusque pas si longtemps ne s'etait jamais intéressé du tout a la programmation, il a commencé direct par la programmation assembleur sur NES et n'a pas beaucoup de temps a y consacrer et moi mon profile c'est vraiment pas la folie:
- j'ai arreté les etudes tres tot au lycée, aucun diplome.
- j'ai aucune formation de programmeur et tres peu d'experience en amateur (en cumulé sur tout ma vie je dois avoir 3 ou 4 mois d'experimentation en autodidacte , je programme quelques semaines tous les 5 ans environ quand vraiment j'ai une pulsion et en recommencant a zero a chaque fois, mais cette fois j'essai de faire des petits truc régulierement pour entretenir, j'espere continuer comme j'ai terminé 2016)
- Je suis manutentionnaire a la Poste, je deplace des bacs de courrier donc c'est pas mon parcoure professionnel qui m'aide non plus
- je suis une bille total en anglais donc je galère un peu pour m'informer (surtout pour partager) vu que le sujet est 99.999% anglophone.

Donc voila je pense qu'on est Mr Toutlemonde sinon je vois pas qui peu l'etre. C'est vraiment juste une question de centre d'interet. Ce qui fait la difference c'est a quelle point on s'intéresse a un truc et donc le temps qu'on est pret a y consacrer. Moi ca m'a toujours plus ou moins intéressé meme de loin. C'est ca qui fait la difference.

par vincent2105 Lun 30 Jan 2017 - 17:22

C'est tout à fait ça !

Sinon, perso, j'ai du bidouiller 15 jours en C, autant en Python et QB64 avant ça.
C'est vraiment la passion qui a fait que je suis encore sur ce topic (et pour un moment je pense). J'ai des souvenirs très forts de moi gosse devant ma NES quand j'ai eut mes premiers jeux, je trouvais ça absolument magique ! je me collais à 10 centimètres de l'écran pour regarder les chutes d'eau dans super mario bros 2... Comme je l'ai dit à TOUKO une fois, y'a le coté nostalgie qui joue beaucoup.

Ned_Flanders a écrit:Et maintenant étant bien accros à la NES ce serai un aboutissement de pouvoir sortir un homebrew sur cette belle machine...mais j'y connais absolument rien et plus je regarde vos post plus ça me démoralise !

Le truc le plus important, c'est de mettre le pied à l'étrier au moins une fois. Après ça plait ou pas. C'est aussi simple que ça :)

par Invité Lun 30 Jan 2017 - 19:50

Le truc le plus important, c'est de mettre le pied à l'étrier au moins une fois. Après ça plait ou pas. C'est aussi simple que ça :)

je pense que bcp ici ont commencé comme ça (moi compris) .
Mais la progression est assez fulgurante passé les premiers essais .
Ce topic en est la preuve vivante Wink

par upsilandre Lun 30 Jan 2017 - 21:31

J'avais deja parlé de l'animation de pluie en color cycling 3 couleur dans Ducktales 2 qui est la plus réussit que je connaisse
Mr ToutLeMonde et la programmation NES... - Page 25 Ducktales2rain

Mr ToutLeMonde et la programmation NES... - Page 25 Ducktales2rain

Mais je me rend compte que celle des sables mouvant est aussi tres reussit pour du simple color cycling 3 couleurs.
Mr ToutLeMonde et la programmation NES... - Page 25 Duck_Tales2_Sable_M

Mr ToutLeMonde et la programmation NES... - Page 25 Duck_Tales2_Sable_M

Le color cycling c'est vraiment le truc du pauvre qui donne pas des truc terrible mais dans Ducktales c'est vraiment super bien maitrisé. Ils avaient de bon graphiste chez Capcom (ca se voit de toute facon sur tout le character design)
Les Ducktales pour moi c'est probablement les jeux les plus aboutit que je connaisse en 128ko

par Invité Lun 30 Jan 2017 - 21:40

Moi j'adore le color cycling, technique d'anim du pauvre, mais qui peut donner de supers résultats quand c'est bien fait, pour une charge CPU dérisoire .
Tes exemples le montrent d'ailleurs, l'anim rend super bien je trouve .

Mais tu es sur que sur la pluie c'est bien du color cycling ??
Je trouve bizarre que l'on voit du noir sur les tiles nuages,qui n'a aucune raison d'être pour moi avec le color cycling(a moins pour faire des économies avec des tiles sur 2 bits, et encore) .

par vincent2105 Lun 30 Jan 2017 - 21:55

@TOUKO : merci Embarassed

j'en apprends vraiment tous les jours et y'a encore à faire, c'est ce qui est intéressant.

@upsilandre : on ne se lasse pas des ducktales Wink

en regardant tes gifs de plus près on voit une sorte de clignotement sur le derrière de picsou. Tu as l'explication ?

Sinon, j'estime avoir fini le nettoyage de mon code. C'était pas si compliqué que ça, je vais pouvoir continuer.