Re: Topic Officiel Project Y - Paprium

[TotOOntHeMooN]

putain on a tous des signatures de coupon, on est tous des putes.

Sauf moi... J'ai juste une citation de pute ! 

[Invité]

oui faut que je pense à retirer, un de mes contacts UK m'a annoncé son nombre de coupons et je pense que personne ici n'a aucune chance de gagner quoi que ce soit :)

[ob1]

Bon, mes filles sont parties répéter leur pièce de théâtre, j'ai donc une petite demi-heure à vous consacrer.

En préambule, j'indique que Fonzie m'a contacté pour travailler sur l'optimisation 68000 de ce qui était à l'époque le Projet Y. Je crois que mon SuperVDP sur la 32X (je vous laisse chercher sur YouTube) lui avait bien plu. Pour situer rapidement, il s'agissait d'un moteur de tiles sur la console champignon. Tout en assembleur, synchronisation des CPU, surutilisation des 4 controleurs DMA, je tapais 4 plans à 30fps là où les meilleurs jeux commerciaux de l'époque n'en faisaient qu'un (on se calme les zealots, j'ai jamais réussi à faire le moteur 3D dont j'avais rêvé).

Alors, d'abord et avant tout, je ne parlerai encore que de ce que je sais, dans la mesure de ce que je peux. D'ailleurs, je ne parlerai même pas de Paprium ou du Projet Y, je vous dirais simplement comment j'aborderais l'optimisation à la main (en assembleur) d'un algorithme en C, si je devais le faire aujourd'hui. Certains des éléments que je partagerai ici pourront avoir été utilisés sur Paprium, certains pas, et peut-être même que j'en ai gardé quelques uns. Mon but n'est pas de vous dévoiler comment est fait Paprium (en définitive, vous vous en moquez), mais plus qu'est-ce que c'est que le job de "68000 Assembly".

Avant-propos : on va descendre bas, loin et fort. FL vous donne un harnais et c'est grâce à ce harnais qu'il vous hisse vers la connaissance, nous pouvons tous le remercier à nouveau pour ça.
Ici on va plutôt faire du saut en parachute ascendant spéléologie. Pour donner une idée.

Bon, la première des choses quand on vous donne un programme en C à optimiser, c'est de bien en comprendre l'esprit général. Et vous en percevrez l'esprit général, vous ne le comprendrez, que si ce programme est simple, ou si vous avez son concepteur à côté. Mais si le logigramme (des losanges qui enchaînent sur des ovales qui sont fléchés vers des rectangles) qui le représente tient sur 3 pages, vous savez que vous allez souffrir.

Une fois que vous avez exploré cette voie, vous pouvez fanfaronner avec les 3 notions de gcc que vous avez. En gros, l'optimisation est gérée par l'option -O qui donne des résultats divers selon le type d'optimisation que vous souhaitez. Optimisation de taille (pour mettre plus de choses dans la cartouche), optimisation d'empreinte mémoire (pour garder de la mémoire pour faire autre chose), ou optimisation de vitesse. Souvent, quand on demande de l'optimisation, c'est la vitesse qu'on cible. C'est ce dont je vais parler par la suite.

Même avec les meilleurs options, gcc n'a commencé à être vraiment bon que relativement récemment. Si je vous donne un compilateur gcc d'il y a 20 ans, si vous regardez le code généré, vous vous demanderez certaines fois si celui-ci ne l'a pas été par un poisson rouge. J'exagère ? A peine. Ainsi, à plusieurs reprises, on rencontre une variable lue, écrite en mémoire, pour être relue deux instructions plus tard. Alors, quand on a mangé un peu du compilo, on comprend pourquoi gcc fait ça. Mais la première fois, ça surprend un peu.

Si on doit optimiser à la main, la première chose à faire est donc de supprimer ces doublons : pas besoin d'écrire pour lire juste après. On inverse simplement l'instruction intermédiaire, pourvu qu'elle ne soit pas utilisée entre, et on supprime l'écriture-lecture. Et une écriture-lecture supprimée, c'est de 12 à 16 cycles économisés. 12 à 16 cycles sur une frame, ça peut sembler négligeable (une frame compte environ 128k cycles), mais si cette écriture-lecture est réalisée un nombre conséquent de fois, c'est la différence entre 60 fps TOUT LE TEMPS, et 60 fps SOUVENT. Je vous renvoie à mon précédent message sur le degré d'exigence de certains projets ...

Ensuite, à nouveau pour qui veut optimiser du code à la main, il doit y avoir la connaissance intime de la cible. Par intime, j'entends vraiment intime. Tout gamopat que nous sommes, nous avons - presque - tous une copine, certains une femme ... Ah ouais, j'ai pas vu beaucoup de nénettes chez les gamopats. Enfin, toujours est-il que je parle de cette intimité-là. Tu sais TOUT d'elle. Ouais, ça aussi.
TOUT, pour ton CPU, ça veut dire que tu connais ses instructions, tu connais les temps de ces instructions, tu connais les registres, tu connais les calling conventions, tu connais la cache, tu connais ... tu connais tout. Et parce que tu connais tout, tu peux donner des astuces au compilo (à l'assembleur en fait). Par exemple, il peut être intéressant de remplacer une boucle for en C par une do while, parce qu'une certaine instruction du CPU s'y prêtera mieux. Et là, c'est encore 2 à 4 cycles gagnés. Et toujours pareil, 2 à 4 cycles, c'est pas beaucoup, mais quand tu gagnes 2 à 4 cycles sur une boucle dans une boucle, franchement, tu es vite à quelque chose de mesurable, donc plus négligeable. Mais, si tu veux optimiser, connais ta cible. Tu passes à côté de tous ce que les dev hardware ont fait pour toi en ne faisant pas cet effort, ingrat !
Je prolonge ce point. Certaines fois, tu peux faire une action de deux manières différentes. Et quand tu regardes la doc et tout, chacune de ces manières te donne le même chrono. Alors pourquoi t'embêter à choisir ? Tu prends de manière arbitraire et c'est marre, hein ? Sauf que si tu vas un peu plus loin, tu vas t'apercevoir qu'une instruction s'écrit en 2 octets, alors que l'autre en prend 3. Et même si elles prennent autant de temps, mettons 10 cycles, lire la première te prendra 1 cycle supplémentaire sur une machine 16 bits, alors que lire la seconde te prendra 2 cycles supplémentaires. Et là aussi, tu peux dire que c'est jamais qu'un cycle d'écart, mais d'une part, si tu mets ça dans une boucle d'une boucle ... OK, c'est bon, t'as compris, et d'autre part, ça dépend de ton degré d'exigence. Bon, ou TRES bon.

Et là, déjà, on est pas mal.
Mais si vraiment tu veux aller plus loin, il faut te plonger dans les maths. Par exemple, les tests prennent plus ou moins de temps selon que le branchement est pris (le "else" d'un test "if") ou pas (le "then" d'un test "if"). Je n'invente rien, prends le guide d'utilisateur de n'importe quel processeur, et tu verras que c'est marqué noir sur blanc. Alors ce que tu peux faire, c'est faire une étude, et incrémenter des variables et faire tourner ton appli et regarder à la fin à combien et ton compteur de branchements pris, et de branchements non-pris. Et si tu as bien plus de branchements pris que de branchements non-pris, et que ce sont les branchements pris qui sont plus longs, ça peut valoir le coup d'inverser ton test. Ca, c'est pour vraiment aller chercher les derniers %.

Mais, et j'aurais dû commencer par ça, clairement, le plus, plus, plus important, le plus gros gain de perfs, qui est lié à la connaissance intime de ton processeur, ce sont les registres. Les registres, certains appellent ça de la mémoire, moi je dis que ce sont simplement les cases avec lequel le processeur travaille directement. Les registres, c'est les deux rectangles fondamentaux quand tu veux représenter un CPU qui fait une addition. Les registres, c'est la base de la base, l'accès direct, gratuit et immédiat. C'est la nano-seconde contre la milli-seconde. C'est la seconde contre 6 minutes. Et très souvent, parce que le compilateur n'est pas assez malin, il va pas s'embêter. Une variable à stocker, je la mets en mémoire. Un calcul à faire pour dans deux instructions ? Je mets en mémoire. Alors oui, la mémoire ça va vite et il y en a beaucoup (comparé aux registres). Mais quand tu veux aller très vite, ce n'est pas suffisant.
NOT GOOD ENOUGH !!!
Certains CPU sont plus ou moins bien lotis. Pour le SH2 de la 32X, c'est très bon. Pour le 68000 de la MD, c'est respectable. La SNES, c'est tendu. Si tu veux pleurer, regarde la Gameboy. Mais, certaines fois, moins maintenant, mais certaines fois quand même, le compilateur n'est pas très malin. Il croit que la retenue d'une addition, c'est quelque chose que tu veux garder tout le temps du programme. Il croit que c'est une bonne idée de stocker une donnée dans un registre d'adresse. Il croit que c'est une bonne idée de laisser un registre affectable parce que tu comprends, peut-être on va s'en servir pour debugger.
Foutaises.
A nouveau, les gars du hardware ont fait leur taf, c'est pas pour qu'on massacre tout à grands renforts de cycles.
Alors, je sais ce que tu vas me dire. D'une, les compilos ont fait de gros progrès. Et c'est vrai que les compilos ont fait de gros progrès. Mais certaines fois, tu n'as pas le choix. De deux, parce que tu as suivi les discussions de fin de cours d'avec ton prof de C, tu sais qu'il existe un mot-clé "register" qui permet, directement depuis C, de mettre une variable dans un registre. Sauf que dans la pratique, c'est une indication que tu fais au compilateur, qu'il pourra appliquer ... OU PAS !!!
Dans la pratique, quand on vient te voir pour optimiser les trucs, et surtout pour optimiser la vitesse, tu veux TOUTE la puissance disponible. TOUTE. Jusqu'au dernier cycle.
Connais ta cible.

En définitive, je dirais que le gain qu'on peut escompter est de 30% d'un compilo un peu ancien. Et que les registres, c'est 60% de ton optimisation, l'étude du code gcc, c'est 30%.
Je ne parle pas d'un projet particulier, je parle juste d'un mec normal suffisamment motivé pour se jeter dans cette folie. Parce que folie crois-moi que c'est. Si tu bosses un peu dans l'info de gestion, tu connais plein de trucs comme la saisie prédictive, les debug, les printStackTrace, les JUnit et les bêtises comme ça.
Là, mon pote, t'as que dalle. Ta bite, ton couteau, un bloc-notes et une fenêtre DOS. Et si tu t'es planté, t'as intérêt à avoir utilisé un Notepad++ à retour arrières multiples, ou une espèce de GCL, quitte à te la faire à la main.
Vraiment, ne fais pas d'optimisation pour te marrer. C'est UN PEU marrant, je l'aurais pas fait sinon, mais c'est surtout un travail très sérieux, et assez austère.
A nouveau, le résultat, si tu l'obtiens, est plaisant.
Mais le reste, tout le reste, c'est des heures et des heures devant ton écran. Des tests, essais, erreurs, et pour UNE version qui marche, et il n'y en a qu'une seule, tu vas faire des CENTAINES de versions qui ne vont pas marcher. Des centaines mon pote. No kiddin'.

Voilà. J'espère que ce post vous aura permis d'en apprendre un peu plus sur la fonction d'optimiseur ASM. Si vous voulez plus d'infos sur le sujet (et donc, plus du tout sur Paprium, et désolé si, partant, je fais un HS), je suis tout-à-fait motivé pour en discuter. Mais on en a déjà pas mal parlé sur un autre forum retro, et croyez-moi quand je vous dis qu'il y a des mecs bien plus gradés que moi sur ce forum pour parler de ça ;) (je vous ai reconnus, les barbus).

Au plaisir les gamopats.
La bise,
o

[Invité]

" Mon but n'est pas de vous dévoiler comment est fait Paprium (en définitive, vous vous en moquez)"


oh que non ... ici t'as 4 techos qui se foutent de l'esthétique des jeux, qui zooment les captures à 6400% pour savoir le niveau de scaling d'une image, et qui ne parlent que de tiles et de vram quand ils parlent d'un jeu ... t'es au contraire bien tombé ici pour parler de choses dont les vrais joueurs incultes en ont rien à battre :)

[Clarence 051]

oh que non ... ici t'as 4 techos qui se foutent de l'esthétique des jeux, qui zooment les captures à 6400% pour savoir le niveau de scaling d'une image, et qui ne parlent que de tiles et de vram quand ils parlent d'un jeu ... t'es au contraire bien tombé ici pour parler de choses dont les vrais joueurs incultes en ont rien à battre :)

plié de rire, c'est tellement vrai. ^^  

@Ob1

J'ai juste une petite question, je suis pas de la partie, moi c'est plutôt dessin et peinture à l'ancienne, je ne comprend pas grand chose... bref tu a fait quoi comme étude pour connaitre autant de chose qui me semble aussi obscure ??

[ace76]

Putain ,Stef,touko,upsilandre,totoonthemoon et autres fanatiques du code vont pas tarder a se pointer....

[iceberg_slim]

Ça a l'air tellement austère comme tu dis @ob1. Chapeau à vous autres codeurs de vous embarquer là-dedans... 

[tbp]

[ob1]

@Ob1

J'ai juste une petite question, je suis pas de la partie, moi c'est plutôt dessin et peinture à l'ancienne, je ne comprend pas grand chose... bref tu a fait quoi comme étude pour connaitre autant de chose qui me semble aussi obscure ??

DEUG MIAS (Math Infos Application aux Sciences)
Maîtrise MIAGe (Méthodes Informatiques Appliqués à la Gestion)
DESS Commerce électronique.

Mais dans la pratique, tous ces trucs, c'est juste de la passion.
L'essentiel des compétences nécessaires, je l'ai eu en DEUG.
La passion, hors celle des jeux vidéos, je l'ai attrapée réellement avec le numéro 00 de Retro Game (Game Museum) qui était très prolixe sur l'achitecture de la MD. C'était en 2005, je ne me suis jamais guéri ^^

[ob1]

Putain ,Stef,touko,upsilandre,totoonthemoon et autres fanatiques du code vont pas tarder a se pointer....

Voilà, alors autant je ne connais pas directement touko et upsilandre (je les ai pas vus sur spritesmind), autant j'ai déjà eu le loisir - et l'honneur - de dire à Stef et Toto tout le respect et l'admiration que j'avais pour leur travail.

Edit : typo

[ob1]

" Mon but n'est pas de vous dévoiler comment est fait Paprium (en définitive, vous vous en moquez)"


oh que non ... ici t'as 4 techos qui se foutent de l'esthétique des jeux, qui zooment les captures à 6400% pour savoir le niveau de scaling d'une image, et qui ne parlent que de tiles et de vram quand ils parlent d'un jeu ... t'es au contraire bien tombé ici pour parler de choses dont les vrais joueurs incultes en ont rien à battre :)

:)) Et j'en suis heureux. J'aime sur ce site le fait qu'on rencontre des joueurs passionnés et des développeurs autant passionnés. Et parfois, ce sont les mêmes :))

Bien évidemment, je n'irai pas au-delà du NDA ;)

[Seb25]

Merci pour le boulot que vous avez fait sur Projet Y, j'en profite pour demander : savez vous jusqu'à quelle date peut on précommander le jeu et s'il sera trouvable après sa sortie officielle en septembre sur la boutique de Watermelon ?
Est ce qu'il faut s'attendre à ce qu'il soit en rupture à sa sortie ? car ça m'embêterait de devoir attendre une version reprint parceque je n'ai pas préco.

[Master-of-Magick]

C'est Juste Magnifique ! perso j'adore le choix des couleurs. je vais ressortir ma Megadrive pour ce jeu ! L'arcade à domicile   enfin !

[tbp]

Bien évidemment, je n'irai pas au-delà du NDA

Oui tout comme Stef hélas ... ^^

Donc on ne saura pas combien d'ennemis vous avez réussi à faire afficher de façon fluide simultanément,
Ni si les SFX et les voix sont d'une qualité jamais entendue sur Megadrive (voire sur SNES ou Neo Geo). Dur !

Dites-nous au moins si vous avez réussi à battre techniquement parlant Final Fight CD... SVP

[ob1]

Bien évidemment, je n'irai pas au-delà du NDA ;)

Oui tout comme Stef hélas ... ^^

Donc on ne saura pas combien d'ennemis vous avez réussi à faire afficher de façon fluide simultanément,
Ni si les SFX et les voix sont d'une qualité jamais entendue sur Megadrive (voire sur SNES ou Neo Geo). Dur ! :monstre:

Dites-nous au moins si vous avez réussi à battre techniquement parlant Final Fight CD... SVP ;)

Ah je peux comprendre une certaine frustration et j'en suis désolé. Mon but n'était évidemment pas celui-ci.

De mon côté, je comprends, et je respecte le NDA. Il y a tellement de temps, d'espoir, d'énergie qui sont investis ici, c'est normal de vouloir protéger tout ça.

Par rapport à Final Fight CD, je ne peux pas me prononcer : je n'ai jamais eu Final Fight CD et je n'ai pas eu Paprium en version finale pour comparer.
Qui plus est, je n'ai travaillé que sur une partie hyper spécifique.
Je dirais simplement qu'en ce qui me concerne, j'ai donné 1.9ms / frame supplémentaire à Fonzie.
Et je suis convaincu qu'il l'aura utilisé à bon escient ^^

Edit : calculs refaits, je serais plus proche de 1.9ms / frame #SoyonsPrécis

[Invité]

Je dirais simplement qu'en ce qui me concerne, j'ai donné 2.4ms / frame supplémentaire à Fonzie.

Et ça, c'est très très cool.

[Invité]

Toujours génial d'avoir des passionnés comme toi par ici !!
Et merci pour tes témoignages riches d'instructions.

[Supasaya]

J'avoue !
Je comprends 1/10 de ce que tu expliques mais c'est passionant a lire

[Orion_]

mouais, n'importe quel codeur de demo sur atari st connais ça par coeur et va même 10x plus loin :)
déroulage de boucle, code généré, movem à gogo

je me suis fait un petit kiff, j'ai utilisé le prefetch du 68k dans mon dernier jeu MD pour la protection anti copie =)

[TotOOntHeMooN]

mouais, n'importe quel codeur de demo sur atari st connais ça par coeur et va même 10x plus loin :)

Je site: "Certains des éléments que je partagerai ici pourront avoir été utilisés sur Paprium, certains pas, et peut-être même que j'en ai gardé quelques uns."
Son explication de 70 lignes reste compréhensible... Toi, en 3 lignes t'as perdu "tout le monde" sans rien expliquer, juste pour te la racler. 
Comme il le dit, il y a plus balaise que lui. Juste qu'il explique son rôle dans le projet, le travail et l'exigence que ça a représenté.

[Tryphon]

Paprium, ça serait donc du C à la base, petit à petit traduit en ASM ? J'aurais pensé que vous auriez directement démarré en ASM, comme à l'époque. C'était quoi comme lib et compilo ? Le SGDK de Stef avec son GCC antédiluvien ? Ou vous avez changé de version ?

Merci pour ce post bien sympa.

[ichigobankai]

il y'a d'autres compilo en C sur MD, XGCC et SGCC.

A mon avis - partagé par quelques personnes dont mon pote Vingazole - le plus efficace en terme de temps de dev étant tres certainement de coder en C (pour la rapidité/simplicité d'écriture) puis de convertir petit à petit les routines les plus gourmandes en ASM.

En connaissant bien ton compilateur tu peux anticiper les trucs ±"débiles" qu'il fait (bon perso je connais pas encore assez mon compilo - SDCC  (pour SMS) - pour faire ce genre de choses de façon efficace, c'est comme tout faut du temps (bcp) ).

Je ne connais pas GCC, mais sur SDCC au niveau de la compilation tu peux lui faire (re)passer le code au travers d'un fichier pipeline afin de modifier (au niveau asm) les routines récurrentes qu'il fait de façon n'importequoitesque (via macros & cie).

En tout cas, comme déjà dit en direct à Fonzie, mes plus sincères félicitations à l'équipe WM.

[ob1]

Je ne connais pas GCC, mais sur SDCC au niveau de la compilation tu peux lui faire (re)passer le code au travers d'un fichier pipeline afin de modifier (au niveau asm) les routines récurrentes qu'il fait de façon n'importequoitesque (via macros & cie).

Ca c'est un débat philosophico-religieux très intéressant, merci Ichi ;)

Ma position, c'est de dire que le compilo est là pour te faciliter la vie. Pas à t'embêter à apprendre des trucs compliqués (ISA, timings, ...) pour être efficace. Mais pour tirer le maximum de l'intelligence de ton compilo, tu dois parfois apprendre des trucs spécifiques (register, volatile ... ici le fichier pipeline dont tu parles) qui sont loin de ton sujet premier, et qui pour le coup te facilitent moins la vie.

A nouveau, pour revenir dans l'informatique de gestion, c'est le dilemme Hibernate. Hibernate c'est très bien, je le dis parfois à mes étudiants : ça permet de ne plus faire de SQL, de jointures ou de trucs un peu sioux comme ça. Sauf, pour être vraiment bon avec Hibernate, il faut maîtriser des concepts pas forcément évidents : lazy ou eager, comment vérifier le plan, les paramètres, table porteuse, ... Et en définitive, tu te retrouves à chercher des réponses à des questions que tu te serais jamais posées si tu avais pas utilisé Hibernate en premier lieu (JDBC power !!!).

Je ne dis pas qu'il faut faire tout un jeu en ASM only. Le C, ça aide quand même sacrément, ne serait-ce que pour jeter rapido les bases d'un algo. Je ne dis même pas qu'une voie est supérieure à l'autre (tout C vs tout ASM, tout Hibernate vs tout JDBC). Chacune a ses avantages et inconvénients*.
Je pense sincèrement que c'est la situation ... et le développeur (!), qui font pencher la balance d'un côté ou de l'autre ^^

* : ça me fait penser à Kaamelott :
"l'avantage avec les opinions tranchées, c'est que ça relance le débat. En somme, vous êtes une sorte de provocateur",
Leodagan au Père Blaise, Livre V

PS : cette réflexion me fait penser à une phrase de Dave Small, l'inventeur d'un émulateur Mac sur ST :
"Si je veux aller vite, je fais de l'ASM. Si je veux m'amuser, je fais du Basic".
Bon, c'était à une période où les compilateurs C semblaient très mauvais ^^

Edit : mais je digresse. Revenons sur le sujet principal de Paprium ^^

[F.L]

Salut Ob1 (kenobi? )
Quand le jeu sera sorti , auras tu le droit de nous raconter son devellopement ?
Ça serait super interessant de lire ça sur le forum et d'en ouvrir un sujet
Qu'en pense tu ?
A+

[Invité]

Le Basic, c'est fantastic !!
Bon ben vivement Septembre, ma Nomad va adorer Papi-Rhum !!

[drfloyd]

voilà une idée : un beat'm up avec Papi Commando : Papy Rhum !

Avec des caisses de Rhum à éclater bien sur

[sengoku 2]

Salut, ob1.

Peux-tu expliquer dans un langage simplifié ( pas le vocabulaire de codeur ) à quoi sert le gain de 1.9 ms / frame ?
Moi, à mon avis je crois comprendre que c'est du gain en fluidité dans les mouvements des persos lorsqu'ils bougent, frappent etc...
Et c'est du gain optimisé dans le sens, où c'est du code 100 % utile qui ne demande pas une trop grosse charge au CPU et/ou DMA.

Ensuite, quel est le gain de la compression ?
Je crois savoir que 16 megas sont alloués à la partie sonore.
Et donc environ 63 megas pour la partie graphique .
La partie code, ça doit prendre à peine 1 megas. ( je peux me tromper )

Bref, vu les progrès en compression, j'aimerais savoir à combien correspond en données décompressées par exemple les 63 ou 64 megas de la partie graphique ?
Doit-on multiplier par 2, par 3 ou par 4 ?

[Invité]

Je dirais simplement qu'en ce qui me concerne, j'ai donné 2.4ms / frame supplémentaire à Fonzie.

Et ça, c'est très très cool.

J'adore .

[Invité]

J'étais sérieux, j'adore tout ce qui est optimisation de code, etc.

Quand je programmais en Pascal, j'ajoutais des (sous-)routines en assembleur pour le fun, et côté benchmark, c'était super.

[Invité]

J'étais sérieux, j'adore tout ce qui est optimisation de code, etc.

Raaah c'est moins marrant du coup 

[ace76]

en pascal?y'a quoi de plus vieux ,le Fortran?