Homemade Pixels

Des pixels frais qui sortent du four le blog de MrHelmut.

Archive pour décembre 2011

« Articles plus anciens

Global Game Jam 2012

Mardi 20 décembre 2011

Tu aimes le jeu vidéo ? Tu es développeur, graphiste, musicien ou joueur de claquettes ? Tu aimes manquer de sommeil ? Le Global Game Jam est fait pour toi.

default_game_0Le Global Game Jam (GGJ), c’est 48h non-stop de création de jeux vidéo ! C’est un événement mondial qui se déroule tous les derniers week-ends de janvier avec plus de 150 sites pour y participer et notamment en France.

Cette année, cela se passe le week-end des 27-29 janvier 2012. Tous les profils sont les bienvenus : amateur, professionnels, étudiants, curieux… L’important, c’est de passer un bon moment autour d’une même passion.

Et les nofragés dans tout ca ?

Je dénombre quelques nofragés qui sont coutumiers de l’exercice. Nemo de Swing Swing Submarine (et son accolyte Guillaume), Mathieu de Frogames, Celibatman et Valryon (si il y en a d’autres, faites moi coucou). Ils ont participé aux jams de 2011 et 2010 qui se sont tenus à l’ISART à Paris, avec le concours du studio MekenSleep (excepté Valryon qui a participé à Rennes).

Vous pouvez d’ailleurs lire leurs comptes rendus des années passées : 2010 (chez Mathieu), 2010 (chez Nemo) et 2011 (chez Mathieu).

Les sites du Global Game Jam 2012 en France

Nos amis Belges, Suisses et Canadiens ne sont pas en reste et ont aussi plein de sites, à voir sur le site général du GGJ.

Moi ?

Pour ma part, je vais à Metz !

Bien évidemment, et comme mes homologues nofragés, je vous ferai un post-mortem du Jam et de son organisation. Et j’en profite pour souhaiter un bon jam à tous les jammeurs francophones !

Lost project : “Last but not Least”

Samedi 17 décembre 2011

J’ai un problème. Celui de bien des développeurs. J’ai plein d’idées de projets, quand j’en commence un je suis à toc, et une fois que le challenge technique est passé, le projet prend la poussière… L’eau coule sous les ponts, jusqu’à ce que j’ai une nouvelle idée de projet. Rinse. Repeat.

En marge de mon début sur l’émulation, je compte vous proposer une série d’articles “Lost projects”, témoin de ces projets (plus ou moins aboutis) de garage qui finissent inexorablement par tomber à l’eau.

Un de ces projets est “Last but not Least” (2008). Il est né de ma lecture du bouquin de James Silva sur XNA (lien non affilié), le monsieur derrière The Dishwasher: Dead Samurai. J’avais pas mal aimé l’approche de son livre qui se résume par “je vais vous montrer comment on fait un jeu dans son garage, avec du scotch et des ficelles”. Bref, comment faire un jeu sans se casser la tête. A contrario, j’avais détesté le livre de Benjamin Nitschke parce qu’à chaque page, il essayait de me refourguer des tests unitaires de code (même sur des parties graphiques), alors que moi, je voulais juste aller droit au but et voir ma démo bancale tourner. D’un côté, il avait annoncé la couleur dans le titre de son livre avec le mot “professional”.

Mais revenons à nos moutons, le livre de James Silva. C’est un peu comme un making of de The Dishwasher. D’ailleurs, on sent bien qu’à l’issue de sa lecture, on a en mains un moteur 2D moderne (avec shader & co) qui partage beaucoup de fondations avec ses propres jeux. Le résultat, on peut le voir dans la vidéo ci-dessous.

YouTube Preview Image

Pas la peine de s’extasier trop longtemps dessus, je dois avouer qu’il n’y a aucun mérite à avoir suivi un livre. J’avais juste refait entièrement l’éditeur de niveaux  et l’éditeur d’animations avec de vraies fenêtres, car ceux que James proposait de coder étaient assez affreusement inutilisables (ou plutôt pas ergonomiques pour un sous). Mais le résultat m’était des plus satisfaisants. Suffisamment pour que ma machine à game design entre en ébullition.

J’avais donc commencé à bosser sur le game design de “Last but not Least”. Un beat them all 2D, satire de la représentation du bien et du mal dans les jeux vidéo. Le pitch ? “Lassé de voir des jeux vidéo où le bien et le mal s’affrontent, où le plombier sauve la princesse etc., le dieu du jeu vidéo décide d’y mettre un terme en faisant triompher le bien une fois pour toute. Après une guerre sans merci, tous les démons furent exterminés, excepté un, dont les forces du bien avait au passage anéantie sa bien aimée : sa moto”.

lbnlUn des rares pseudo artwork du projet. Réalisé par Az’, un ami (si tu me lis o/ ).

On arrive grosso modo sur un beat them all où l’on dirige un démon armé d’un pot d’échappement de moto (j’ai du trop joué à Full Throttle). Les niveaux s’étalonnent de l’enfer jusqu’au paradis (facon escalade du mont olympe dans God of War), dans le but de fritter les forces du bien pour venger son destrier. Pastiche des autres jeux, les ennemis rencontrés étaient des caricatures des héros du JV et le jeu devait être jonché de clins d’oeil, comme un traveling façon Ghosts’n'Goblins entre les niveaux. Le jeu devait se solder par une epic battle contre le dieu du JV, alias Peter Molyneux (que je ne tiens pas en éloge pour autant). Le tout sur un fond de métal indus’ (avec un groupe ardennais d’hardcore en candidat). J’avais mis sur papier une bonne partie du design, levels, personnages, caractéristiques, armes, gameplay, combo…

Aujourd’hui, je ne sais pas où j’ai rangé la “bible” de ce projet, et je ne sais pas si j’ai encore le code source du moteur 2D retrouvé !

Statut du projet : abandonné.

En guise de bonux, je fais le parallèle avec un mec ultra doué, qui n’est pas programmeur à la base (!), mais qui en lisant le même livre a fait son propre jeu : Dust. Il est tout seul à le faire sur son temps libre de père de famille (depuis 4 ans maintenant). Voici un trailer plus très frais.

YouTube Preview Image

Ca calme… Bon, il triche, c’est un animateur professionnel.

Je suis ce mec via ma participation à la communauté XNA, et depuis le jeu a beaucoup évolué (on a pu le playtester).  Il est en train de pondre un metroidvania assez énorme. Il a aussi raflé le gros lot du concours Dream.Build.Play de 2009 (ou 2010, je ne sais plus), qui lui garantis un contrat d’édition avec Microsoft pour une sortie XBLA, qu’il espère pour 2012. Il participe aussi au concours de l’IGF de cette année.

Quand à moi, j’ai débuté plein d’autres projets entre temps (ou avant), mais heureusement certains sont encore debout et me tiennent plus à coeur. Next in line : “Super Speed Racer 2000″ ou “Deep Assault”.

EDIT : publié à 13h37 sans faire gaffe o/

So, you want to code an emulator ?

Jeudi 15 décembre 2011

Cet été, j’ai découvert qu’il existait un émulateur Wii très performant, Dolphin. Cela faisait un moment que je n’avais pas guetter la scène émulation. Aux dernières nouvelles que j’avais prises, il existait un émulateur Gamecube, des plus bancal (c’était déjà le projet Dolphin). Autant vous dire que j’ai pris une claque en lançant cet émulateur Wii sur ma machine (un peu comme à l’époque où Chankast avait débarqué de nul part). Cerise sur le gâteau, il est open source. Alors quand j’ai mis la tête dans le code, je me suis dit : MER IL SON FOU.

J’adore comprendre les choses, ce qui se passe en “behind the scene”, ce que mon processeur fait si je lui dis de faire A + B. J’ai codé 1001 choses dans ce but, mais je ne sais pas pourquoi, les émulateurs ont toujours eu quelque chose de mystique pour moi. De mon approche naïve, faire un émulateur consiste à écrire un programme qui simule en 1:1 les composants d’une machine. Mais ce que j’ai vu dans le source de Dolphin n’avait rien à voir. Il ne reproduit pas les composants, mais recompile des opcodes PowerPC vers x86 (facon JIT). Bref, des dingues, mais diable que c’est performant. La plupart des bons émulateurs font des choses de ce genre.

Bien entendu l’approche naïve est viable pour de petits hardware. Je me suis donc armé de mes connaissances en archi hardware et assembleur pour créer mon propre émulateur. Ainsi, je me suis attaqué à un système simple : la Gameboy. Il y a plein de systèmes sympa pour débuter, les Atari, la Nes, etc, mais la GB a l’avantage d’avoir un hadware très largement documenté via ce qu’on appel la “pandocs”, dont un miroir est trouvable par ici, mais aussi de la doc sur les instructions CPU.

Le résultat, c’est SilverGameboy, un émulateur codé en C# (avec une sortie Silverlight ou XNA suivant la version), tournant sur PC/Xbox360/WindowsPhone. Je compte ouvrir les sources dès qu’il aura atteint un degré de finition satisfaisant.

SilverGameboy

Ce qu’il lui manque encore pour être “fini”, en dehors d’habituels bugfix :

  • Le support du rom banking (pour l’instant uniquement MBC1, avec des bugs, donc 90% des jeux encore injouables)
  • Le son (assez problématique sur Xbox360 et WP7, car pas d’accès bas niveau à la couche sonore)
  • Tout ce qui touche à la Gameboy Color (et le Super Gameboy, mais ca je crois que je ne vais pas le couvrir)
  • Et j’aimerais bien faire un wrapper réseau du port série pour jouer en multi (devrait être assez trivial)

Les petits trucs que j’ai trouvé “marrants” en le faisant :

  • Le CPU possède ~512 instructions, que j’ai mis quelques heures à écrire et… plusieurs jours à déboguer. Heureusement pour ca il existe des ROMS de test qui testent rigoureusement les instructions une par une, le bon comportement des registres etc. Malheureusement les tests ne sont pas très explicites en dehors de dire “passed” ou “failed” alors que 200 instructions peuvent être erronées :-/. Je m’en suis sorti en “trichant”, j’ai pris les sources d’un autre émulateur que j’ai modifié pour avoir une trace d’exécution, que j’ai comparé avec une trace de mon propre émulateur pour comprendre ou ca clochait. Je me suis retrouvé à faire des “diff” sur des fichiers de traces de 500Mo. La où le bas blesse, c’est que les documentations sur le CPU de la GB sont contradictoires : d’une doc à l’autre, les “flags” et les timings ne sont les même. Je ne comprenais pas pourquoi d’un émulateur à l’autre, ils implémentaient des instructions si différemment. Comment faire pour être sur de coller au hardware ? Coder un test GB et demander à un copain qui a un SDK Gameboy de l’exécuter sur un vrai hardware…
  • Le rom banking, c’est barbare. Le rom banking, c’est une méthode des plus utilisées pour palier à des limitations hardware. La Gameboy ne peut adresser que 64ko à la fois (dont 32 dédiés à la ROM d’un jeu). Or, certains jeux font jusqu’à 2mo. Les cartouches sont alors découpées en plein de “bank” mémoire de 32ko, et au besoin on les échange pour aller taper dans la totalité. Ce que j’ai trouvé spé, c’est la facon dont on change de bank. Dans chaque cartouche de Gameboy, il y a une puce, qui gère les banks. Les cartouches sont de la mémoire en lecture seule (normal, sinon on pourrait modifier des jeux), or, il est possible d’”écrire” dessus. C’est la puce qui gère les banks qui va comprendre que en écrivant, vous voulez changer de bank (mais ne va pas vraiment écrire). Je ne sais pas comment le rom banking est géré sur d’autres hardware, mais le coup de la nécessité d’une puce dans chaque cartouche et le principe de faire une fausse écriture pour changer de bank, je trouve ca barbare. Mais il y a plus pourri, il existe plusieurs versions de cette puce (appelé Memory Bank Controller, aka MBC), et forcément, chaque version a un comportement différent. Il en existe une petite dizaine et certaines sont très mal documentées.
  • Emuler un vieux système revient à émuler une télé ^^. Dans le cas de la Gameboy, le hardware est étroitement lié au fonctionnement de l’écran LCD. Cet écran a des caractéristiques précises, il fonctionne comme un tube cathodique, en balayant les lignes de pixels. Chaque balayement a une durée précise, et suivant l’état de l’écran, le CPU a le droit de taper dans la mémoire graphique. Il faut donc coder un pseudo-écran LCD. J’ai regardé comment ca se passe ailleurs, notamment sur Atari, même combat, c’est assez lié au comportement d’une cathodique. Je pensais me retrouver face à des systèmes assez banals, avec un framebuffer et une indépendance de la sortie vidéo, mais non. C’était marrant.

Mais tout ca ne répond pas à la question initiale de ce billet. Quand on parle de développement d’émulateurs, c’est un peu comme le développement de jeux vidéo de façon générale. Il y a toujours pleins de kevins qui croient que avec 2 semaines de cours en BAC+1 on peut développer un MMORPG. Il faut commencer petit.

Bref, tout ca pour dire que je m’adresse uniquement aux personnes conscientes qu’on ne code pas un émulateur en ne voulant pas s’intéresser au bas niveau. Pour se lancer dans l’émulation, il est préférable d’avoir des bases d’architecture hardware, savoir un peu de comment on est arrivé de la logique booléenne à des processeurs. Loin d’être indispensable, mais préférable pour savoir où l’on va. Pour ces gens curieux, et qui veulent commencer doucement, il existe une “machine” à émuler. Il s’agit du Chip8. En fait, cette machine n’existe pas. C’est une machine virtuelle qui a été inventée dans le but de simplifier le développement de jeux dans les 70’s. Il y a une doc disponible sur son hardware virtuel, et la machine possède un jeu d’instructions très limité (une trentaine, contre les 512 de la GB par exemple), ce qui en fait un hardware de choix pour commencer à comprendre l’émulation. Il y a donc tout ce qu’il faut par ici pour bien débuter. Si la demande suit, je vous pondrai un tutoriel sur le développement d’un émulateur Chip8.

Mise à jour :

Suite à vos remarques sur la clareté de mon paragraphe sur le rom banking, voici quelques précisions sur la mémoire de la Gameboy.

Les images étant plus larges que 800px, il est préférable de lire cet article sur une seule colonne.

Une mémoire, ce sont des blocs de 1 octet (8 bits) qui sont tous numérotés. La Gameboy a un bus mémoire capable de voir 65536 blocs (autrement dit, 64ko).

blocks
Or, la Gameboy possède seulement 8ko de mémoire vive. A quoi servent le reste des 56ko ? Comme l’a souligné LeGreg dans les commentaires, le bus mémoire est de type “memory-mapped I/O”. Une partie est donc dédiée aux I/O (gamepad, port série, son, interruptions…), mais aussi à la RAM et à lire les cartouches de jeux (32ko de cet espace, divisé en deux parties de 16ko, est dédié à la lecture des cartouches). Le reste est grosso inutilisé (ou presque).

memorymap

Comme je l’ai expliqué, 99% des jeux Gameboy font plus de 32ko. Comment faire avec cette limitation hardware ? Il y a un mécanisme, qui est interne aux cartouches, et non à la GB : le Rom Banking. Le rom banking est géré par une puce à l’intérieur de chaques cartouches, le Memory Bank Controller (MBC). Son rôle est de montrer à la Gameboy uniquement 32ko de la ROM. La ROM est alors découpée en “bank” de 16ko (j’avais simplifié ce cas par des banks de 32ko dans mon article, ce qui est faux en fait). La bank 0 est toujours visible par la GB, afin d’avoir accès au programme principal en toutes circonstances. Par contre, la “bank n” est amovible, et c’est le MBC qui la pilote.

mbcMais comme la Gameboy n’est pas capable de gérer ça d’elle même, il faut pouvoir dire au MBC de montrer la bank que l’on souhaite. Le principe est alors d’écrire sur la cartouche (ROM), une opération illégale. Le MBC va alors intercepter cette écriture et l’empecher. A la place d’écrire, le MBC va comprendre par votre tentative illégale, que vous souhaitez voir une autre bank.

mbc21
Un bus mémoire de type memory-mapped I/O est quelque chose de tout à fait commun. Le rom banking également. Ce que j’avais trouvé bizarre, c’est que ceci n’est pas implémenté dans le hardware de la console elle même, mais dans les cartouches de jeux, via une puce dédiée (le MBC), et via le principe bizarre de “fausse écriture” (et du fait qu’il existe plein de versions de cette puce).
Je ne sais pas de quelle manière le rom banking est géré ailleurs, mais je m’attendais à quelque chose de plus propre en terme de design (comme un bête registre CPU). Après il se peut que ce soit comme ca partout et qu’il y ai une bonne raison à cela, mais je n’ai pas creusé la question.