dimanche, octobre 30, 2011

PoP C64 2011

Prenez un succès incontournable du jeu vidéo des années '90 (allez, 1989): Prince of Persia. Prenez un briscard de la programmation sur une machine mythique et merveilleuse: MrSid et son C64. Arriva ce qui devait arriver: après la SNES, le PC, l'Amiga, les téléphones Java et l'iPod et la calculatrice HP48, le titre à succès de l'Apple II arrive sur Commodore 64.

Au départ, je pense à une ancienne version qui aurait refait surface, mais non: MrSid refait bel et bien le jeu entre 2008 et 2011 -- chacun son hobby. L'Apple II et le C64 tournent avec le même processeur, le MOS 6502. C'est énorme. Ca signifie qu'en prenant simplement le "binaire" de PoP sur Apple II, une partie du jeu "tournerait" directement sur C64 ... toute la "logique" du jeu, en fait. Les mécanismes graphiques et sonores des deux machines sont totalement différentes, en revanche. Et à relire pour la 3eme fois le peu d'information que je trouve sur le graphisme de l'Apple II, j'aime autant dire que cette différence est importante. La machine de Steve Wozniak travaille essentiellement avec un gros 'framebuffer' (une image bitmap unique, remise à jour à chaque étape du jeu) alors que le C64 a un hardware inspiré des consoles et machine d'arcade de l'époque: caractères reprogrammables et sprites hardware. Le moteur de rendu devra donc être intégralement refait.

Well, if you read English, you can simply head to MrSid's post "Why would anyone want to port Prince of Persia on the C64". I guess he'll explain his reasons and give you crunchy details and videos much better than I could ever do ;)

La tâche à laquelle MrSid s'attelle donc, c'est de reprendre le binaire de la version Apple II, le désassembler et le cartographier. Il s'est évidemment mis en chasse du code source d'origine, qui a été perdu corps et bien ... eh oui, on travaillait sur floppy à l'époque >_<. Ce qui a survécu, en revanche, et que MrSid exploite au maximum, c'est la "documentation" du jeu. Quelques schémas qui expliquent les grandes lignes du moteur graphique, la liste des animations, l'organisation en mémoire des objets, leur position, les animations, et tout ça. Ca fait toute la différence! Au milieu de l'inconnu, il y a maintenant des points de repère qui permettent de comprendre le code parfois curieux de Jordan Mechner. Code-trampoline, liste d'instructions ... Si tout ça vous parle, ne vous en tenez pas à ce que je vous raconte: allez lire le blog dans lequel MrSid raconte en détail sa réalisation étape par étape... vidéos à l'appui.

Au fait, MrSid, c'était aussi le portage de Giana Sister (version C64) et International Karate sur DS. ^_^

(pour le blog Commodore Users Charleroi

samedi, octobre 29, 2011

Vieux Bouquins


Selon Helm, il faut que je retravaille mes "vieux bouquins" ... il est peut-être donc temps que je mette en ligne mes images de références trouvées sur flickr, histoire de les avoir plus facilement sous les yeux. (Encore que, en principe, je les avais imprimées :P)

These should be my references for drawing old books in pixel art.

mardi, octobre 25, 2011

Colour Balance ...

J'essaie d'ajuster un peu les couleurs des différents éléments de la "school zone" histoire d'avoir quelque-chose de plus harmonieux que les derniers mock-ups. La difficulté, avec les bruns et les verts, c'est que le moindre faux-pas casse tout. Je suis assez content des teintes sur la gauche de l'image (gimp-power), mais le hic, c'est évidemment que la DS a moins de souplesse de ce côté-là: 5 bits par couleur au lieu de 8, on se retrouve vite avec un écart trop grand ou trop petit entre deux couleurs si on se contente d'essayer de réappliquer les valeurs HSV de l'un à l'autre.

Not so easy to make sure that the different objects fit together well, esp. when lights and colours come into the game. On your left, binders and small wooden blocks with Gimp-revamped colours. On your right, books and larger wood block as they exist right now on the DS. I'd love to have the wood blocks use the same colour, but unfortunately, it turns out that the RGB values fined-tuned in Gimp do not fit the 5-bit-per-color-channel constraint of the DS hardware. Whatever "brainless" conversion I try to apply inevitably ends up with exagerated contrast here or flattened colours there.

I guess I'll have to do something similar to the process through which I revised the green zone's dust background: bring in the desired background colour and some misc. objects, finetune colours on the DS and then rework my rasters accordingly. It's just a pity that SEDS does not provide a way to visualise which colour of the palette is where (on tiles) in palette edition mode >_<


Et pour ne pas changer, il me manque le "petit plus" pour faire des essais facilement avec SEDS, à savoir visualiser dans l'image une couleur choisie sur la palette... Quand j'aurai ajusté ça, il faudra aussi que règle les vieux bugs de mon Level Editor, parce que si pour les maps simples d'Apple Assault, j'avais pu "faire avec", là, c'est un peu la catastrophe. Dès que j'essaie de définir un objet comme solide, j'ai une chance sur deux d'en effacer un autre >_<

Puis il faudra que je permette d'ajuster le niveau de zoom du frame editor d'AnimEDS pour pouvoir travailler sur Bilou, dumblador et les autres qui se sente un peu perdu dans un cadre de 64x64 :P Et puis permettre à SEDS et LEDS d'utiliser les palettes alternatives de la DS, histoire de varier un peu les couleurs des livres sans faire exploser le nombre de tiles pour autant.

edit: it's been 3 evenings I spend trying to adjust colours on the DS, where everything looks "just fine" when viewed at the proper angle. If I really want homogeneity in art, woudln't that be wise to first check that my FG is harmonious against existing background ... like the one of the green zone ? ... imho, it works fairly well, regardless of the actual "tint" of that background. Don't you think ? Now, all I need to do is draw some books and school stuff with those tints :P

lundi, octobre 24, 2011

Playing Diamond Hollow

A nice chippy music, simple graphics that reminds me of (good) DOS sharewares and nice level design, Diamond Hollow could be a dynamic game created with RSD game-maker if it wasn't for the sophisticated, immediately available weapon upgrade system. You collect diamonds in caves and fight blobs, spiders and some undefined creatures. That's fairly classical, but in video game like in cinema, there are some classics that can't be made wrong.

One thing that really puzzles me is the control system. Am I supposed to control the player with keys and space bar with one hand and aim my fire with the mouse ? That's fair enough in level 1 and 2 with relatively stubborn monsters that don't really attack me and the "autofire" power up. There is no timer in the game (i.e. power up dropped by monsters are permanent: you've got as much time to gather them as you want), so I can just stop in a safe position, move the mouse with the touchpad (yeah, laptop here), and then jump around to shoot the monsters. Leaving the "mouse" untouched means I'll always fire towards the same absolute X position (moving left/right won't change my target) and the same relative Y position (jumping makes change my target). Sure, the game designer wanted that feature and freedom very hard, but allow me to be brutally honest: it's useless. 4-directions firing would have been largely enough, and it would likely have involved the player much more by intense action when risk must be taken rather than doing precision adjustment to shoot plain blobs. When controls are awkward, I will just minimize the risks of getting into trouble. too bad. It really had a cute little something.

vendredi, octobre 21, 2011

wooden pixels

Vous avez remarqué qu'il y avait du bois sur chaque image présentée dans mon post précédent ? Pas un hasard, bien sûr: je cherchais des références pour les étagères du niveau "bibliothèque" ... parce que les "briquettes" du dernier mockup ... bof. Mais où trouver du bois dans un jeu vidéo ? Pas dans la cité des images de Rayman, en tout cas! Tout est en gomme, et tant pis pour ta pomme!

Première pioche: les bâteaux volants de SMB3. Un dégradé assez riche, mais qui reste principalement sur la même teinte (hue=35), sauf pour les extrèmes. Les rondins sont essentiellement un dégradé auquel on rajoute une "texture" en traçant des traîts horizontal de la couleur un cran plus claire dans chaque bande de couleur. Assez réaliste et réussi, mais on est pas du tout à l'échelle qui m'intéresse. Et puis, une étagère n'est pas en rondin, donc les irrégularités ne seront pas identiques.

Etonamment peu de teintes pour le niveau "off da wall" the Coolspot. On pourrait presque transposer directement ces graphismes-là sur NES. Les différents portages de Coolspot (SNES, PC, Amiga) sont très inégaux sur le plan graphique, et je n'ai pas la certitude d'avoir trouvé un screenshot de la version MegaDrive originale (afaik). Saturation surprenament élevée, et des patterns qui font allègrement usage du tramage, ce qui colle plutôt bien avec l'aspect "vieux grenier" souhaité. Une plaie à reproduire, par contre. Sous Master System (la version utilisée sur vgmaps pour en tirer les cartes du jeu), la "planche" d'un étage fait 32 pixels de haut avec un pattern de 32 pixels de large.

Couleurs super-saturées pour Zool -- mais ce n'est pas une surprise: le monde de zool est dans des tonalités systématiquement saturées. Même le fond est parsemé d'objets hétéroclytes qu'on a même pas tenté de rendre visuellement distants en les passant en tons pastels. On est ici à une taille un peu plus petite que celle de Cool Spot avec des "veines" d'un pixel de large, travaillant beaucoup sur l'anti-aliasing (surtout pour le bois plus clair). Un point-clé, c'est la grande régularité de l'espace entre deux veines, de 3 pixels. Sans ça, on a juste des traîts barbouillés dans tous les sens, comme ce que j'ai fait sur la droite :P Pattern de 32x32, de nouveau.

Petit retour à SMB3 ? Il faut dire que les "briques de bois" ont un comportement tellement particulier dans ce jeu (cachant parfois des plumes-tanooki mais nécessitant de les cogner *sur le côté*) que j'ai tendance à croire qu'il y a du bois partout ... en fait, il est plutôt rare ^^"

Ici, pas de "veines" dessinées dans le bois, mais l'impression qu'on voit un morceau de tronc débité dans la longueur, avec les anneaux caractéristiques. L'effet de dégradé obtenu n'est pas ce qu'on a vu de plus esthétique dans le jeu, mais personne n'ira suggérer que ce sont des tablettes de caramel. Pour faire des plates-formes dans les niveaux aquatiques, eh bien, les p'tits gars de chez Nintendo ont simplement répété une "vague" tous les 8 pixels, jusqu'à arriver au bloc "bord droit". Nettement moins crédible (bin oui, c'est supposé être concentrique), mais ça marche quand-même. Par contre, tout ça est (de nouveau) à une échelle qui ne colle pas à celle de Bilou. Rideau.

Et les Rangers du Risque ? eh bien, même technique que pour Zool, mais avec des veines nettement plus courtes et une limite de 3 couleurs par palette (noir, brun clair, et sisi-c'est-pas-du-rouge-c'est-du-brun-foncé). Bien réussi pour l'époque, mais je n'irai pas en faire une référence, ni au niveau des couleurs, ni au niveau des pixels eux-même.

jeudi, octobre 20, 2011

Influences for Bilou ...

Facile de voir que la school zone de Bilou ressemble à la cité des images de Rayman. Et pourtant, c'est une pure coïncidence: quand mon frère m'a ramené les nouveaux monstres de Pierrick, personne n'avait jamais entendu parlé du curieux bonhomme sans bras à moins d'être dans l'entourage rapproché de Michel Ancel... Ce dont je ne peux malheureusement pas me vanter.

Mais ce n'est pas pour autant dire qu'il n'y avait rien avant, même si à 15 ans, on avait passé le cap de "refaire un Sonic avec Calimero", il y avait forcément des jeux qui nous avaient marqués et qui nous ont donné envie donner vie à des objets genre "Alice au Pays des Merveilles"dans des environnement "zoomés". Coolspot ('93) fait ça un peu tout le temps. L'animation gag et fluide du jeu de David Perry a largement contribué dans mes influences pour les jeux vidéos, c'est clair.

I long for the "school zone" to get more monsters so that people stop saying that I should have mentioned Rayman (PSX) as an influence. No, rayman was still a top secret project (on SNES?) when we started sketching Sqrt and the pendats. But the video game album was already featuring a few dudes that shown us the way of micro-characters-in-macro-areas (just in case our daily dose of Wonderland weren't enough ;). Coolspot's attic is frequently appearing in my mind when I try to get references for the library level of the school zone, for instance. And of course, Zool had an even greater influence, with its objects-brought-to-life monsters.

L'année avant, l'ovni farfelu, c'était sur Amiga, c'était Zool, le ninja trans-dimensionel. Château des Délices -- euh, zone Chuppa Chups, je veux dire -- puis monde de la musique (tiens, tiens!), Jardin Géant, Boîte à Outils et magasin de Jouets.

Oui, ce "tueur de Sonic" à très certainement marqué le terrain d'une manière plutôt décisive, et je me demande même dans quel mesure il ne figure pas également dans les influences de Michel ;)

Ou alors serait-ce les Rangers du Risque (sur NES, dès 1990) ? Avec leurs niveaux à kangourous smasheurs dans une bibliothèque ? Si ce jeu figure parmi mes référence en terme de gameplay coopératif, en revanche, je ne crois pas être allé jusque là, ni même avoir jamais vu quelqu'un y jouer. Il faudra chercher ailleurs.

Oh, and just FYI, yes, I enjoyed Rescue Rangers a lot, especially due to its innovative and fun co-op play, but I'm afraid I never managed to beat the game up to the library level. So, no, this wasn't a reference for me. That's funny to note that Zool's first two levels just match Rayman's Cake and Music levels, by the way ^_^

mardi, octobre 18, 2011

branches/newcollide

So I finally started a new SVN branch with the collision engine modification that I sketched in the train. It's not going to be testable anytime soon, I'm afraid. The current collision engine was already abusing some "setContext(...)" calls to set static variables into GobExpression so that you can e.g. shoot things despites the eval() has no such thing in its argument. With the new "attach" and "align" features I want to develop, that becomes a huge mess of things to capture at various places in the GOB -> GOB -> area -> state -> expression call chain that happens at every collision. I bet the best move will be to extract all this context (including some of the things that are currently plain arguments) into a GobCollision structure which would have temporary lifetime (i.e. allocated on the stack) that would be passed around ...

Well, that'd be better unless the compiler is able to keep all the arguments in registers otherwise :P


Je dirais bien "assez causé, implémentons ces fameuses nouvelles collisions". Sauf qu'en fait non. Les petites modif' faites par-ci par-là dans le Boutdlard Express ne compilent pas, et si je fais ce qu'il faut pour qu'elles compilent, ça va être une véritable pagaille dans le code. Genre "la famille araignée en vacances dans une boites de spaghetti géante", voyez? J'ai une petite idée pour rationaliser tout ça sans perdre en souplesse ni (trop?) en performance. Je vous en dis plus après avoir fait le test.

jeudi, octobre 13, 2011

a link to the past ...

Everytime you explicitly save your SEDS work to a file, SEDS archives the former content under /data/seds/[ABXY]<year><month><day><sno>.spr. That way, you should not accidentally lose some work, and you can keep working forward despite the fact you can only save to 4 slots. If you want to retrieve something from those files, you had so far two options: either take your media card out and copy the file, or switch to runme and beam it out to a PC.

5 ans après, la politique de gestion des fichiers dans SEDS n'a toujours pas changé, et je la trouve toujours aussi pratique. 4 fichiers, "A,B,X,Y" que je choisis en appuyant sur le bouton correspondant de la DS sur l'écran-fichier après le bouton L(oad) ou (sto)R(e). Pour éviter de se tromper au moment de la sauvegarde, R-R réécrit sur le fichier ouvert (les anciennes données étant alors placées dans un fichier .bak). Quand je veux travailler sur quelque-chose de neuf, je sauve explicitement vers un des fichiers [ABXY], ce qui "repousse" l'ancien contenu dans un fichier-archive dans /data/seds.

Ce qui n'était pas pratique, par contre, jusqu'ici, c'était de parcourir le contenu de ces archives à la recherche d'un "travail à continuer". Mais avec les dernières modifications apportées à runMe, ça devrait bientôt être possible.

I had to do that last month when I wanted to revive work on the schoolzone pixel art, but tests with AnimEDS had pushed the schoolzone sprites into the archive. What's ridiculous is that runme can show you a preview of a .spr file that has just been beamed in, but it couldn't show you a preview before you beam out :P I made a few tweaks to runme these last days, fixed a couple of bugs in the SpriteSet.unpack(memory_buffer), too, and added an "offline" button so that you can navigate files with runMe even in the country side, far away from any WiFi base station. I'm not yet satisfied with the resulting usage flow, though. It does the trick, but explaining to anyone *why* it works so would be tedious. That will be for another lunchtime.

dimanche, octobre 09, 2011

Apple Assault fait mouche

J'étais donc dans le Zurich-Bruxelles le week-end dernier. Presqu'une journée entière, en fait. Après quelques tentatives d'encrage du Bilou's Book abandonnées pour cause de virages un peu plus serrés que prévus, je déplie mon PC pour tenter de mettre en oeuvre les modifications du moteur de collisions dont j'ai parlé ces derniers jours... de mémoire, vu que si la SNCF a équipé son Vauban(?) de prises de courants depuis 2008, je n'ai toujours pas d'abonnement wifi-dans-le-train :P

C'est alors que débarquent Lucius, Harry et Ron qui viennent squatter "ma" banquette. Pendant que Lucius et Ron se chamaillent à coup d'iPhone, Harry tente désespérément de faire son devoir d'arithmancie. Il pose à ses camarades une question du genre "si, tu sais, t'as une droite ou un point et tu dois refaire un point ou une droite ...". Au bout de 2 minutes, je risque "symétrie", histoire d'avoir la paix. C'était bien ça. Ron, assis à côté de moi, semble impressionné, et me demande "c'est quoi mon métier". "Informaticien", que je réponds. "C'est vos e-mails", demande-t-il en voyant la fenêtre Xemacs. "Non", que je réponds, "c'est du code. Du C++. C'est mon moteur de jeu". Il n'a pas immédiatement relevé, mais au bout de 10 minutes de questions, je finis par lui sortir ma DS, lancer la dernière version de Apple Assault et je lui mets la console entre les mains. "Voilà: c'est le jeu que j'ai fait l'an dernier avec mon moteur de jeu. Maintenant j'essaie de l'améliorer pour pouvoir faire d'autres jeux".

Imagine, Ron, Lucius and Harry in regular clothes, coming in your train and sitting next to you while you're coding upgrade to your collision engine. Ron was so curious about my job (since I was able to hint Harry on his math homework), and what is "code" for, what does a "game engine" do, en so on ... I finally picked up my DS in my bag and claimed. "Look, that's the video game I made last year with the code I'm updating now".

It merely took him some gameplay tips to start enjoying the game to the point Lucius couldn't resist to stand up and check what was going on. Both were previously toying with their iPhones, but Ron never complained about Apple Assault to be flat, old-school, odd or boring or whatever. He enjoyed it the same way I enjoyed Bomb Jack at his age... And when he handled me my DS back at his end station, he said "Informatics, that rulez!" -- "Yeah, I replied, but then you need to listen to your math and physics teacher well ;)"


Il lui a fallu quelques petits conseils pour pouvoir passer le premier niveau ("Waaaa, mortel!"), mais ensuite, le voilà lancé, posant ça et là des questions du genre "c'est vous qu'avez fait les pixels?" ou "on peut faire un jeu comme ça tout seul ?". Harry bougonne et continue son devoir, mais Lucius tend de plus en plus l'oeil par-dessus la console et finit par faire le tour pour s'asseoir sur l'accoudoir :) Ron ne me rendra la console qu'au moment de descendre du train, avec pour conclusion "C'est trop cool, informaticien !".
"Ouaip", que je réponds, "mais il faut bien bosser ses maths et sa physique".

quick gameplay note: despite my repeated suggestions that pressing (A) again while bouncing on ennemies would build up punch power faster, neither Ron, nor my colleague (and WP leader) Maugrey seemed to look at using that technique. As a result, they mostly had access to small-punch with limited range and efficience. Shooting a shuriken or doing a "big-punch" almost never occured during their game. When building levels further, bouncing on ennemies to reach a goal should be a refinement, not a basic feature to reach the level's exit.

mercredi, octobre 05, 2011

SpongeBop & Dumblador revisités

Je n'ai pas eu autant de commentaires que j'espérais sur Pixelation, mais ça m'a quand-même suffisamment motivé pour retravailler l'animation de l'encre dans le train, en revenant de Zurich, peaufiner les bouquins et faire une version un peu décente de mon éponge ainsi qu'un lifting pour Dumblador, le taille-crayon grognon. Par contre, je persiste et signe: ce sera une école "rétro" avec le matos des années septantes (voire antérieur), encriers, tampons, éponges molles et jaunes plutôt que stylo-bille et "brosses pour tableau". C'est ça l'esprit de la school zone depuis '94, et tant pis si certains trouvent que "ça fait bizarre, les nuages jaunes" :P

I remember of Pixelation being more reactive when I was working on the green zone graphics. I guess that's the recent datacenter failure combined with the lack of on-board zoom feature that makes the board itself less attractive to artists. Anyway, having some feedback motivated me enough to keep improving books, ink, spongebop, and even dig for (2006) unpublished pixels of Dumblador and revamp them. Hope you enjoy it. At least, I think I managed to be somehow close to my own design sketches.