[devlog] Super Tilt Bro. - Page 3

Hop, une jolie petite nouvelle à propos du projet : le prototype online.

Il y a bien longtemps j'avais fait quelques premières expérimentations qui s'étaient bien déroulées. Là j'ai l'ambition d'enfin intégrer ça correctement. Depuis le netcode a été amélioré et on a réussi à le faire tourner sur une vraie NES.

Avant d'intégrer ça à l'alpha de Super Tilt Bro. J'aurais besoin de savoir à quel point ça marche vraiment en conditions réelles. Donc voilà un prototype suffisamment stable pour être utilisé sans avoir l'impression d'être Anakin Skywalker dans une course de pods. Le prototype vient avec un émulateur, la ROM et des scripts pour lancer tout ça correctement sur l'un des deux serveurs : Amérique du nord ou Europe. Pour vous le bon choix sera généralement Europe

Voilà le lien magique : http://supertiltbro.wontfix.it/online.html

Merci de me faire des retours. Que l'expérience soit bonne, mauvaise ou toute pourrie. Tout retour m'aidera à savoir sur quoi me concentrer ensuite. Aussi, les serveurs ne seronts pas très fréquentés, pensez à prévenirs vos amis avant de lancer une partie, histoire d'avoir quelqu'un contre qui jouer.

Supeeeer !
Je vais m’organiser avec mon frère pour tester. Je vais peut-être faire de la capture video aussi pour les retours !!

Merciii !

Hâte d'entendre vos retours. Vous faites partie du top mondial sur ce jeu (même s'il suffit d'avoir joué pour rentrer dans le top.) S'il y a un truc que j'ai appris en implémentant ce netcode c'est que les problèmes sont clairement plus évidents pour les joueurs qui savent ce que font les boutons. Enfin, j'ai aussi appris tout un tas d'autres choses, ça méritera un article

Le retour de l'internet !

Super Tilt Bro. n'est pas un jeu rétro. Le but à toujours été d'en faire un jeu moderne sur une ancienne console. Et vous savez quoi ? Les jeux modernes, ça se joue en ligne !

Ça fait un bon moment que l'idée me trotte dans la tête, et j'avais même écrit un truc là dessus : topics/188767-devlog-super-tilt-bro/2#post-34 Les choses ont bien évoluées depuis, on arrive à le faire tourner sur de vraies NES et le protocole s'est bonifie. J'ai même eu l'occasion faire des parties transatlantiques sans aucun souci ! Donc voilà, comment ça se passe sous le capot.

D'un point de vue hardware, basiquement on colle une puce WiFi (ESP8266) dans la cartouche. Je suis loin d'être une brute en hardware, mais c'est juste ça et beaucoup de magie. Je vais surtout parler du netcode de Super Tilt Bro.


Les problèmes avec le jeu en ligne

Écrire un jeu qui se joue en ligne est réputé difficile. À tout moment, on doit s'assurer que les deux joueurs voient la même chose. Lorsque l'action est intense, quelques millisecondes de ping peuvent tout changer.

Considérons Alice et Bob qui jouent ensemble. Bob a préparé sa super attaque et Alice l'a esquivée au tout dernier moment, MAGISTRAL ! Mais il y a 20 millisecondes de ping entre les appartements d'Alice et de Bob, c'est commun, alors qu'une frame fait 16 millisecondes. Alice a esquivé sur la toute dernière frame possible, donc l'esquive est passée, elle est prête pour une contre-attaque sanglante. Malheureusement Bob reçoit l'information à propos de cette esquive la frame d'après, pour lui elle à esquivé trop tard et s'est prise l'attaque de plein fouet. C'est un cas typique de désynchronisation : les deux joueurs voient une issue complètement différente de leur combat.


Le netcode basé sur le rollback

Super Tilt Bro. implémente un netcode de type "rollback". On n'attend pas de connaître les inputs de l'adversaire, on les devine. Bien sûr il arrive qu'on se trompe. Dans ce cas, on revient à l'état du jeu avant de s'être trompé et on rejoue le plus rapidement possible (sans les afficher) les frames erronées.

Qu'est-ce que ça donne pour Alice et Bob ? Alice esquive à temps et son jeu l'affiche sans problème. Du côté de Bob, le jeu commence par "deviner" qu'Alice n'a pas esquivé a temps (c'est un super play comme on en voit rarement). L'écran de Bob affiche une frame où on peut voir Alice se prendre l'attaque. Quand l'information arrive, moins de 20 millisecondes après, le jeu rejoue les frames mal devinées. Alice n'a jamais été touchée. Ça veut dire qu'il y a eu une frame étrange, où Bob à vu l'attaque réussir, mais tout est revenu à la normale très vite. Le jeu peut continuer.


L'algorithme pour deviner les inputs futurs est super simple. On part du principe que rien ne va changer, aucun nouveau bouton pressé, aucun bouton relâché. Même avec un joueur taré qui fait six actions par seconde, sur un jeu à 60 FPS, on devine correctement 90% du temps.

Ajouter de la latence à l'input

Une autre astuce est de délayer les inputs, tout en les envoyant immédiatement sur le réseau. Disons qu'on ajoute artificiellement quatre frames de délai, soit 64 millisecondes. Tant que les messages mettent moins de 60 millisecondes à traverser le réseau, aucun rollback n'est nécessaire.

Voyons la partie entre Alice et Bob, cette fois avec quatre frames de délai à l'input. Quand Alice appuie sur le bouton esquive, l'effet n'est pas immédiat, donc elle se prend le coup en pleine poire. Une ou deux frames plus tard, Bob reçoit le message à propos de la tentative d'esquive, elle prendra effet plus tard. Les deux joueurs voient la même action : Alice a pris cher. C'est moins épique, mais au moins tout le monde voit la même chose et il n'y a pas eu de glitch.


Bien entendu, les deux façons de faire peuvent être utilisées conjointement. C'est ce que fait Super Tilt Bro. Les inputs sont légèrement délayées, ça suffit la plupart du temps. Quand il y a un pic de latence sur le réseau, le rollback est là pour rattraper les pots cassés. Simplement dit, le rollback provoque de petites sautilles, le délai d'input rend les persos moins réactifs, il faut trouver le juste équilibre entre les deux.

Ce que font les autres

Bon, maintenant on a une idée des techniques de mitigation de la latence implémentées dans Super Tilt Bro. La plupart des développeurs ne parlent pas ouvertement de leur netcode, c'est pourtant un sujet important et les différentes approches sont toutes intéressantes. Voici quelques-unes connues.

Super Smash Bros, le vrai. Ça ne se passe pas tout à fait pareil. Il n'y a aucun rollback dans le jeu de Nintendo. Au lieu de ça, le jeu ralenti ou même freeze en attendant les informations nécessaires. On peut facilement voir ces freezes en jouant sur une connexion instable. Pour mitiger l'impact de ces freezes, le jeu semble adapter le délai aux inputs dynamiquement. (Désolé pour ce "il semblerait", les infos disponibles ont été reverse ingénieurées, voir simplement devinées.) On sait pour sûr que Super Smash Bros Brawl note chaque connexion de la meilleure (avec trois frames de délai) à la pire (avec 15 frames de délai.) Des gens ont tenté de mesurer le délai de Ultimate avec une caméra haute vitesse, ils ont échoué pour le mode en ligne, c'était trop instable. Peut-être qu'Ultimate ajuste le délai au cours de la partie pour chaque joueur.

Cette approche qui consiste à éviter les rollbacks, quitte à freezer le jeu, a du bon comme du mauvais. Premièrement, c'est simple à implémenter, le seul cas spécial à gérer est d'attendre les infos nécessaires avant de continuer le jeu. C'est également peu coûteux en CPU et en mémoire. N'ayant pas besoin de pouvoir rejouer le passé, le moteur de jeu peux simplement oublier ce qui s'est passé avant et aller de l'avant. L'effet sur un pic de latence est un freeze, alors qu'un code de type rollback montrera des persos qui se téléportent. Le freeze est plus lisible, mais une petite sautille d'un personage perturbe moins de rythme du jeu. Ce doit être une question de préférence. Le plus gros problème est le jeu compétitif. Même à un niveau moyen, les joueurs ont appris des combos avec des rythmes très précis (parfois même frame-perfect). Si le jeu ralenti, freeze ou change le délai d'input au milieu d'un combo frame-perfect, c'est foutu, même si l'exécution du joueur était bonne. Enfin, les freezes doivent absolument être minimisés, donc en cas de doute, le délai d'input doit être au plus haut.

Une autre solution, bien connue celle-là est GGPO. C'est un netcode de type rollback fait pour pouvoir être utilisé tel quel par les développeurs de jeux. Il est très populaire dans l'émulation d'arcade et est la solution retenue par Skull Girls, jeu reconnu pour son bon netcode. GGPO fait du rollback, sa documentation ne mentionne pas de délai d'input, mais Skull Girls offre l'option. On peut y choisir un nombre de frames de délai qui restera le même pour toutes nos parties. Ainsi, le joueur peux choisir lui-même où placer le curseur entre trop de délai ou trop de rollback.

Ça ressemble beaucoup au netcode de Super Tilt Bro. Le bon point de cette technique est que le délai est fixé et constant. On peut placer nos combos frame-perfect aussi bien qu'en local. Le plus gros problème est lors de gros pics de latence sur le réseau. Les personnages ont tendance à se téléporter dans tous les sens le temps que les jeux réussissent à se resynchroniser. Dans ces cas là, on ne comprend plus rien, mais le jeu continue de se dérouler. Enfin, un moteur de rollback doit être capable de garder des save-states de lui-même et les gérer en mémoire, pour pouvoir revenir dessus en cas de rollback. Ça a un coût non négligeable en CPU et en RAM.

Toutes ces implémentations modernes on un point commun : le peer-to-peer. Éviter aux messages de transiter par un serveur permet de gagner quelques précieuses millisecondes de latence. C'est vraiment une très bonne solution. Super Tilt Bro., lui, utilise un serveur. Voyons pourquoi.

Le serveur de Super Tilt Bro.

On a vu que le peer-to-peer c'est le top. Super Tilt Bro. ne fait pas ça. On a aussi vu que le rollback avait un coût CPU et RAM élevé. Il faut gérer une liste de save-states en RAM et être capable de re-jouer plusieurs frames immédiatement à tout moment. La NES, avec son CPU 8 bits à 1,5 Mhz et ses 2 Ko de RAM est très, très, loin des systèmes modernes. Implémenter le système de rollback dans ses condition monopoliserait la plupart des ressources, et c'est le gameplay qui en payerai le prix. Le serveur est là pour aider.

Vous vous souvenez d'Alice et Bob ? Avec le protocole de Super Tilt Bro., quand Alice appuie sur un bouton son jeu envoie l'état de sa manette et un timestamp au serveur. Le serveur connait le jeu, il est capable de simuler des frames et de recalculer l'état du jeu à tout moment. Connaissant la partie et la nouvelle input d'Alice, le serveur peut calculer l'état du jeu au moment où Alice a appuyé sur son bouton et envoyer tout ça à Bob. Bob reçoit donc le timestamp, l'état de la manette d'Alice et l'état de la partie à ce moment là. Si le délai d'input à fait son travail, il peut ignorer l'état du jeu décrit dans le message. Si un rollback est nécessaire, la NES de Bob peut se baser sur l'état fraîchement reçu, qui est juste au moment où la prédiction était mauvaise. Donc la NES n'a aucun besoin de gérer une liste des états passés, ce qui retire presque toute la pression sur la mémoire.

Le serveur peut aussi aider avec le budget CPU. Disons, qu'il y a toujours au moins deux frames qui s'écoulent le temps qu'un message transite d'Alice vers Bob. Quand le serveur reçoit une input d'Alice, au lieu de calculer l'état du jeu au moment de l'input, le serveur peut calculer un état deux frames après. Le serveur se met à prédire le futur, de la même façon que l'aurait fait la NES de Bob, lui épargnant ce travail. Bien entendu, ça nécessite d'implémenter un système de rollback aussi dans le serveur, mais ça aide beaucoup à gérer les grosses latences. A l'heure actuelle, Super Tilt Bro. est capable de rejouer trois frames avant de manquer de temps. Si le serveur peut se charger de le faire pour une ou deux frames, ça aide beaucoup.

UDP, TCP... et les navigateurs web

Sur internet il y a deux gros protocoles omniprésents TCP et UDP. TCP est le plus commun, il permet à un ordinateur de se connecter à un autre et d'envoyer des données. Avec TCP il n'y a pas de perte de données et les données arrivent a destination dans l'ordre dans lequel elles ont été envoyées. Le gros d'internet est construit sur TCP, c'est super simple à utiliser. UDP de son côté est un protocole beaucoup plus léger. Avec UDP, quand on envoie un paquet, la seule chose assurée est que le paquet a été envoyé. Il peut être perdu en chemin, ou arriver avant un autre pourtant envoyé auparavant. Donc TCP est le meilleur protocole ? Pas du tout ! La magie dont est capable TCP a un coût.

Quand on utilise le protocole de Super Tilt Bro., les paquets perdus ne sont pas un gros problème. Un message du serveur contient l'intégralité de l'état du jeu, donc si on perd un paquet, on retrouvera nos petits avec le prochain. Si on utilisait TCP, qu'on envoyait deux messages à la suite et que le premier se perde. Le premier serait alors inutile, le second étant plus récent il nous intéresse plus. Bien que le paquet intéressant soit physiquement reçut, TCP assure qu'il ne sera pas utilisé tant que le paquet inutile soit reçut. Il faudra donc attendre que le paquet inutile soit ré-émit. J'ai testé d'implémenter ping avec des garanties similaires à TCP et en forçant 10% de pertes de paquets au niveau de mon driver réseau, le ping pouvait monter jusqu'à trois secondes par moments, contre 20 millisecondes normalement.

Vous imaginez avoir trois secondes de latence à cause de la perte d'un paquet inutile ? Hors de question !

Pour ceux qui suivent le jeu, vous avez remarqué l'émulateur HTML5 sur la page itch.io. Ça semble anodin, et ça ne l'est pas du tout. Les navigateurs web se sont construit sur TCP, depuis des décennies. Ils ne laissent pas une page web envoyer des paquets UDP simplement. Super Tilt Bro. est basé sur l'UDP et il en a besoin. La solution à été d'utiliser WebRTC, un protocole fait pour les vidéo conférences. C'est ce qu'utilise votre Skype online, Google Meet, Facebook "appel vidéo",... préféré. Détourner un protocole de vidéo conférence pour y faire passer un prtocole de jeu a été épique. J'écrirai peut-être un truc là-dessus, en attendant, voilà le fil Twitter en temps réèl de mon combat contre la sécurité du web : https://twitter.com/RogerBidon/status/1259171335135211523

Un dernier mot

Implémenter des possibilités réseau moderne pour la NES à été épique... Et ce n'est pas fini ! Ça à fait son chemin jusqu'à l'ALPHA. Ce n'est pas complet et j'ai terriblement besoin de feedback.

C'est testable ici (HTML5 ou émulateur patché) : https://sgadrat.itch.io/super-tilt-bro

Il y a aussi un Discord pour trouver des joueurs : https://discord.gg/qkxHkfx

Voilà, j'espère que ce petit bout de connaissance de l'internet pourras servir à quelqu'un. N'hésitez pas à poser vos questions pour de plus amples détails. Super Tilt Bro. est un projet libre. Il est là four faire de l'internet un meilleur endroit (à son niveau), pas pour protéger des secrets.

Merci c'est extra

Impressionnant !

formidable! bravo!

Merci, merci !

Petites news du projet

Bon, bah, j'ai ré-implémenté un moteur de musique à partir de la page blanche. Mais pourquoi ? Deux raisons :

1. C'est rigolo à faire
2. J'ai en tête des fonctionnalités qui n'existent dans aucun
3. J'ai calculé que ça ne serait pas si long... mais je ne sais pas compter.

Le moteur est encore en rôdage, mais il fait déjà quelques trucs cools. Je vais le comparrer à ggsound et famitone, qui sont eux aussi des moteurs fais pour être utilisés par des jeux. Aussi au driver de Famitracker, qui lui est hyper complet mais bouffe beaucoup de ressources et est rarement utilisé pour des jeux, par contre en chiptune, c'est l'idéal.

1. On peut lui faire jouer des morceaux de Famitrackers qui contiennent des effets. ggsound et famitone ne font pas ça, ce qui oblige les compositeurs à faire en fonction du moteur,
2. Il est rapide et léger, il faut que je pousse la comparaison, mais pour l'instant il semble battre ggsound/famitone (de pas grand-chose, c'est comparable),
3. La taille des musiques importées est plus grosse que ggsound/famitone, sans être aussi obèse qu'avec Famitracker.

Et donc a terme j'aimerais lui faire jouer des musiques dynamiques. Qui changent de rythme en fonction du déroulement de la partie... Mais on n'y est pas encore. Je pense que je vais me motiver à écrire une entrée de devlog sur ce qui est déjà là. Il y a déjà une énorme quantité de détails techniques croustillants

Sinon, on a aussi fait un nouveau trailer avec une amie qui se lance en freelance de motion design. L'ancien avait déjà trois ans et ne ressemble même plus au jeu



Instant promotion gratuite : du coup si vous avez des besoins de motion design, pensez à elle. Elle répond sur son instagram.

Ce trailer !

Fei (./71) :
Ce trailer !

Grave !!!

Ça donne vraiment envie...

Merci ! Ça fait plaisir a etendre. A force de le regarder en boucle, j'ai appris a n'en voir que les défauts et trucs qui auraient pu être autrement

Relayé sur flipboard

https://www.mirari.fr/qtAk

Héhé, apparemment l'idée du jeu NES en réseau ça plait. Je ne vais pas m'en plaindre

Netcode rollback sur la NES : les détails inavouables.

Attention, celui-là il va être technique !

Super Tilt Bro. ALPHA 5 vient de sortir. Grosse nouveauté : on peut jouer en ligne avec n'importe quel personnage sur n'importe quel niveau. Le moment idéal pour faire un bilan sur le fonctionnement du netcode, et les plus gros obstacles surmontés.

Vous les savez puisque vous avez lu le dernier post (au moins les parties avec des images), Super Tilt Bro implémente un netcode basé sur le rollback. L'expérience reste toujours fluide, quand les messages de l'autre NES prennent du temps à arriver, le moteur les prédit et continue d'avancer. Bon, parfois il se trompe. Dans ce cas il efface ses prédictions et re-joue les frames manquantes pour revenir à l'état courant de la partie.

Le protocole

Les netcodes basés sur le rollback sont connus pour être difficiles à implémenter. Il n'y a qu'à chercher un peu pour trouver des postes très longs et très sérieux assurant que la Switch n'est pas assez puissante pour faire ça. Et donc, comment réalise-t-on l'impossible sur NES ? (Vous vous en doutez : en trichant !)

Un des gros problèmes quand on implémente ce genre de netcode, c'est la gestion de la mémoire. Le jeu doit littéralement garder une copie de chaque état qu'il a prédit pour pouvoir s'en servir comme checkpoint. Tournant sur NES, avec 2 KB de mémoire (et pas des plus rapides), Super Tilt Bro. doit éviter ça à tout prix. Quand on n'a pas de mémoire, la solution est d'utiliser celle des autres. Les routeurs entre le serveur et la NES sont bourrés de mémoire !

Le protocole en quelque lignes :

• Quand le joueur appuie sur un bouton, un message est envoyé au serveur. Un tout petit message, juste l'état de la manette et un timestamp.
• Le serveur calcul l'état du jeu au moment de l'action. Il envoie un message étendu à l'autre NES.
• Le message étendu contient : l'état de la manette, le timestamp et l'état du jeu à cet instant.
• La NES qui reçoit ce message à tout ce qu'il lui faut. Il n'y a plus qu'à remplacer l'état du jeu par celui dans le message et simuler quelques frames pour compenser le temps de transit du message.
  

Voilà, la NES n'à plus à s'occuper de la gestion difficile de la mémoire. Le serveur s'en occupe et transmet tout ce qu'il faut. Aucun problème pour les routeurs, car on est sur NES, l'état de notre jeu fait une grosse centaine d'octets. C'est encore un tout petit paquet sur l'internet moderne. Il y a tout de même des compris faits. Déjà le serveur est plus complexe, il intègre un émulateur pour déterminer l'état du jeu. Le pire étant que, du coup, le serveur est nécessaire, impossible de migrer vers un protocole peer-to-peer. Avec le temps, on verra bien si ce rollback en passant par un serveur rivalise avec les netcodes basés sur l'input-lag en peer-to-peer.

Ok, second vilain : le CPU

Donc la NES a reçu un ancien état depuis le serveur et doit simuler les frames manquantes pour coller au présent. Ça DOIT être rapide. On ne veut pas délayer ça sur plusieurs frames vidéo, accélérant la vitesse de jeu, ça ruinerai le timing des inputs et ferait rater leurs combos aux joueurs. On veut rollback instantanément, qu'a la réception du message le jeu soit immédiatement mis à jour. On dispose d'exactement 20 millisecondes pour faire ça sans rater une frame vidéo (en PAL.)

La première chose à faire est de pouvoir mettre la simulation en “mode rollback”. Dans ce mode, rien n'a besoin d'être affiché, le moteur peux simplement ignorer tout ce qui est placement de sprites, modification du background, et tout ce qui est visuel.

Si on ne fait que ça, simuler une frame en rollback prend 25% de nos 20 millisecondes. Ça pourrait suffire à rollback quatre frames, donc compenser 80 ms de ping, si le reste du jeu ne prenait pas 60% du temps disponible. Notamment, on veut toujours simuler une frame en mode normal, juste histoire de voir quelque chose à l'écran. Du coup, ça permet de jouer, mais le moindre rollback est vite problématique.

Après ça, il reste l'optimisation pure et dure de tout ce qui est fait plusieurs fois par frame. La détection des collisions est là où on a vu les plus gros gains. C'était un vieux bout de code, implémenté tout en apprenant les base de 6502, et ça tourne chaque frame, pour chaque joueur, pour chaque plateforme... plusieurs fois. Autant dire que le grand ménage a été fait là-dedans.

Un autre gain a été trouvé sur le code qui gère les animations. En mode rollback, on se fiche de placer des sprites à l'écran, malheureusement les hitboxes sont définies dans les animations. Le moteur se retrouvait donc à parser des définitions de sprites, au cas où il y aurait une hitboxe au milieux. Ici l'astuce a été de toujours placer les définitions de hitboxes au début, le moteur s'arrête tout de suite après en mode rollback. Et puis des optimisations bas niveau, ça ne fait jamais de mal.


Avec ça, on n'arrive pas encore à compenser les grosses latences. Heureusement, on a un serveur à disposition. Après tout, le serveur peut lui aussi prédire des frames, et il le fait. Il prédit juste ce qu'il faut pour compenser la latence minimum observée. Disons que le ping oscille entre 100 et 140 ms, le serveur va prédire de quoi compenser 100 ms. Dans le pire des cas, la NES devra compenser 40 ms, ce qui fait deux frames.

C'est quoi la suite ?

Ce netcode va avoir besoin de gagner l'expérience du terrain. C'est sûr et certain il n'est pas parfait, mais en quoi précisément ? Le seul moyen de le découvrir est de l'essayer, de jouer avec... de l'éprouver en somme. Plus il est utilisé, plus on trouvera de trucs, donc n'hésitez pas à l'essayer par vous-même, forcez vos amis à jouer avec vous, et envoyer moi toute remarque (promis, je ne m'énerverais pas.) Tout commence ici : https://sgadrat.itch.io/super-tilt-bro

Bon, aussi le netcode c'est bien, mais ce n'est pas tout ce qui fait un jeu en ligne. Pour l'instant, une interface moche nous bombarde dans une partie et voilà, point. Je pense commencer par créer un classement officiel consultable en ligne. Comme ça, si on est le meilleur au monde on pourra enfin se la péter. C'est important !

Vivement le petit livret making of offert avec le jeu

Benchmark des différents compilateurs C pour le 6502


Choisir un compilateur C pour le 6502 n'est pas si facile. Chacun à son lot de forces et faiblesses. On peut chercher la vitesse, la facilité d'utilisation, le respect du standard, ou vraiment n'importe quoi.

Quand j'ai dû faire ce choix pour Super Tilt Bro., la vitesse était le dernier de mes soucis. Cependant, en discutant avec d'autres developpeurs, le sujet revenait toujours sur le tapis. Ça sera donc notre principal focus : quel compilateur produit le code le plus rapide ?

Quelques petits bouts de code seront comparés. À chaque fois on expliquera ce que fait le code et pourquoi il est pertinent de le bencher.

Ensuite, je parlerai de mon expérience à utiliser chacun de ces compilateurs. Leurs forces et faiblesses au-delà de la performance. Forcément, c'est subjectif, j'essaierais de rester factuel mais je ne promets rien.

Enfin, une petite section "comment choisir son compilateur" conclura cet article. En espérant que ça serve à quelqu'un.

C'est partit !

Les candidats au - très convoité - titre de meilleur compilo ?

cc65 est le plus utilisé. Il bénéficie d'une énorme suite d'outils, est activement maintenu, se bonifie avec le temps et à une grande communauté d'utilisateurs. Ceci dit, il a la réputation de produire un code particulièrement lent... on verra bien

vbcc c'est le compilateur tendance. Moins utilisé que le roi, il a la réputation de produire un code bien meilleur.

KickC est le petit jeune plein d'avenir. Est-ce qu'il a déjà de quoi jouer dans la court des grands ?

6502-gcc est un sombre inconnu. Personne ne le maitrise vraiment, le projet semble mort, les instructions d'installation sont impénétrables,... Nous allons tenter de faire la lumière sur ses inavouables secrets !

6502-gcc à deux options de compilation très différentes :

• "-O3" optimise le code pour être rapide
• "-Os" optimise le code pour être petit
  

Décompression

Ce benchmark est issu de la vraie vie. Il s'agit d'une fonction prototypée en C pour Super Tilt Bro. avant d'être convertie en assembleur à cause de mauvaise performances. Les données compressées sont aussi celles d'origine.

La fonction fouille dans un tas de données compressée pour en extraire quelques octets. C'est de la grosse logique qui boucle, passant son temps à lire la mémoire.



Ça saute aux yeux, cc65 est fidèle à sa réputation. Le code généré est extrêmement lent.

Le gagnant est 6502-gcc, avec une avance correcte sans être confortable. KickC à un très léger avantage sur vbcc.

Fun fact : plus un compilateur est populaire, pire est sa performance sur ce test.

Memcopy

Là, c'est la tâche la plus commune au monde : on copie des octets d'un endroit à l'autre de la mémoire. Il est toujours judicieux de comparer les compilateurs sur ce qu'on leur demandera de faire le plus souvent.

Il y a deux versions de ce test :

• Le normal est une boucle qui copie les données
  • le compilateur peut déterminer les adresses et la taille des données, ainsi il peut optimiser pour ce cas particulier.
• Le "no-inline" passe par une fonction indépendante
  • le compilateur est forcé de générer un code générique de copie d'octets
    

cc65 est fidèle à son poste de dernier.

KickC confirme être un poil plus rapide que vbcc. À noter l'absence de KickC dans la version "no-inline" : KickC fonctionne toujours en connaissant tous les sources du projet, impossible de l'empêcher d'inliner.

6502-gcc prend un coup dur ici. Pire, en menant d'autres tests on s'aperçoit que ses performances varient énormément en changeant quelques détails dans le code.

Aussi, avez-vous remarqué que "-O3" est terriblement mauvaise dans la version inline ? gcc (le "vrai" ainsi que 6502-gcc) fonctionne en deux étapes : le front-end optimise le code C, puis le back-end génère du code machine. Le front-end de 6502-gcc est le même que celui de gcc, il optimise comme un dieu, puis vient le back-end. Le back-end 6502 manque sévèrement d'amour et ça se voit ici. Dans notre cas, le front-end comprend ce qu'on fait et dis simplement au back-end "copie 200 octets de $400 vers $200". Le back-end devrait implémenter ça de la façon optimale, mais il se contente d'appeler "jsr memcpy", qui est la fonction standard de copie et n'est pas DU TOUT adaptée à un CPU 8 bits.


Le meilleur JDR au monde !

Disclaimer : ce bench a été pensé pour tirer avantage du front-end extraordinaire de 6502-gcc.

C'est un moteur de JDR avec tout plein d'abstractions. Il y a des structs, des fonctions pour que le héro frappe, des fonctions pour que le monstres reçoivent un coup, le héro porte une arme,...

La fonction benchée initialise l'état du jeu, joue un tour et retourne. Du coup, bien qu'il y ait plein d'appels de fonctions, de calculs de point de vies, et d'aller-retours, finalement la fonction doit simplement mettre la mémoire dans l'état du jeu après un tour.


cc65... ça devient lassant. Bon, ce test n'est définitivement pas pour lui. cc65 ne fait strictement aucune optimisation de haut niveau alors que bench test la qualité des optimisations de haut niveau.

KickC est un meilleur vbcc côté performances. Rien de nouveau.

6502-gcc ne déçoit pas. Son front-end est l'un des meilleurs au monde (sans mentir ni exagérer) et là, il voit l'arnaque. Le code généré est une simple succession de "LDA <constante> : STA <mémoire>" pour écrire en mémoire l'état de la partie après un tour de jeu.

Du code pour cc65

Avez-vous lu le superbe article "Advanced optimizations in CC65" ? Vous le trouverez ici :

Opération sauvez le soldat cc65 ! On va bencher un code spécialement fait pour cc65, codé par un expert. Ça devrait le faire, hein ?

Le code est comparable au moteur de JDR : c'est un moteur de JDR plein d'abstractions inutiles. La différence est qu'il boucle 100 fois et affiche les personnages à l'écran à chaque fois, donc pas moyen de simplement réduire ça à une suite de LDA+STA, il va falloir calculer des trucs.

Sur cette base, Ilmenit applique différentes optimisations jusqu'à ce que le code aille vraiment vite.

On benchera deux versions : la première, sans optimisation, et la dernière, avec toutes les optimisations.


KickC a disparu et vbcc en piteux état !

KickC a simplement trop de limitations pour compiler ce code. Entre autres il refuse de générer du code pour un modulo ou une division.

vbcc a généré une boucle infinie sur la version non-optimisée. Il a aussi souffert de mon manque d'expérience pour l'intégrer à mon outil (d'où l'absence d'info sur la taille du code.)

6502-gcc a dévoilé un sal bug. Les variables globales sont visiblement mises dans un segment au hasard. L'assembleur généré a dû être fixé à la main pour le faire tourner.

Donc, même sans lire les graphiques : cc65 a gagné ! Il est le seul à réussir à compiler ce code !

Il est intéressant de voir que 6502-gcc n'est pas particulièrement bon sur la version non-optimisée. Après tout ce qu'on a dit sur la puissance de ses optimisations de haut niveau ! Le truc c'est que le code ne lui permet pas d'inliner. En C, quand on déclare une fonction sans la précéder de "static", elle doit être accessible aux autres unités de compilation et donc être complètement utilisable : avec passage de paramètres par la pile et tout le tintouin. Bien sûr ça ne change pas grand-chose pour cc65 qui de toute façon n'inline rien.

Sur la version optimisée, il n'y a pas de grande différence. vbcc est derrière mais souffre peut-être de mon inexpérience et de mesures grossières. Le code a été optimisé pour être facile à compiler, rien d'étonnant à ce que tous les compilateurs est à peu-prêt le même résultat.

Et ce "???", qu'est-ce que c'est ? Si vous n'avez pas encore lu "Advanced optimizations in CC65" (Ayez honte!), vous ne vous rendez pas compte à quel point le code optimisé est illisible. Toutes les astuces possibles et imaginable y sont passée, même l'auteur ne recommande pas ça dans la vraie vie.

"???" c'est "6502-gcc -Os", sur un code avec seulement deux des 12 optimisations et surtout le mot clé "static" utilisé à bon escient. Cette version ressemble beaucoup à la version non-optimisée et la pénalité de performance est quasi nulle.

C'est pourquoi je pense que les optimisations haut niveau sont importantes. Elles permettent d'écrire en C, sans trop se soucier de l'assembleur généré. On laisse les astuces bas niveau au compilateur et on se concentre sur la logique.

Les performances, ce n'est pas tout

Ok, côté performances il semblerait que cc65 est loin derrière, vbcc et KickC sont quasiment ex aequo et 6502-gcc oscille entre l'excellence et la catastrophe.

À vrai dire, les performances, ce n'est pas ce qui devrait compter le plus quand on choisit un compilateur C (pour le 6502.) Apprenez l'assembleur et vous aurez toujours moyen d'injecter des performances là où ça compte.

Voici un petit résumé des avantages et inconvénients de chaque compilateur :

cc65
Pros

• Rock-solid et battle-tested, il ne vous claquera pas entre les doigts.
• En développement actif
• Plein de ressources disponibles pour apprendre
• L'une des suites d'outils les plus complètes
  

Cons

• Performances (sérieusement, c'est son seul défaut)
  

vbcc
Pros

• Performances acceptables
• Il a des utilisateurs actifs
• La documentation est super complète
• Suite d'outils bien fournie (assembleur, linkeur, fichiers de configurations,...)
  

Cons

• Pire licence possible (vraiment je recommande de l'éviter à cause de ça)
• Parfois buggué
  

KickC
Pros

• Bonnes performances
• Difficile à intégrer avec d'autres outils (il veut compiler tout un projet d'un coup)
• Développement actif (et la base est bonne, le futur s'annonce prometteur)
  

Cons

• Respect partiel du standard C (même "const" est mal supporté)
• La compilation est lente
• Les erreurs de compilation sont cryptiques
  

6502-gcc
Pros

• Respecte le standard C à la lettre
• Optimisations haut niveau qui profitent de la puissance de gcc
• Génère de l'assembleur pour ca65 (et donc compatible avec tous les outils de cc65)
• Erreurs et warnings lisibles, et qui peuvent même remonter de vrais bugs dans votre code
  

Cons

• Développement inactif
• Buggué
• Qualité du code généré très variable
  

Ok, donc lequel choisir ?

Comme toujours, ça dépend ! Qui êtes-vous ?

Êtes-vous un développeur expérimenté, habitué à l'un de ces compilateurs ? Restez dessus, vous le maîtrisez déjà, les autre n'apportent que peu d'avantages.

C'est votre premier projet C pour le 6502 ? Il vous faut cc65, c'est le plus mature et vous trouverez de l'aide quand vous en aurez besoin.

Il vous faut des optimisations de haut niveau, et un truc qui marche sans se prendre trop la tête ? KickC est fait pour vous.

Il vous faut des optimisations de haut niveau, et avez tendance à exploiter les détails du standard C ? Vous être prêts à vous faire vos propres outils au besoin ? 6502-gcc est le compilateur idéal.

Non. Je ne recommanderais jamais vbcc. Sa licence est horrible. Les sources ne sont pas disponibles et vous ne pouvez pas l'utiliser pour "usage commercial" (sans définition spécifique, ni d'info si ça s'applique aussi aux programmes générés.) En prime, il intègre divers outils et bibliothèques qui ont chacun leur propre licence. Pour faire les choses bien, vous devrez au moins lire trois licences avant de savoir si ce que vous avez en tête est autorisé.

Un dernier mot

Les benchmarks c'est joli et montre un classement clair, mais ce n'est jamais parfait. Ces benchmarks en particulier, c'est ma première expérience avec la plupart de ces compilateurs, j'ai possiblement raté des choses. Si vous voulez jouer les apprentis sorciers vous-même, l'outil utilisé est disponible ici : https://github.com/sgadrat/6502-compilers-bench Ça prend un fichier C et sort les infos de rapidité ainsi que l'assembleur généré.

En espérant que cette petite recherche aide quelqu'un un jour. Mais n'oubliez pas, en développement rétro, l'important c'est de s'amuser (au sens geek du terme.)

Juste GENIAL !
Thanks!

Héhé, moi qui avait peur d'être trop technique sur ce coup. J'imagine que comparer les compilateurs C n'est pas le dada de tout le monde. Ça devait être fait, trop de questions sans réponses claires, mais je vais tenter de me calmer pour la suite et rester sur des choses que les joueurs peuvent visualiser.

Merci matmook, ton entousiasme va droit dans mon petit cœur

C'est beau du CC65 optimisé, hein ?
Il y a d'autres articles du même accabit (peut-être une partie des mêmes probablement) ici :
https://sourceforge.net/projects/cc65extra/files/

Disons qu'à écrire en C en pensant à l'assembleur, on perd beaucoup de l'intérêt du C.

Je ne sais pas pourquoi cc65 refuse les optims haut niveau. J'imagine que c'est un nid à bugs incroyable pour le compilo qui, d'un coup, doit gérer correctement les barrières mémoire même dans la logique abstraite.

C'est ce que j'ai aimé avec 6502-gcc. On peut faire un block inline asm et savoir que les clobbers sont respectés à la lettre. On peut appeller une fonction externe et savoir que toutes les écritures mémoire son effectives au moment de l'appel. Je n'aurais confiance en aucun autre pour ce genre de choses (a part cc65, au prix de la perf)