README: The Sprite Decade

Présenter l'architecture des consoles, du gameboy à la XBOX ... rien de moins que ça. Voilà le contenu qui vous attend depuis 2020 si vous cliquez sur le lien "Copetti" dans la liste "blogs I watch" de cette page. Et oui, la Nintendo DS s'y retrouve ;)

C'est déjà quelque-chose, mais Rodrigo Copetti -- l'auteur du site -- n'en est pas resté là: il a commencé à rassembler ses articles pour nous proposer des version imprimées des bouquins... et j'ai donc craqué pour "The Sprite Decade" qui reprend les machines 8 et 16-bit de Nintendo et Sega auxquelles s'ajoutent la TurboGrafX (aka PC Engine) et la Neo Geo.

Bon, c'est vrai que pour la NES, j'ai déjà le bouquin de Nathan Altice: I AM ERROR, et la SuperNintendo est largement couverte par les vidéos de Retro Game Mechanics Explained. Mais les avoir un peu toutes sous la main, pouvoir retourner voir la vue d'ensemble sur les propriétés de l'une et l'autre ... c'est un bouquin bien pour moi. Bon, j'avoue, j'aurais probablement ajouté encore d'autres détails techniques parce que bah ... on ne se refait pas, mais c'est une bonne base. Une sorte de syllabus de cours sur lequel j'ai déjà commencé à prendre des notes pour me faire ma référence des consoles rétro.

Puis je dois bien l'avouer, il y a une autre raison qui m'a poussé à acheter ce livre: je voulais voir comment il rendait. Parce que je n'ai pas encore abandonné le rêve de convertir un jour tout ce texte en une version linéaire sur papier. Et bien, ça rend rudement bien. La prise en main est bonne, la qualité du papier nickel, un rien velours... Et Rodrigo a travaillé sans maison d'édition, un peu comme Jill Bearup (qui a du 18:6 entre le prix de vente de sa version Amazon paperback et ce qu'elle en retire)... ce qui pourrait peut-être intéresser M. Jared qui cherchait un éditeur/imprimeur pour son bouquin sur le homebrew sur Nintendo DS (justement). 

Un bémol, toutefois: pour offrir une taille maximale à certaines images, Rodrigo a décidé de les imprimer en format paysage ... sur un livre version portrait. Si ça permet effectivement d'avoir plus de détail sur les photos des circuits imprimés de chaque console, ça me semble discutable pour la photo de la NES dans sa boîte en plastique, et c'est franchement dommage pour les différents schémas d'interconnection entre les composants. Le texte est disponible aussi sous github, mais pas les images...

Bon, et non, je ne suis pas devenu fan d'Amazon pour autant. A vrai dire, j'ai même failli passer mon tour quand j'ai vu que le site me réclamait pas loin de 20€ de frais de port et douane pour un bouquin à moins de 30€ ... Puis vérification faites, Rodrigo Copetti nous écrit ça d'Ecosse ... donc en passant par Amazon.fr, mon édition est finalement imprimée en France et mes frais de port me sont offerts. Donc, force et courage aux camarades qui luttent pour des conditions de travail honnêtes dans les entrepôts. Des que je trouve un moyen de soutenir les chercheurs/rédacteurs sans contribuer à votre oppression, je pousse sans hésiter sur le bouton, m'sieurs dames. 

Silence, on tourne ...

 J'ai repris un tour de Harry Potter et les méthodes de la rationalité. Dès le 1er chapitre, j'avais envie de le faire connaître, mais les gens qui ont le temps de tourner les pages ne sont pas légion autour de moi. Par contre un audio book, ça a l'air plus commun. En particulier pour mon frangin.

Du coup, c'est logique que je lui chipe son enregistreur Zoom. Evidemment, il y a déjà des enregistrement de l'excellentissime version originale. Ici, je m'attaque à la traduction française, en réécrivant des p'tits bouts à gauche ou à droite pour avoir un rhytme qui me plaît mieux.

J'ai encore du chemin avant les Sparkling Unicorn Princess, mais on devrait voir débarquer Drago d'ici un week-end ou deux.

Lucky you, English speakers. Harry Potter and the Methods of Rationality reads so well. But for most of my family, reading a novel in English is far beyond their level. And well, there is a translation in French, but every here and there, you stumble upon some sentence that sounds awkward, or not like something someone would have said. The meaning is almost always preserved, but the rhythm is lost. Can I do better ?

(tout ça ne booste pas la vitesse de développement de Bilou's Dreamland, mais que voulez-vous: il faut maintenir son équilibre psychosophique aussi, non ? ;)

PS: pour le chapitre suivant, il faut obligatoirement que je prépare un faux-guru-meditation-screen sur le thème "Fundamental Attribution Error"

PPS: on dirait bien que hpmor est en 'creative common' ... ça va plaire à mon frangin, ça.

PPPS: la conversion en .mpeg marche moins bien pour ces derniers épisodes. 

ffmpeg -loop 1 -r 2 -i Downloads/hp-stairs.jpeg -i Documents/hpmor12.mp3 -c:v libx264 -preset medium -tune stillimage -crf 18 -c:a copy -shortest -movflags faststart -pix_fmt yuv420p hpmor12.mkv

Prince of Persia

J'avoue que quand j'ai vu "le making of de Prince of Persia" chez Third Editions juste avant Noël (dernier), je me suis dit que je n'avais pas besoin de chercher plus loin un cadeau pour mon frangin. Il m'avait avoué avoir aussi commandé quelque-chose pour moi chez eux, donc j'étais convaincu qu'on allait s'échanger le même bouquin au pied du sapin. Tellement convaincu que j'ai laissé le sien bien au chaud dans son emballage, histoire de ne pas gâcher le plaisir de la lecture *du mien*.

Sauf que non. J'ai eu quelque-chose d'autre. Et la lecture du making of aura attendu encore et encore, le livre continuant d'être sur la table de chevet de mon frère. Jusqu'à ce Noël ou j'ai réussi à le convaincre (nouvelles  BD à l'appui), qu'il parviendrait bien à s'en passer une semaine ou deux.

I know: I could have read Jordan Mechner's notebook years ago ... and I did read some snippets. But having it published in french meant that I could offer it to my brother: he's the collecting one in the family. I thought he would offer me a copy but it turned out he offered something else. So I had to wait until I could borrow him his gift ^^".

Deux ans après avoir numérisé les premières séquences vidéo où son frère court et saute, Jordan Merchner prend conscience qu'il manque quelque chose de fondamental dans son prototype de Prince of Persia: des objectifs.

La princesse à la fin du jeu n'est qu'un trophée. Il faut des récompenses dans le jeu comme battre un garde dans Karateka, attrapper une pac-gomme dans Pac Man ou compléter un niveau dans Lode Runner.

A ce moment-là, son jeu autorise l'exploration libre de grands niveaux (plus d'une 20aine d'écrans). Il n'y a pas encore de combats. Il n'y a pas moyen d'anticiper à quelle distance on est encore de la sortie du prochain niveau. Si on tombe dessus, on se dit "ah ok ? c'est la sortie, alors". Pour qu'il puisse y avoir sentiment de récompense, il faut que le joueur ait pu anticiper qu'il avait quelque-chose à réussir.

On peut se retenir pour la tâche suivante, attendre le bon moment avant de se dire "Ok. Maintenant!" et se plonger dans une période de tension plus forte, avec une grande chance d'avoir un contretemps ou un succès. Prince of Persia n'a rien de tout celà pour le moment (12/11/1988). Si le sous-objectif est de finir le niveau, il faut un indicateur visuel de où on en est.

Il faudra que je sois attentif à ce genre de chose dans Bilou. La bonne nouvelle, c'est que les bonus-à-ramasser donnent facilement des petits objectifs intermédiaires. Il se pourrait que ce qui ne m'a pas plus dans les collect-a-thons, c'est justement cet absence d'objectif (ou alors un objectif caché, du style "bon, il reste 8 Lums dans ce niveau. génial. Où est-ce qu'on achète une boussole à Lums ?)

#collect: at some point in 1988, Jordan Merchner realises that it is important in an action game that the player knows what are the next goals they're after. What is the next reward I can get (a power pellet ? completing a level ?), and how far am I to reach it? That was obvious in games like Lode Runner or Pac-man, and by that time, there was no such feedback in the Prince of Persia prototype (before he adds swords fight to the game). There cannot be satisfaction of reaching a goal if there is no way to anticipate the goal.

I'll have to be careful about that in Bilou, especially regarding the use of collectibles as a progress indication. It could be what made collect-a-thon uninspiring to me: okay, you got a feedback that you haven't found everything, but that's an incomplete feedback because it doesn't show you what the next objective is. It's like if pellets in pac-man were actually invisible. Same for the 'remaining Lums' in Rayman 2: I have no Lums compass to find them!

edit: okay. Bouquin fini. Bonne histoire, bonne lecture, mais il faut reconnaître un truc: Jordan ne s'est pas particulièrement étendu sur les aspects techniques du développement. Pas beaucoup plus sur les niveaux eux-même. Ce n'est pas si étonnant. Quand il bosse, il bosse. Il ne prend pas des notes sur "pourquoi on met une potion l et pas ici". Il prend des notes quand il rumine. Et pour tout ce qui est 'bon comment on va faire ça sur 8-bit', voyez plutôt le portage C64. (par contre, le code source est publiée sur github)

On y retrouve les schémas expliquant comment les graphismes sont découpés dans le bouquin, et deux ou trois autres trucs du genre, mais on ne s'y attarde pas. Pas de regrets, donc: c'est un bouquin taillé pour CJ et PYH plus que pour moi.

Bon, Jordan, si tu me lis un jour, je n'ai jamais vu PoP en magasin. J'y ai un peu joué en version MS-DOS, mais je n'ai jamais réussi à passer le 3eme ou le 4eme niveau. Mais t'as fait un super travail quand-même. Ton jeu reste un mètre étalon de la discipline. Et merci d'avoir publié tes carnets.

Je suis un n00b

J'ai découvert la guilde  NOOB de Fabien Fournier via twitter lors de l'appel à participer à leur levée de fonds pour créer un jeu vidéo. En soi un évènement assez banal, sauf que cette fois, les personnages du jeu étaient déjà connus depuis 6 saisons par les spectateurs de la Websérie - un concept qui, lui aussi, m'était inconnu. Intrigué, je lance l'intégrale de la saison 1, je regarde le présentation de Gaea qui crée son perso  avant de me souvenir que j'ai Une intervention prévue en salle des machines.

Quand je remonte, ma fée m'a chipé ma chaise de bureau et est en train de rigoler devant le Jack Céparou. c'est la période où on vient de changer de box, et le nouveau modèle permet de regarder des vidéos Youtube sur la télé. La guilde va donc se faire sa petite place au chaud dans nos soirées entre les Dr. Who et les épisodes de Castle. L'humour, la parodie et le second degré vont permettre de proposer un divertissement très réussi malgré un budget d'amateurs et les personnages bien croustillants, au juste équilibre entre réalisme et caricature nous auront définitivement convaincus.

Soyons clair: le jeu d'acteur de Gaëa, Omega Zell, Arthéon et Sparadrap est excellent. Le truc, c'est qu'ils n'ont pas à être crédible en tant qu'invocatrice ou assassin. Ils sont crédibles en tant que geeks qui incarnent des personnages. Et ça, ils le font superbement bien. Pareil pour les inévitables combats. Quand un JDG nous sort un épisode dans lequel il est supposé être CanardMan mais qu'il se bat plutôt comme léguman ... bin ... c'est mignon puis c'est tout.

Ici, plutôt que d'essayer de faire des combats de dingues à la Seigneur des Anneaux, la série joue sur le fait que c'est un combat dans un jeu vidéo. Oui, les coups sont ridiculement mous par moment et on tape dans le vide à d'autre, ce qui compte ce n'est pas le réalisme avec lequel l'acteur combat mais le petit '-200PV' (ou parfois '-2PV') qui accompagne pour nous envoyer un 'bin oui, on est dans un jeu! t'avais oublié?'

Quand ma fée est revenue de la bibliothèque avec le roman "La pierre des Âges (saison 1.5)", je savais déjà bien qu'il y avaient des 'produits-dérivés' de l'univers de Noob. Mais j'avoue qu'entre le graphisme pas franchement à mon goût de la BD, l'idée euh-ouais? de Néogicia et le fait que je ne suis pas un joueur de mmeuporgs, je ne m'étais pas précipité pour acheter les romans. Bin j'aurais peut-être bien dû. Parce que non, on ne verra pas Sparadrap faire l'andouille ni Omega Zell prendre la pose dans le roman, mais c'est toujours bien la même écriture et les même personnages. Fabien Fournier a réussi à choisir un style équilibré entre la narration classique, les dialogues comme-dans-la-série et les chapitres dans-la-tête-du-perso. Quand je lis les répliques, j'entends les voix de Sparadrap ou d'Arthéon dans ma tête. Je vois les grimaces de Gaëa qui cogite. J'aimerais entendre la voix de Zell, mais n'ayant pas l'acceng, c'est plus difficile.

En plus de ça, le "1.5" un peu troublant au départ prend tout son sens une fois la lecture entamée: chaque saison de la web-série démarre par une introduction en vitesse d'un nouveau contenu dans le jeu-qui-n'existe-pas Horizon. Au risque de voir le spectateur décontenancé par les références au sans-âmes, à la Pierre des âges, un nouveau continent, une nouvelle faction ou que sais-je encore. Les romans, eux, traitent justement du passage entre ces saisons, sur fond de quêtes-d'investigations, de rumeurs de forums et tutti quanti. Bien trouvé. Bref, j'ai accroché et ma fille a laissé de côté ses re-lectures de Harry Potter pour se plonger dedans (le "bin non les louloups, je ne vais pas vous mettre la saison 3 tant que *deline est occupée à lire le tome 2.5" n'y étant peut-être pas tout à fait étranger)
 

Retro Game Dev

My brother got me a copy of Derek Morris' book on C64 game development. It is more or less a printed tutorial to his studio-like application that features code editor, resource packer, Commodore emulator and C64 graphic editors. I haven't managed to run that in WINE so far, unfortunately, but reading the book was already quite interesting.

One nice thing is that the games discussed in the book are programmed in assembly language. So we can skip the usual PEEK and POKE things and start straight with the main meal. I'd love to be able to say that the libraries that come with the studio let you focus on your game logic without having to figure out how to pull joystick state and push tiles into graphics memory, but the reality is that it adds a layer of confusion instead of abstraction.

Things like Screen_SetColors or Sprite_SetFrame are understandable and generic enough, but the "particles system" using special background characters to emulate more sprites would have been nice to see discussed in the book. Same goes for a few more key algorithms like map update after something got picked up, played monster collision, and the like.

A défaut de la démoparty espérée pour mes 42 ans, mon frangin m'a dégotté un bouquin sur la programmation de jeux pour C64. Il faut dire qu'entre Wolfling, PowerGlove et Relentless, mon frangin avait eu le temps aussi de cogiter à une adaptation de Spector sur C64 (mais bon, lazycow a finalement remis le couvert avec le chapitre II de Wolfling). J'imagine que ça pourrait être un appel du pied.

Le côté intéressant, c'est que le bouquin ne s'embarasse pas des PEEK/POKE bien connus de ceux qui ont essayé d'aller plus loin que le PETSCII en BASIC: ici, on code en assembleur. Enfin ... d'une certaine façon.

A côté du bouquin, Derek Morris nous propose en effet un "studio" pour windows, avec éditeur de salles, de sprites, de tiles et compagnie et une série de bibliothèques de macros pour pouvoir commencer son petit titre sans devoir se farcir les détails techniques de la programmation hardware de la bête.

C'est sympathique (et plus gamejam-friendly), mais ça transforme aussi une grande partie de la lecture en une sorte de visite-guidée-faites-moi-confiance où ira rarement plus loin avec l'assembleur qu'une petite augmentation du score ou une bidouille de la vitesse, parce que le reste se situe généralement à l'intérieur d'une macro qui n'est pas reprise à l'écran. Pour celui qui est curieux de savoir comment les tirs, les collisions ou les mises à jour de maps sont gérées, bin il faudra ouvrir le .zip parce que ce ne sera pas dans les pages.

Ah, par contre, sorry frangin: la gestion des musiques de fond, c'est aussi réservé au tome 2.

It is also a bit disappointing that the "engine" is only capable of scrolling 1/3rd of the screen, and thus the "platformer" example looks more like a simplified Wonder Boy title than the Great Giane Sisters.

60-fps full-screen scrolling requires page-flipping and interrupts, says the last page. It's a starter kit, in a sense, not a PhD thesis on Wolfling-like guru techniques that would push the limits of the machine. Well, I guess starter kits are good to have too, aren't they?
Now ... maybe for game jams ...Yes, I think that could be a good setup for an 8-bit game jam. 

 

edit: j'étais étonné de voir des macros un peu dans tous les sens dans le bouquin, et en particulier des macros qui font des appels de fonction ... un tweet vient de me faire comprendre pourquoi: sur 6502, on va devoir se souvenir du "protocole" d'appel de chaque fonction, qui n'a rien à envier à celui des appels systèmes MS-DOS. Si on a pas envie de se souvenir "mets la destination dans X, la source dans Y et la longueur du bloc à copier dans l'accumulateur", on peut se faire une macro qui prendra 3 arguments "simples" (disons une constante ou un nom de variable) et qui prépare l'appel à la fonction block_copy. Ce sera plus flagrant encore si on doit accéder à un chip externe avec un protocole du style "écrit le numéro du registre vidéo à l'adresse $8000 puis la valeur en $8001. Recommence ensuite avec la coordonnée Y que tu mettras dans le registre vidéo suivant".

Par contre, suivant le conseil de Mario Nesrock, on garde ses macros dans les sources principales (on ne les planque pas dans un .zip) et on les garde courtes (sinon gare à la taille de sa ROM).

Gits'n'Hubs

NDS / GBA homebrews

 https://github.com/gbdev/awesome-gbadev

 https://github.com/relminator/Fuzed-Neo

https://github.com/dbeef/homebrew-links-ds

https://github.com/Asiern/SpriteNDS

https://github.com/devkitPro/devkitarm-rules

https://github.com/dbeef/spelunky-ds

https://github.com/melw/dicewars

Disassembly and Reverse Engineering

https://github.com/Dirbaio/nsmb-editor-ds

https://github.com/n64decomp/sm64

16-bit homebrew

https://github.com/MiSTer-devel/Main_MiSTer/wiki

https://github.com/BigEvilCorporation/LUMINARY

https://github.com/moon-watcher/cave-story-md

https://github.com/undisbeliever/untech-engine

https://github.com/optixx/snes

8-bit homebrew

https://github.com/Zal0/gbdk-2020

Stylux-related

https://github.com/Leszek111/ReLaunchX

https://github.com/ocornut/imgui

https://github.com/onyx-intl/boox-opensource

https://github.com/PypeBros/booxsdk

misc.

https://github.com/alpine9000/climbyskies

context: my new Boox can browse github contents, but I'm not sure I want to give it my github credentials. So here's the list of projects I've starred over the years, but wouldn't print and can't afford to check on-screen.

Thank you, Fabien

It's a true pleasure to keep reading the reports of Fabien Sanglard about the "polygons of Another World", one system after another. He went for people who did the ports, like a great investigator from Pix'n'Love would and mix those live coding moments with technical details about the various 16-bit architectures that make it quite exciting and pleasant to discover.

Of course, there's already a significant amount of things I have learnt about the bowels of Another World: because Eric Chahi himself documented them on his website. Like the language used for game logic, the development of the polygon modelisation tool and so on. That makes it (imho) perfectly for Fabien to focus on getting high-performance drawing primitives. But if you really want to, he covered the virtual machine source code back in 2011. 

For instance the episode about the homebrew GBA port finally allowed me to understand why the heck there were thumb-vs-ARM modes and IWRAM-vs-EWRAM and things alike in gba coding. With a simple diagram of how chips and busses were connected. That could definitely help if I was to port some Bilou games to the GBA later on (likely I'll take closer attention to make that possible with "Bilou Dream Land"). But I enjoyed the description of how the Amiga used its blitter to fill polygons quickly, too. and how the SNES version could have been running at 60 fps if the manager had said yes to a SuperFX chip on the cartridge.

Time-Turner

Just in case I wonder... nothing is happening here because I've discovered "Harry Potter and the Methods of Rationality" and it diverted me from virtually every other hobbies :-P

The colleague who pointed me to it (about 3 weeks ago)
will hereafter be known as 'Sparkling'. 

(and yes, there are HPMOR t-shirts around)

ngised emaG

C'est une pépite que je découvre et dévore grâce à Kirby Kid: le ""reverse design" de Super Mario World ... comprenez une analyse poussée d'un de mes jeux de plate-forme favoris, ce qui le rend unique par rapport aux Mario précédents (moins d'inertie au sol, physique des sauts simplifiée, etc.) et une quête pour la compréhension du niveau de difficulté et de son évolution au sein du jeu.

Thanks flies to Kirby Kid for re-tweeting something that made me discover The reverse-design of Super Mario World (a.k.a. debriefing a statistical analysis of the game's challenges based on Mario's jump). How high can you jump, and what do you need to get that high ? How large is the death zone (aka d-distance) of a specific jump ? what is the penalty for failing ? is the height difference making the jump simpler or harder ? and how large is the safe landing zone on the target platform ?

Je n'ai pour l'instant que la version "web" du document, mais qui étudie déjà fort numériquement les capacités de Mario dans le jeu, avec les hauteurs (4, 5, 6, N blocs) et longueur (5, 8, 12, N blocs) de saut et propose la notions de d-distance -- la distance horizontale que Mario doit franchir en sautant pour éviter un obstacle mortel -- en plus du différentiel de niveau entre la plate-forme de départ et celle d'arrivée... ou de la distance entre le premier ennemi sur la plate-forme et le bord de celle-ci. Des chiffres qu'il me tarde de comparer avec ceux de Bilou que j'avais décrypté après le play-testing de mes deux premiers niveaux (pour ajuster la difficulté du jeu, justement).

I remember collecting similar figures about my own games between the original two levels of School Rush and the more complete gameplay I have now. But the authors do not only focus on how the difficulty curve evolves over the game. They're also interested in how a gameplay element (e.g. rotating platform or torpedo launcher) can be simplified into its most elementary instance (the standard challenge), increased numerically according to their metrics (aka "expansion": denser ennemies, larger death-distance, etc.) or evolved into something different (where e.g. route planning is involved) that requires additional skills after the standard challenge is sufficiently mastered. They also point out that a challenge may often just be mutated -- that is, turned into something different but that isn't any harder by any metric we can think of. Just the same challenge, but without being annoyingly repetitive.

Les auteurs présentent de manière très juste Mario à la rencontre de l'action pure (atteindre des cibles) et de la plate-forme pure (passer par-dessus des trous). Son mouvement fétiche -- sauter sur les koopas -- combine en une seule mécanique les deux pilliers d'arcades sur lesquels il est construit. De tous les costumes du dernier épisode sur NES, Super Mario World ne retient que 2 power-up: celui qui tire Mario davantage vers l'action (la fleur) et celui qui améliore nos possibilités de manoeuvre en matière de "plate-forming" (la cape). Une dualité qu'on retrouve finalement aussi dans les power-ups de mon petit "School Rush".

La grille d'analyse qui nous est proposée s'ajuste aux "thèmes de gameplay", axés soit sur le timing ou la vitesse, et soit sur l'action ou la plate-forme. Sauter au bon moment, ce sont les plate-formes mobiles. Frapper au bon moment, ce sont les ennemis périodiques. Sauter pour aller vite, c'est le thème de la "conservation du moment cynétique" (pardon pour la lourdeur de traduction).

Based on the fact that Mario's gameplay is a mix between pure action (hitting targets) and pure platforming (mastering gravity to leap over pits), they propose a reading matrix to Mario World's challenges, depending on whether they're requiring timing skills (jump/fire at the right moment) or speed skills (keep jumping because platforms are falling, for instance). I'll need to read more of their examples on periodic ennemies and intercepts to accurately understand why they put one in either category ... I hope it will help me coming with good design for my climb-to-the-source-of-all-ink level ^_^./

Reste l'intercepteur, cet ennemi dont la trajectoire croise celle du saut le plus naturel pour aller d'un point A au point B et qui en module du coup significativement la complexité. Typiquement (mais pas uniquement) un koopa volant par-dessus un trou entre deux plate-formes... mais que j'ai du mal à associer à l'interaction "vitesse et action", personnellement.

A noter que "vitesse" ne signifie pas forcément "bouton de saut" et peut s'appliquer même dans un jeu comme Commander Keen: dès qu'il y a quelque chose qui nous oblige à rester en mouvement (comme des plate-formes qui tombent au bout d'un moment), on est du côté "vitesse" et pas du côté "précision/timing".

La guerre des Mascottes

Ça y est : j'ai enfin reçu mon tome 2 de l'Histoire de Mario. Chiffre de ventes à l'appui, William Audureau et Oscar Lemaire passent au tamis les années sabbatiques du plombier, à savoir la période de 1990 (lancement de Super Mario World) à Juin 1996 (fin du développement de Mario 64). Je dis "années sabbatiques" puisqu'entre les deux, les amateurs de fleurs de feu n'auront que Mario Land II à se mettre sous la dent.

C'est pourtant l'époque où tous vont tenter l'aventure de la plate-forme dans le sillage de celui qui tente de faire vaciller l'idole, à savoir Sonic (1991). Bien sûr, il y aura eu d'autres jeux de plate-forme avant et il y en aura d'autre après, mais durant cette période, ils représenteront le gros des ventes de jeu sur console.

Chose peu surprenante, c'est avec la sortie de Sonic que coïncidera l'envie de faire mon propre jeu de plate-forme avec d'abord Calimero de '91 à '93 puis avec Bilou sous Basic entre '94 et '96.

Pendant ce temps, à peu près tous les détenteurs de personnages enfantin forts vont cesser d'"ignorer" le jeu vidéo et attaquer le dangereux Mario sur son terrain : celui du jeu de plate-forme. Ce sera "castle of illusion" avec Mickey, "duck tales" puis les jeux Infogrames qui ratissent autant de personnages de bande-dessinée francophone que possible mais aussi le bestiaire de la bande à Bugs Bunny -- avec plus ou moins de succès. En réaction, les acteurs du jeu vidéo vont aussi miser gros sur les personnages d'animaux antropomorphiques ayant le potentiel de devenir des mascottes, comme le Mr. Nutz de Philippe Dessoly chez Ocean, la chauve-souris acrobatique chez Sun Soft et le controversé Bubsy chez Accolade (que je ne connaissais jusque là que sur PC pour ses simulateurs de course)... et bien d'autres encore qui n'auront atteint ni l'émission Luna Park ni les planches de Midam. Même les robots de combats spatiaux prennent des allures de braves mascottes et tentent de se faire passer pour des abeilles avec des noms comme "twinnbee".

Oh, well. There's been another book by William Audureau, joint by Oscar Lemaire, about years '91-'95 where platformer was the king of video games, and where it looked like everyone could come with a mascot-like hero that would be the next Sonic since Mario was Missing... So I've been reading and reading. And no code has progressed. More luck next week ?

De notre côtés de jeunes ados, on fait la chasse aux magazines, on rève à ce que peut bien être tel ou tel jeu avec un personnage plus ou moins probable. Il semble qu'il y ait un nouveau venu tous les trimestres. Dans quelques rares cas, on aura l'occasion de s'y essayer mais le monde du PC est tristement dépourvu de ce genre d'exotisme. Au mieux, ce sera James Pond II sur Amiga à la maxithèque, ou la surprise de découvrir Moktar reconverti en Titus the Fox. Ils ne sont pas tous des sonic-like tels que Zool, mais ils cherchent clairement à plaire au même public. Et il semble bien que le succès de Sonic décomplexe tous ceux qui hésitaient jusque là à faire des chat-tout-mignons comme personnages de jeu: il suffit de leur coller un élément vestimentaire de jeune, une attitude cool-et-frondeuse, et en avant. Sur micro, on le prendra avec une dose de dérision, et j'ajouterais bien "Super Frog" (PC, Amiga) à Jazz Jackrabbit & James Pond ... mais le plus souvent, on avait droit à un gros raté du genre "Skunny the Wild West".

Le tandem William-Oscar gratte donc derrière les couvertures de magazines et effectue un impressionnant travail pour rassembler les interviews, les mettre en contexte ... Car si l'un va titrer "la nouvelle mascotte de XXX", ce n'est pas nécessairement l'avis de la société qui l'aura publié, ni du studio qui l'aura créé. Et si les personnages humains (Commander Keen ? Duke Nukem ?) sont assez peu présent dans l'analyse, les "héros/mascottes" improbables tels que Plok ou Cool Spot eux, ne sont pas oubliés.

Il met aussi en perspective les travaux de l'équipe de Miyamoto -- qui n'est évidemment pas restée les bras croisés pendant 5 ans -- qui sans parvenir à donner un deuxième jeu où l'on saute vers des blocs-questions à la SuperNES va se frotter à toutes les technologies de pré-3D afin d'avoir le meilleur Mario 64 possible quand sera enfin prête la console 3D de nintendo.

Il y aura finalement peu de suites parmi les "héros fabriqués spécialement pour l'occasion" ... et aucun ne parviendra à survivre à l'environnement des 16-bits où il a vu le jour, que ce soit pour des raisons de fusion/acquisition/license, par incompatibilité technique entre la vue 3D et les mouvements du jeu de plate-forme, ou simplement parce que les artistes d'animations qui donnaient vie aux personnages se retrouvent privés de tout repère devant les logiciels de modélisations polygonales.

Vous l'aurez compris, même s'il y avait beaucoup moins de matière pour le game-designer-amateur que je suis, le livre m'a malgré tout tenu en haleine. Bon, évidemment, avec tout ça, le travail sur l'amélioration de SEDS et LEDS, mes éditeurs de jeu sous DS, n'ont pas beaucoup avancé ^^".

Nathan Am Error

I'm reading a book about the NES: "I AM ERROR" by Nathan Altice. I guess you're not surprised. After all, I've been reading Pix'n'Love take on Donkey Kong, "L'Histoire de Mario" and "the Playstation Revolution". But this book is published at MIT press, and written by someone who has a thesis in arts, not an engineer or a game reviewer.

Yet, he got deep into nitty-gritty details about how tiles are used to build the images produced by the PPU, and how game developers and Nintendo themselves tried and extended the features of the NES as competing micro-computers were trying to bridge the technological gap.

Quelque-part entre les chroniques de la saga Zelda et "la révolution playstation", je vais bientôt ranger un outsider: "I AM ERROR" par Nathan Altice. Outsider parce que ce livre-ci a été pensé comme un ouvrage de référence universitaire par un expert d'une faculté "arts & culture" qui va étudier en détail en quoi les limites de la NES ont influencé les gens qui ont créé dessus, leurs oeuvres et les gens qui ont découverts leurs oeuvres, un peu comme on pourrait écrire un livre sur la technique des pigments dans les peintures de la renaissance et l'impact que le changement de matériel pour les pinceaux a eu sur l'oeuvre de Léonard de Vinci. Ici, bien sûr, il sera plutôt question du nombre de couleurs et de tiles, des possibilités de scrolling puis des puces et astuces que les développeurs de jeu et de chez Nintendo ont utilisé pour faire des histoires toujours plus grandes, dans des environnements toujours plus vastes .

I found it pretty surprising that the first generation of NES game had to be soldered for either horizontal and vertical scrolling. Then, cartridge started to include chips that would allow to switch between the two, like with the custom "UNROM" in Mega Man and the official "MMC1" in subsequent Mega Man games. Of course, I already knew that some cartridges featured more than mere ROMs, be it only for the SuperFX in StarFox. But the NES mappers had more arcane things to do and were not that much advertised. And they came as a second choice, as the initial extension roadmap was the disk system and its video RAM where the PPU expected to find tiles and sprites ROM.

En découvrant les maps des jeux Capcom sur NES, j'avais déjà supposé que la console imposait le choix du sens de scrolling: horizontal ou vertical. J'étais loin d'imaginer que pour faire un jeu tel que Megaman qui alterne phase horizontale sur phase verticale, il aura fallu bricoler les cartouches et leur rajouter une puce de contrôle, parce que Super Mario Bros, par exemple, a soudé le choix d'un scrolling horizontal. Toutes ces puces -- les "mappers" -- sont bien plus fréquentes que le SuperFX de la superNES, mais pourtant il n'en a presque jamais fait mention. C'est un détail pour le joueur, presqu'un secret de fabrication. Un secret peu avouable pour les développeurs qui avaient au départ misé sur le "famicom disk system" qui remplaçait la ROM graphique de la cartouche par une RAM remplie à partir du contenu d'une diskette. Pourtant, c'est bien en ajoutant une puce de RAM que Super Mario 3 est capable de retenir quels blocs ont été cassés (la NES n'ayant que 2KB!, à peine de quoi retenir le contenu de 8 écrans).

Still, if you think about it, Super Mario Bros. was already using the full range of pixels that the PPU could use. Embedding more graphics in the game is useless without a technique that could change which 16KiB slice was used. I suspected such techniques existed by 1998 when I first saw nesticle's video "pattern table" window contents updating as SMB3 played out. Those techniques are reminiscent of memory-paging techniques already in use on mainframes by then, but I was far from imagining the level of sophistications those chips could have, having different page sizes depending on the game's need regarding animation or environment diversity, ultimately embedding even additional sound chips and ways to offer real free, 4-direction scrolling.

Ce n'est qu'à travers ce genre de ruse -- pagination pour passer de l'overworld de Zelda à un des donjons, copie à la volée de sprites présents dans la ROM-programme vers la nouvelle RAM auquel le processeur graphique (PPU) a accès -- que les développeurs NES vont pouvoir faire mieux et plus riche que Super Mario Bros, qui saturait déjà les 16KB de mémoire que le PPU sait utiliser. Ici aussi, j'avais soupçonné ce genre de technique en voyant tourner SMB3 dans Nesticle, mais j'étais loin de me douter de la diversité des approches, des subtilités ajoutant des nouveaux systèmes d'interruptions sur une ligne précise de l'écran (devenue partie intégrante des designs de Nintendo depuis la SNES) ou l'intégration d'une puce sonore additionnelle que la NES utilisera comme elle aurait utilisé "l'entrée micro" du 2eme contrôleur de la Famicom.

En revanche, "comment on fait tenir un niveau sur 100 bytes" restera une curiosité dans ce livre. Dommage pour moi. Heureusement - j'imagine - pour la majorité des étudiants qui commandent le livre sur MIT Press...

I'm just slightly disappointed that "how SMB level were packed to a mere hundred of bytes" is the sole sequence that reveal how NES games were created with such a level of detail. I might have to dig for Megaman disassemblies ...

See you, bloggers.

With dev-scene.com dropped, dev-fr crashed, google reader turned off and the DS celebrating its 10 years, my RSS feeds list has shrunk to the point it is no longer worth checking. I wished to thanks their author for the nice ideas shared between 2005 and 2012 (mostly).

J'ai beaucoup aimé les années blog, que je situeraient de 2005 à 2010. J'ai beaucoup aimé l'ambiance bon enfant de dev-fr jusqu'à ce que l'engouement pour les iPhones ne le dépeuple et qu'un Androïd ne lui donne le coup de grâce. Je suivais les développement des uns et des autres via Google Reader grâce à la magie des RSS. Je laissais des commentaires et j'en recevais quelques-uns en retour. Tout celà est loin maintenant. Les blogs sont au mieux alimentés d'un "je ne suis pas mort" annuel. Au pire, leur adresse a été vampirisée par un quelconque annonceur sans scrupule. Petit message de sympathie à mes correspondants de l'époque.

0xtob is the author of NTXM library and nitrotracker for Nintendo DS. I owe him a lot -- including a patch featuring my upgrades to his player. His work has now moved to code.google.com. His blog is gone, his homepage is still there.

Je commence par 0xtob, à qui je dois la base du son dans mes homebrew. Je lui dois d'ailleurs toujours un rétro-portage de mon code pour les effets (vibrato, etc) dans sa nouvelle architecture... Le blog est mort. La page d'accueil lui a survécu. Le code aussi. J'aurais dû regarder de plus près à son moteur physique, peut-être ?


Squidi had the Grand project of describing 300 game mechanics. One a day, iirc. He went quite far away, around 160 mechanics, and even started implementing examples in HTML5. I think the archive.org is the only way to consult content he wrote.

Il n'y avait pas que des homebrew dans mes flux RSS, mais aussi les nouvelles idées très chouette de règles de jeu. Il s'était fixé l'objectif de 300 règles, il est arrivé au résultat très honorable de 160. Bien mieux que le catalogue des Jeux Vidéos Obsolètes.

Sverx doesn't post much anymore, but he's still into homebrewing. Mostly moved to SEGA mastersystem tools/libraries and posting code on github.

Les petits jeux de Sverx étaient bien agréables. Ses conseils de baroudeur des consoles Nintendo Précieux. Il est maintenant passé à une bibliothèque pour la Master System de SEGA. Github semble être suffisant par rapport à un blog puisqu'il n'y met plus qu'un bonjour par an.

J'adorais les mini-jeux de Mia. Lui a continué à blogger de temps en temps, et son blog est toujours actif. Comme de nombreux homebrewers' Mia est passé au jeux Androïd, mais malheureusement avec de "simples" jeux de cartes. Peut-être celà représente-t'il un vieux challenge à vaincre pour lui ?

Last but not least, I'd like to greet Mia and thank him for his inspiring little games on Nintendo DS. He switched to Androïd, like many other french homebrewers. It's a bit of a pity that he decided to make only plain card games. I know he used to rip nintendo graphics because he had no own characters for his games. Maybe that's still missing for him ? Maybe he doesn't know about Open Game Art ?

And then, there are those who haven't gave up. I'm impressed at how Smealum (previously releasing Aperture Science for DS and the first DS minecraft clone) makes progress towards a full understanding of the 3DS, and it looks like there is now a growing community of 3DS software homebrewers, reaching the state where a clone-of-moonshell is being crafted. So far, what I want to do fits the NDS alone, I haven't found any way to push homebrew to my own DS (I'm often lacking the game to exploit) nor did I started investigating what others have done / found on that newer hardware,  but maybe that would be the best way to quit that feeling of being a lomesone cowboy lost in the deserts of NDS homebrew...

Oh ... et pendant ce temps-là, Zalo nous sort quelques tutoriels 3DS et une reprise de Jumping Jack sur son blog ^_^

Reading: Ken Kutagari.

Avec le recul, ça pourrait être mon "life-changing book: 4/3". Une lecture très enrichissante qui dépasse la simple annecdote de playhistoire pour nous donner une idée assez précise des enjeux de la conception d'un équippement électronique de pointe. Complexité d'approvisionnements, choix marketting, ... comment le fait d'utiliser moins de robots pour placer les puces sur la carte-mère est la meilleure option pour baisser les coûts (et enterrer la Saturn de SEGA). De quoi quitter un moment l'artisanat du homebrew pour découvrir "le vrai monde" de la production électronique de masse, parce qu'en électronique, si on a pas la masse, on y est.

Another Great Read at Pix'n'Love editions, but this time, you too, English-readers, can enjoy it, and not only the French-Folks. Because Reiji Asukara wrote it in English under the title "Revolutionaries at Sony", published by Mac-GrawHill, obviously. It goes well beyond telling the tale of Nintendo and Sony teaming up, then splitting, then fighting to death. It gives you a complete overview of how a technical tour de force has been converted into a successful mass-market product. Retrospectively, I realise that everytime I have to understand why some idea to hack around some existing hardware to extend functionalities cannot be integrated into a finished product, I end up mapping the situation to one of the key decisions of Ken Kutagari in the PlayStation design story.

Le côté technique est malgré tout un peu léger. J'aurais aimé voir en vis-à-vis le schéma général de la PS1, voire l'organigramme de son CPU/GPU basé sur le System G... Pour ça, il me faudra faire l'étude du "psx-tek" comme j'ai étudié les DS-tek et GBA-tek, encore qu'il est probable que je laisse ça à mon ancien étudiant qui avait réussi à s'acheter une "Net Yaroze" d'occasion... Peut-être que Ce que vous avez toujours voulu savoir sur la Playstation (par Joshua Walker)
.txt donnerait quelques raccourcis, celà dit.

I would have loved the book to go a little bit more into the technical details, though. It is nice to have this discourse over the hardware evolving towards lower manufacturing costs and how it was decisive in the race against the Sega Saturn. It would have been much better to show together the motherboard layouts over the evolution. The book kind of assume that you've teared down a PSX already or that you don't want to depict the chips in your mind when it tells about it.

There's very little being said about the actual engineering of the GPU, the component that made the PSX so unique. Because it is architectured along the (now classic) model of a command FIFO and hiding the video memory from the CPU altogether, even showing the register map do not reveal a single detail about how things are structured to make the rendition of 360,000 polygons per frame possible for the first time except two words: massively parallel. There's not a single example of what "the framework" that PSX developers had to use. For the first time, afaik, a gaming console was made using a CPU that had a "kernel mode" and a "user mode", unlike microcomputers-derived CPUs in NES-SMS-Genesis-SNES. I'm left guessing the kind of functions / construction blocks might be in there, but it shed light about misunderstandings concerning the "BIOS" of the playstation line of products: magazines may have messed up BIOS, kernel and framework countless times.

Je comprends néanmoins qu'une grande partie de ce qui était présenté à l'époque comme le "BIOS" de la PS2 (pour faire bouger les cheveux) était sans doute plutôt un composant du "framework", cet ensemble de fonctions toujours grandissant mis à la disposition des développeurs de jeu pour qu'il puissent se concentrer sur leur développement. Pas uniquement des bouts de code présent sur tous les systèmes ni même des bouts de code destinés à être embarqués sur CD, mais aussi les outils de développement qui vont avec ... peut-être p.ex. un encodeur vidéo pour 3DSmax qui utiliseraient au mieux le décodeur vidéo hardware présent sur la console.

NB: je n'ai jamais eu de Playstation ni cherché à en avoir une. Aucun des jeux que mon frangin me montrera sur la sienne (après Y2K) ne me convaincront. Seul m'aura plus Rayman, que j'ai eu en version PC (, avec un pad plus capricieux mais mieux adapté à mon historique de jeu.

The Ultimate Scrolling Analysis.

Huge thanks to Itay Keren for having written his essay that creates a clear nomenclature of camera techniques in (mostly) platformer games, ranging from Pac-land's position locking to Mario's platform snapping to linear interpolation and beyond.

Grâce au développeurs de Frogatto, j'ai pu découvrir l'existence d'un excellent article sur le scrolling des jeux de plate-forme publié il y a quelques jours sur Gamasutra. Eh oui. C'est ça, l'après Google Reader. Je ne vais pas repasser en revue toutes les techniques qu'il présente, du premier platformer à nos jours -- pour ça, il y a l'article d'origine, mais j'en profite pour mettre à jours mes propres références.

Lerp in action. (C) Itay Keren.

Back then, when I started researching how to move Bilou's camera, my colleague Cyril suggested "an elastic string that would draw back the camera to Bilou's position". One close match is Donkey Kong Country's linear interpolation technique. It still has some "wobbly" effect but much less nausea-inducing than when you lock to the player's position. But this is far from being the only camera mechanic in DK games. Anyone who played the game has noted that some areas of the level are apparently "scripted" with cameras behaviour and that entering some hitbox may suddenly allow the camera to move past some artificial barrier, revealing a hidden area. More subtly, this can also be used to enforce "bottom-locking" in some part of the level, or change the horizontal tracking to the type of gameplay (rush, explore, climb...) of a specific area.

Commençons par une technique que j'avais laissé sur le côté quand elle m'avait été proposée par Cyril -- une "sorte d'élastique qui ramènerait la caméra vers Bilou" -- que j'avais tenté d'implémenter avec le code de poursuite des BerryBats. J'aurais mieux fait de procéder comme dans Donkey Kong Country avec une "interpolation" linéaire qui déplace la caméra d'autant plus vite qu'elle se trouve loin de son point de destination.

When I tried myself to analyze the horizontal scrolling of Super Mario Bros, I thought that there was two 'push-the-screen' positions, depending of the speed at which Mario moves. The reality is a bit different.

two triggers in SMB. (C) Itay Keren.

There is indeed two trigger positions, one -- walking barrier -- that forbids Mario from entering the rightmost part of the screen, and a second that smooths camera movement when Mario starts running. The "early-scroll" trigger doesn't try to keep Mario at its left, though, so he eventually "escapes" to the walking barrier.

Passons ensuite à SMB1, avec son interdiction de revenir en arrière. Ici pas de soucis pour faire demi-tour, mais Miyamoto a quand même pensé à nos jeunes estomacs et a ajouté un démarreur de caméra deux blocs avant la position 'naturelle' de Mario. On y gagne pas pour autant en visibilité pendant la course comme je le pensais au départ, mais on évite un départ trop brusque de la caméra si on revient en courant.

This is what smooth out the movement of the camera by reducing the instan(aus)eous acceleration of the image. I'd be tempted to say screen will move at walking speed until the real barrier is hit. I guess with more CPU cycles and memory, miyamoto's team could have even tried to linearly over time in that region rather than having two-steps, but I doubt most of us would notice the difference, so it's not bad to keep it simple. But no, you don't really have more headroom when running in SMB.

Finally, Itay's model of Super Mario World's camera nicely complement the video document I already found (and not yet re-blogged so far). The camera here clearly has multiple mode, that Shaun categorizes as "platform-snap", "bottom-locked" or "free-moving". I tried and mapped these as an UML state machine, but it lacks one component: the fact that in some levels/parts of the level, some transitions are forbidden -- e.g. in some levels, you will not enter platform-snap and stay bottom-locked.

Les différents mode de suivi vertical de Super Mario World, j'avais déjà étudié par l'entremise de Shaun. Le code est assez sophistiqué pour mériter une machine d'état à lui tout seul. En plus de ça, certaines transitions sont interdites dans certains (morceaux de) niveaux, forçant par exemple la caméra à rester au niveau du sol à moins que Mario ne s'envole dans les niveaux plats. 

What Itay adds to that, is a clear illustration that the camera in SMW has a direction state of its own (moving leftwards or moving rightwards) distinct from Mario's movement. In each direction, there is one barrier that will make you push the screen if you try to go past it, and a trigger that will switch to the other mode if you touch it. When the camera is "heading right", the two yellow lines are active -- Mario is confined within 2 blocks. As soon you hit the dashed line while turning back, the camera switches to "cyan mode", and then you have the screen adapting as quickly as the camera's max speed tolerates because you're about 64 pixels away from the push barrier for that direction (still picture shows a point in time where such catch-back occurs).

L'analyse de Itay est plus précise en ce qui concerne le scrolling horizontale. Il illustre parfaitement le mécanisme des deux "poussoirs horizontaux" décentrés (un pour chaque direction de caméra) et les déclencheurs qui forcent la caméra à changer de direction quand Mario a fait demi-tour de plus de 2 blocs. Il semblerait qu'on ait ici aussi utilisé une "interpolation linéaire" pour adoucir le mouvement de la caméra quand elle atteint à nouveau la position de Mario.

With this scheme, the player always have at least 1/3rd of the screen in the direction he face and half-a-screen-plus-one-block in most of the cases. That works quite well with exploration games like Commander Keen, imho.


If you're doing game design in some way, I strongly recommend you to spend some of your "research points" reading Scroll back : the Theory and Practice of Cameras in Side Scrollers.

Life-changing books [3/3]

1998. Bilou devient la cerise sur le gateau du projet "Ultimate Game Maker". Pour le réaliser, j'ai attaqué très sérieusement la lecture des documents (et les sources) de TRAN sur le mode protégé du 80386, les moyens de passer en mode "unreal" (code 16 bits avec données 32 bits) et ce genre de choses en ligne droite de la démoscène PC.

Many game development studios faced a hard time switching to 2D to 3D at the end of the 90's. Things were quite troublesome for my little self too. I had at last access to massive knowledge about VESA, sound cards and newer tools such as DJGPP compiler and early mikmod player source code ... but it was clear 320x200 MS-DOS games were gone for good. My quest for an improved Game-Maker software turned into a quest for a better operating system to run both game engines and game development tools. Filesystems that would make sharing of samples across a large bank of tracked songs trivial, etc. The cornerstone book for that shift is Andrew Tanenbaum's book on operating system, found somewhere in the university's library, and it will stay at my home, studied dailynightly as the Clicker 32 operating system project shaped up.

Je tombe ensuite sur un bouquin à la bibliothèque universitaire qui présente les structures de système d'exploitations avec environ 2 ans d'avance sur la matière dans mon cursus. Pendant à peu près 8 mois, le bouquin sera emprunté presqu'en permanence, et je remplis des carnets entiers de notes de lectures, d'idées pour aller au-delà des techniques habituelles avec l'idée de construire un système idéal où les politiques de gestion de mémoire et de temps CPU peuvent être échangées en temps réel (comprenez, lors du démarrage ou de l'arrêt de Bilou pour revenir au game maker).

Je vais ensuite tomber sur une description assez détaillées de Linux pour me permettre de définir les objectifs avec assez de précision, et identifier les aspects originaux de mon propre design. Un grand nombre des idées de base visent à donner une sensation de programmation Amiga sur une plate-forme multi-threads x86, avec les pilotes de périphériques vus comme des sortes de co-processeurs. Cette quête va m'occuper l'esprit jusqu'à mon travail de fin d'études et au-delà.

A second book, detailing the internals of the Linux system further refined what I did not wanted to have. Like a monolithic system, purely based on function calls. I wanted to give the programmer in the Clicker operating system the feeling to work on a virtual Amiga-like platform, with programmable co-processors for virtual memory, sound mixing and window compositing tasks, where you could hot-swap the process scheduler.

All this started 100% assembly, but that project taught me to use the C language for what it is and to avoid assembly whenever possible. The reason was you are too much bound to what you write. Do you realize there's a mistake in your algorithm ? you'll be to go through registers allocation planning and pipeline optimization once again.

Le projet Clicker sera aussi celui qui me fera lâcher l'assembleur pour chercher à comprendre le véritable fonctionnement du langage C grâce au bouquin de Kernighan & Ritchie. Les algorithmes utilisés pour la gestion de la mémoire deviennent tout simplement trop sophistiqués pour rester écrits en assembleur. Corriger une erreur de conception dans un code de recherche "best fit avec back-tracking" revient à reprendre le design d'une page blanche, re-réfléchir à l'affectation des registres et revoir tous les efforts destinés à assurer un comportement optimal sur le double pipeline du Pentium. C'est tout simplement intenable.

Programmation GBA dans Login 92

 J'aimais vraiment bien le magazine Login:, bien plus riche que tous les Linux Mag' sur lesquels j'ai pu mettre la main. Romain Guy y signera une série d'articles, sur la programmation GBA début 2002. Un an trop tard pour moi, malheureusement: je suis à fond dans la construction de Clicker avec une demi-douzaine de collaborateurs potentiels, et en passe de devenir modérateur sur le forum Mega-Tokyo.

We never had a great collection of programming magazines in Belgium, unless you read German fluently and live in the eastern cities, I mean. But in the later years of my university studies, I had a stable dealer of "Login:" (and earlier Dream) magazine, covering a wide variety of open source, coding, and chip vendors news. I thought the blog would be a nice place to write a tribute post to Romain Guy's work, for instance his series about homebrew GBA programming. That arrived one year after I considered the option of re-creating Bilou's Adventure on that platform, and after we received a cold reply from Nintendo explaining their requirements for allowing a company to get an SDK.

Beside the relative complexity of the GBA platform -- where you had to manually decide whether to use Thumb instructions, and with very small RAM for code and data with the need to decide which part of your code would migrate from ROM to RAM to meet real-time constraints -- homebrew hardware was still quite repellent, with cartridges having internal flash, rather than using standard media cards, and requiring dedicated programming devices ... I dropped the idea and pursued my research on Operating Systems instead ...

Il y a aussi le côté "lourd" des équippements nécessaires pour programmer les cartes. La miniaturisation de la SuperCard n'a pas encore été atteinte ... ou peut-être les carte SD n'étaient elles pas encore assez répandues. Toujours est-il qu'on se retrouvera avec une cartouche unique, avec une certaine quantité de mémoire flash embarquée et une espèce de périphérique dédié à connecter sur PC pour réécrire le contenu de la mémoire embarquée. Mais tout ça est gros. Pas aussi lourd que la version "on sort un cable ATA pour se repiquer sur un micro disque dur clipsé sous la console", mais le côté "console portable" disparaît.

L'histoire de Rayman

*deline, très fière, vous présente le nouveau livre de Rayman.

Très chouette ouvrage de Michaël Guarné que nous offrent là les éditions Pix'n'Love. Plus aéré et aussi plus détaché que l'histoire de Mario mais quand heureusement plus consistant que le trop graphique "histoire de Sonic", je ne regrette pas ma pré-commande. Bien sûr pour celui qui avait déjà la bio de Michel Ancel et le mook contenant le dossier Rayman, il y aura des redites, mais l'intervention de nouveaux collaborateurs -- chose rendue possible puisqu'on s'intéresse ici à une série, donc avec les anciens épisodes vus sous différents angles.

Mais il y a tout de même quelques belles perles pour l'amateur de game design que je suis, à commencer par une double page dédiée à la "bible du game design", ce cahier graphique de Michel Ancel rédigé dans l'idée de faire passer son jeu au mieux auprès des frères à la tête de Ubisoft. Ça me rappelle très fort le genre de documents que mon frangin plaquait sur ma table à dessin entre '93 et '94, avant qu'on ne mette la main sur notre game-maker.

"Mario Can't Grab" (Kirby Kid)

J'ai halluciné en découvrant le nombre de 15,000 caractères de code pour le comportement de Rayman dans Rayman Origins. S'il y a une bonne dose de mouvements dans ce jeu, on est quand-même pas dans un jeu d'échec non plus... Puis je suis retombé sur une petite image de Kirby Kid à propos de Super Mario Bros. Ici, pas de roulé-boulé ni de wall-kick, mais on retrouve déjà la petite différence entre un jeu qui a été discuté entre testeurs et joueurs ou un jeu fait "en aveugle": si un petit coup d'anti-gravité permet de continuer un mouvement plus à même d'aider le joueur, alors on donne cette anti-gravité.

Pacman Dossier

Je suis tombé sur le document de Pittman "the Pacman Dossier" un peu par hasard, attiré par une illustration qui promettait d'expliquer "comment Pacman peut contourner les coins plutôt que de devoir passer super-précisément... or c'est justement un des défaut de mon moteur de jeu pour l'instant. Mario "contourne" un bloc-question quand il est au bord, Bilou en serait incapable.

English readers, rejoice: you don't have a translation of Pix'n'Love's mook on Pacman (and many others, but Pacman's paper was clearly the best of the mook, imho), but (assuming that you're into game design) you have access to the top-level "Pacman Dossier" by J. Pittman, where game-beating techniques are explained, inpsiration is revealed and behaviour/personality of ghosts is decrypted.

Oh, and make sure you don't miss RetroGameMechEx's video on the topic. The same information as in the dossier, but it sure helps to see the targets, distances and all rendered as a live overlay while you're being explained what is going on.

Le dossier équivalent dans Pix'n'Love m'avait pas mal plu, en particulier parce qu'il présentait comment des constructions simples avaient permis aux développeurs d'avoir des fantômes qui ont "une personnalité". J'ai été assez surpris de constater, en revanche, que les explications diffèrent, notamment en ce qui concerne Pinky et Clyde. La version de Pittman est corroborée par d'autres analyses, dont un désassemblage du code de Pinky, ce qui jette un voile de suspicion sur le travail d'investigation de la PnL Team, même si leur public-cible était clairement différent que celui de Pittman.

Edit:  https://nitter.net/pypebros/status/1275177777868800002 / https://shaunlebron.github.io/pacman-mazegen/ -- how one can craft Pacman-like mazes while playing TETRIS...