un autre mot sur la VRAM

Ouaip. "un petit jeu tout simple où il suffirait de trouver toutes les pommes pour passer au niveau suivant" disais-je donc. Pendant les préparatifs de SeafoxDS, j'avais ajouté la possibilité de demander le chargement d'un fichier .pcx (une belle grosse image bitmap, quoi) comme image de fond. Sympa.

Histoire de tester ça, je bidouille un peu hier soir, mais pas moyen de sortir le décor de Donkey : King of Swing (qui n'est là qu'à titre temporaire, hein) sur mon écran: je me retrouve à la place avec un tas de tiles bleu suivant un motif improbable et quelques pixels aléatoires ça et là.

So, the next milestone should be a very simple "grab all the bonuses and head to the gate" kind of platformer, where i can gradually introduce tests. I just wanted to add a fancy background, since i added support for .PCX loading when "working on Seafox DS". I just couldn't make it work, while runMe can happily show .PCX files for at least two years ... I just forgot that SUB_BG0_CR register is not the only guy who matters here. Whether you have bitmap or tiled background is defined by the video mode, which in turn tells the graphic hardware how to interprete the content of SUB_BGx_CR.

J'avais beau fixer les lignes "SUB_BG0_CR = BG_BMP8_256x256|BG_BMP_BASE(1)|BG_PRIORITY(3);", identiques dans le mode "télécharger un .pcx et l'afficher" de runMe et dans le moteur de jeu ... rien n'y fait.

J'ai fini par me rendre compte ce matin que changer les attributs d'un fond particulier ne suffit pas à faire de lui un fond bitmap sur la DS. Il faut d'abord s'assurer que le mode vidéo supporte bien ce type de plan, mais aussi qu'il peut s'appliquer au plan choisi. En clair, les seules possibilités sont renseignées dans gbatek:

BG Mode
Engine A BG Mode (DISPCNT LSBs) (0-6, 7=Reserved)

Mode  BG0      BG1      BG2      BG3
0     Text/3D  Text     Text     Text
1     Text/3D  Text     Text     Affine
2     Text/3D  Text     Affine   Affine
3     Text/3D  Text     Text     Extended
4     Text/3D  Text     Affine   Extended
5     Text/3D  Text     Extended Extended
6     3D       -        Large    -

Le mode "bitmap 256 couleurs" est un des modes étendus (de même que les plans avec rotations et 1024 tiles, d'ailleurs), et donc disponible uniquement sur les plans 2 et 3 dans le mode 5. Vous suivez ? Ce que nintendo appelle le "mode texte", c'est en réalité le mode "tile" qui effectivement s'apparente au bon vieux mode texte des années 80 à ceci près que vous avez 1024 caractères (et non pas 256), 16 palettes de 256 couleurs et que chaque "caractère" peut combiner comme il veut n'importe lesquelles de ces couleurs (il y a aussi un mode 16x16 couleurs, pour les nostalgiques de la GBA, bien sûr :)

Only those combinations detailed in gbatek are possible. E.g. 3D + two text + one of the "extended" (DS-only) modes. But then, only "BG0" can handle 3D and only BG3 can be an extended mode. What i need for PCX (256 colours bitmap) is extended, clearly, which make me stumble into trouble as the Game Engine i've got so far is hard-coded to use BG2 and BG3 for maps, so that i could zoom in the front layer. Somehow, it was a bad idea >_< . It's not much a dead-end, just a reminder that DS hardware comes with constraints and that a "you just have to ..." idea must always be checked against those constraints...

Y'a un hic, évidemment: j'avais pour ainsi dire "hard-codé" mon moteur de jeu pour que la map utilise les plans 2 et 3 (histoire de bénéficier des effets de zoom, par exemple ... ça m'avait paru sympa). Mauvaise idée, comme dirait l'autre, hein :P

Oh, rassurez-vous, ce n'est pas un problème insurmontable. En soi, le "bitmap" tiendrait sans difficulté en mode "texte". C'est juste que ça me rappelle ma lecture de ce matin dans le bus, selon laquelle les druides théorisent que "l'univers, pour sa bonne marche, dépend de l'équilibre de quatre forces : le charme, la conviction, le doute, et l'envie d'emmerder le monde".

analysis paralysis ?

Près de 3 mois loin de chez moi, maintenant, et toujours pas de petit homebrew à vous mettre sous la dent. Okay, mon laptop est un char à boeufs comparé aux PC que j'ai à la maison. Okay, je n'ai pas de Wifi dans mon k0dek et le laptop n'est pas configuré pour faire base station pour la DS mais il y a autre chose.

Je sais qu'il y aura pas mal de choses à mettre en place pour parvenir à réaliser Bilou sur DS ... je veux dire par là, "le jeu de plate-formes tel qu'il avait été prévu dans les années '90 et prototypé sur BASIC", mais revu et corrigé pour la DS, bien sûr.

Par exemple:

• [just started] la gestion des bordures. Même si je garde au départ un système tile-based, les plate-formes mobiles et autres sables mouvant devront être capable d'altérer le comportement des sprites
• [ongoin] les pentes. Je veux que Bilou puisse se déplacer sur des plate-formes qui ne soient pas uniquement horizontales.
• [done] l'animation modulaire. ou "à la rayman", qui me demande un éditeur d'animations spécifique en plus des ajustements dans le moteur de jeu
• [done] les collisions perso-bloc qui soient plus maniable que juste le "petit bonus" que j'ai pour l'instant. Plate-formes qui disparaissent, échelles, etc.
• [done] des réactions aux collisions perso-monstre. Avec une question pertinente "et comment fait-on perdre une vie, au fait"

J'accumule les idées sympa sans vraiment avancer dans le développement. Je sautille d'un projet de shoot à une reprise de Seafox à un "bubble bobble - like" etc. Et bien sûr, comme j'aime le pixel art, j'ai tendance à explorer les aspects graphiques à tort et à travers avant de me lancer dans un jeu.

Je vais devoir me fixer une "roadmap" jallonée de petits projets intermédiaires, et attaquer les difficultés techniques une à une, sinon je vais finir par recommencer à programmer sur Clicker :P

Bonne résolution 2009 #1: on garde Bilou. Quelque soit le petit jeu envisagé
Bonne résolution 2009 #2: un nouveau thème graphique si et seulement si un jeu est produit.
Bonne résolution 2009 #3: s'il n'y a pas d'image de fond (ou si l'image est fixe, etc.) ce n'est pas un problème pour l'instant.
Bonne résolution 2009 #4: faire la vaisselle ce soir

edit: côté "base station", j'ai au moins pris la peine de recompiler le module de mon stick WiFi. M'en vais aller manger une soupe et tester ça @home, tiens.
edit++: toujours pas de connexion Internet au k0dek, mais au moins, j'ai su modifier runme pour qu'il puisse démarrer un programme 'runme-compatible' après l'avoir téléchargé.

3 monthes in Switzerland and still no updates. I'm not focused enough and therefore I'm missing the #1 golden rule of game development : *release*. Having no Internet access in my Swiss flat doesn't help, so I modified runme so that it can launch the last compatible .nds it received from a WiFi transfer. Using my laptop as an access point, it allows ad-hoc development.

Allez, je vais essayer de me faire un petit "ramasse toutes les pommes pour passer au niveau suivant". Ce sera déjà un bon début. Après tout, c'est fort le principe de base de Qwak, Bubble Bobble et même Still Alive DS :P

-*- intermission -*-

J'ai de nouveau des Bilous plein la tête, et évidemment une dead-line de premier choix qui se rapproche... Au fait, vous ne vous étiez jamais demandé ce qui permettait à un perso de jeu vidéo de revivre ? ou pourquoi on récoltant 100 gouttes d'eau (ou carottes ou pièces d'or, c'est selon) il avait droit à une chance supplémentaire ?

Allez, une petite idée sympa pour le jeu Bilou sur DS : à mesure que vous affrontez de nouveaux ennemis, vous aurez la possibilité de vous entrainer contre eux dans un mode "training" ou vous créez en direct la salle et la peuplez d'ennemis ... histoire de se faire la main ou de tenter un passage un peu délicat sans risquer vos précieuses vies ... Une sorte de holodeck, quoi.

(c'est vaguement inspiré du "Zoo" de Yoshi's Island, sauf que là, vous ne pouvez que les regarder, mais pas toucher)

Oui, parce que j'ai bien l'intention de faire en sorte que l'on ne joue pas à "oh, ben non, finalement j'ai perdu trop de vie sur ce niveau-là ... j'éteins la console et basta."
(^ edit: bon, évidemment, il y aura quand-même des "check-points" pour reprendre ailleurs que là où l'on s'est arrêté la dernière fois ... genre après avoir passé un donjon, avec le nombre de vies etc. par défaut)


edit: Moui. C'est décidé. Je laisserai tombé les "niveaux tutoriels" au profit d'un "playground" prééquippé de quelques obstacles classiques dans lesquels le joueur pourra ajouter les différents éléments qu'il rencontre pour s'entrainer, etc. J'aurais envie de dire "et il pourra aussi découvrir en explorant les niveaux des moyens de débloquer certains monstres, etc. pour le playground", mais ça fait fort Little Big Planet ... j'hésite un peu.
Sauver un playground et l'échanger par Wifi avec d'autres joueurs, vous dites ?
Ah ... Ca, ce serait intéressant, oui.

Johnny Platform's Biscuit Romp

C'est toujours sympa de tomber sur un bon petit homebrew qu'on ne connaissait pas et qui vous accroche pour un week-end. c'est le cas de Johnny Platform's Biscuit Romp par Craig Forrester (ishisoft).

I stumbled upon "Johnny Platform's Biscuit Romp" game by Craig Forrester a couple of days ago: exactly the kind of puzzle platforming game i love. The goal is simple (dismantle robots to get out of there), but with enough variations between levels to make it a brain-teaser with cute graphics.

Biscuits will play a major role since you can push them around and use them as platforms or weapons to reach the goal. One level at a time, you will learn how to use them by yourself, using simple puzzle first before it gets more complicated. I especially love how Craig made it without introducing spoiling-text trying to hint you as tutorials tend to do. When you've tried everything you know your character can do and the level seems to have no solution, think out of the box: you haven't discovered all the possible moves/uses of the game yet.
Biscuit Romp a tout pour faire le bonheur d'un amateur de "puzzle platformers" comme moi : un environnement coloré et sympathique, un principe simple (éliminer les robots pour faire apparaître la porte de sortie) mais dont les variations mettent vos neurones à l'épreuve et des graphismes pas-tout-à-fait-oldskool-mais-presque ...

En déplaçant les biscuits (carrés et ronds), notre protagoniste au bonnet rouge va devoir traverser des lacs, escalader des obstacles, etc. Les usages multiples de ces deux éléments sont tout simplement épatants. Et le "wrapping" (à la bubble-bobble) sélectif (présent dans certains niveau mais pas dans tous) permet d'étendre la zone de jeu tout en gardant l'ensemble du puzzle immédiatement visible. Histoire de varier un peu les choses, Craig introduit progressivement des plate-formes aux propriétés inspirées des casse-briques de mon enfance ...

Bon, je regrette un peu les "contours noirs omniprésents", évidemment, et je n'ai pas bien compris pourquoi ce personnage fait une fixation sur les tasses, mais bon ... Si les robots sont assez esthétique, le personnage principal fait un peu peine à voir, avec son visage verdâtre et ces membres à peine esquissés. Dommage au milieu de décors si bien réussis.

Hazards and levels are varied, clever use of the wrapping makes whole level fit the double screen of the DS and keep the whole puzzle in front of your eyes. Dodging bullets is probably the hardest part of the gameplay for me -- i guess i have been too much used to those bullet-bill that can be jumped.

It's always nice to see some standalone author to come up with a game which is fun to play. This is a huge achievement per se (i have enough not-yet-ready-to-play demos of my own to value it properly), and still, i can't help thinking that a little gem could use some more polish.
The protagonist, at first, looks odd to me. Who's that guy ? how comes he's surrounded by biscuits and is so interrested in cups ? His arms and legs look a bit unfinished ... i'm sure guys at pixelation would call him a placeholder. That's a bit of a pity, because otherwise, the graphics were quite enjoyable.

Next, the sound is poor. Craig reported that he's been facing technical issues with sound hardware of the console, and i can't really blame him for this... but those voices do not match characters: neither the hero nor the robots. I'm really tempted to suggest my bross CJ to write a couple of tracks for the game and ask Craig his sources to see if i can use ntxm player for his game ... but i just lack time for this, and will hope for an update ... or another game from ishisoft ;-)
Gros point noir: la bande son. Effets enregistrés à la voix à une fréquence douteuse et pas de musique de fond (suite à des soucis techniques, dixit l'auteur qui n'en est encore qu'à son premier homebrew sur DS). C'est un peu dommage. J'aurais bien envie d'envoyer tonton CJ à la rescousse et de bidouiller les sources pour activer le xmplayer que j'utilise pour arranger tout ça :)

Le nouveau Biokid pixelisé.

Après les croquis, les pixels. Biokid, revu et corrigé. C'est sans doute les éléments les plus complexes qui sont sorti de mon SpriteEditor DS jusqu'ici. Je n'irai pas jusqu'à dire que ça a été facile, par contre, mais je suis plutôt fier du résultat même s'il a fallu un peu bricoler les détails avec The Gimp sur la fin.

Malheureusement, on dirait bien que je l'ai rapproché de Megaman (X) au lieu de l'en éloigner ... (soupir). La gemme sur le front, les poings blancs, même le look des bottes -- mais bon, je n'ai jamais été doué pour dessiner des pieds, donc le look "mega-man" des pieds masqués par ces énormes bottes était irrésistible pour moi.

Il est de toutes façon trop grand pour pouvoir servir dans un jeu DS (sauf peut-être un jeu de combat, et encore).

I cannot really say that "Biokid NT" is a real game project, but from times to times, i come with some gameplay ideas that would fit nicely there and i can't help but working "a little bit more" on it. Unfortunately, i'm no longer so happy with the former look of Biokid (as of '98) and after a little "brainstorming" on pixelation, i started with sketches of a newer, more dynamic, somewhat ninja-inspired Biokid that would make it clear that "this guy ain't megaman".
I then turned those sketches into pixels -- the largest sprite ever built with SEDS. And unfortunately, it seems that it's still too megaman-ish with his white gloves, barrel arms and big boots. Plus the sprite is simply too big to be of any use in a DS game (half the screen height :P)

Je devrais peut-être continuer dans l'optique "pas besoin d'une armure lourde" et remplacer les bottes par des jambières/genouillères et quelque-chose de similaire pour les avants-bras.

Seafox

Un chouette petit jeu qui trônait sur la même disquette que WarHawk de notre bon vieux commodore. L'illustration même du principe d'un jeu d'arcade : des contrôles simples, un écran unique et une difficulté progressive par un système de mission. Notre vaillant petit sous-marin (repeint en jaune pour la version "DS") s'attaque à des convois marins (la ligne la plus haute) et tente de les couler. Ces convois sont protégés par des croiseurs (la deuxième ligne de bateaux) sur lesquelles vos charge mer-mer iront rebondir et couleront (avec risque pour vous d'y laisser votre peau). Evidemment, vos activités de piraterie ne restent pas longtemps inaperçues, et la compagnie (l'armée ? va savoir ...) qui gère ces caravanes maritimes envoie à vos trousses ses chasseurs sous-marins.

On the same 5"1/4 floppy than WarHawk stood SeaFox. The ultimate example of a good ole' arcade shoot-m-up game : simple but efficient controls, a single screen and a progressively increasing difficulty. Our (yellow on the mockup) submarine try to sink sea fret of some kind (the top line) that are protected by armored ships (the bottom line). As that "shipping Guild" doesn't seem to like your piratery activities, it sends its own sub-fleet to kill you.

As being in the process of trying to revive the game on Nintendo DS (hence the mockup), i've been (of course) re-playing it extensively this week-end to pinpoint important gameplay elements. Ridiculous do i hear ? well, you do not want me to screw it up "à la Tetris DS", do you? Okay. As far as it goes, the relative speed of sprites (torpedos, ships, submarine, fleet) seems to be of high importance: you can escape a opponent sub only vertically : it is just too fast horizontally. You can shoot them with torpedos, but only left-to-right: your sub never turns back.

(PS: I started coding it this week-end and i'll translate more as code progress. It's time i take care of that coffee breach on deck 2. The bridge is yours.)
L'expérience du "tetris DS" et de Space Invaders Extreme m'a appris au moins une chose: quand vous reprenez un vieux jeu, faites-le bien ou ne le faites pas du tout. Donc, au niveau du gameplay, quelques petites contraintes supplémentaires viennent pimenter l'affaire:
• un seul missile et une seule torpille à la fois sur l'écran.
• les chasseurs 'suivent' votre sous-marin horizontalement et traversent l'écran, soit de gauche à droite, soit de droite à gauche.
• votre sous-marin se déplace plus rapidement de haut en bas que de gauche à droite, les chasseurs, à l'inverse, montent et descendent difficilement mais avancent deux fois plus vite que vous (la vitesse de vos torpilles).
• Le fuel (temps) ainsi que le nombre de torpilles est limité.
• Les croiseurs sont légèrement plus lents que le sous-marin, et les navires facilement deux fois plus lents que les croiseurs.
• Votre sous-marin est toujours pointé vers la droite et ne peut donc tirer des torpilles que dans cette direction.

En principe, la caravane passe en boucle jusqu'à son élimination complète. Ca par contre, ça ne me plait pas trop. Je ferai en sorte qu'elle ne défile qu'une seule fois, mais avec la possibilité pour notre petit sous-marin de passer en mode "turbo" pour aller la rattraper et lui tendre une deuxième embuscade . . . ensuite ... hmm ... pourquoi pas voir couler les navires dans l'écran du bas ... il faudra (peut-être?) les éviter et ils pourraient laisser s'échapper des bonus (ultra-missile pouvant couler un croiseur, torpilles plus puissantes, renfort de fuel, brouillage sonar (invisible aux chasseurs)) etc.

Oh, oui. Dans la version C64, tous les navires ont la même taille ... bin à défaut de les faire aussi variés que sur commodore, les miens ont des tailles assez variables ... on pourrait presque jouer au combat naval, tiens ;)

Enfin, faisons d'abord le code tout simple, on enjolivera ensuite ^_^

allez, let's go : je commencej'ai commencé la programmation ce week-end (par des ajouts à mon moteur de jeu et des petites classes pratique genre "Contrôleur-qui-suit-une-cible", etc.)

Note pour plus tard : dans le jeu C64, les "recharges" sont effectuées par un sous-marin qui lache un dauphin une fois arrivé dans le coin inférieur-droit de l'écran. Une sorte de poisson-pacman va tenter de gober les munitions du dauphin on a en gros qu'un demi-écran pour faire la recharge, et surtout, la destruction du dauphin déclenche immédiatement l'envoi d'une sorte de baleine vengeuse à laquelle vous ne pourrez pas échapper. Greenpeace veille ^_^. Ca me paraît un peu beaucoup pour une première implémentation, mais c'est à mon avis un des éléments du gameplay qui en faisait un jeu sympathique et attachant (au risque de distraire le jeune joueur de la mission de base -- couler les navires -- d'ailleurs).

PS: mon frère est sur la brèche pour le son, bien sûr ... Par contre je cherche un artiste pour me refaire les fonds (là, j'ai pris une image sur Internet -- et donc pas libre de droit -- juste pour avoir une idée de ce que ça donnerait ...)

Hacking gspca for Logitech QuickCam E1000 support.

Hop, je fais le saut: j'achète une webcam. Pas chère (25 francs) avec oreillette inclue "für skype" ... Mon choix s'est arrêté sur la QuickCam E1000 de Logitech, dans un rayon qui semble comporter une douzaine d'autres webcam qui se ressemblent toutes, en ce qui me concerne, hormis peut-être leur prix.

Je branche ça sur mon portable linux ... et évidemment ça ne marche pas tout seul. Le CD ne comporte que des drivers pour windows, ce qui n'est pas une surprise non-plus. Haa... on a pas encore fini de changer le monde.

Bref. Un petit tour de google, et je tombe là-dessus : http://doc.kubuntu-fr.org/spca5xx "installer gspca sous ubuntu, la version facile" ... je prends. je suis les instructions à la lettre, le module (comprenez "le driveur" pour les windoziens) s'installe. c'est bien. Sauf que point de webcam.

I just blindly bought the Logitech QuickCam E1000 this week-end (since it was the cheapest webcam around) and of course realised that it did not came with any Linux driver (not that it's surprising in any way) nor does it seems to be supported by any "out-of-the-box" driver for Ubuntu gutsy (unless i'm proved wrong). Hacking around, checking lsusb and reading the sources of the gspca driver, i figured out that it was yet-another-generic-driver that has a "white list" of supported devices. I thus added the product-id to that white list and now proudly have a working webcam. See compiled driver (which might no longer work with Labtec Webcam Pro, because i've really been *hacking* instead of *patching*) and modified sources down the page.

Un petit "lsusb" me donne au moins la référence "technique" du produit : Bus 001 Device 012: ID 046d:08af Logitech, Inc.

Ces deux numéros magiques (vendor-id=046d et product-id=08af) me permettent de voir (dans les sources du driver, en bas à gauche de l'image) que si pas mal d'autres webcam logitech sont supportées, par contre, la mienne n'est visiblement pas là. Comme le "gspca" est un driver "générique" (à savoir qu'il est en fait valide avec toutes les webcams 'standard'), j'ai 9 chances sur 10 pour que le code puisse effectivement faire fonctionner la webcam si j'arrive à expliquer au driver que "si, si, je t'assure, tu la connais aussi, celle-là". Un peu comme si votre clé-télécommande devait reconnaître la plaque minéralogique de votre voiture pour pouvoir la faire démarrer.

Bref. Premier jeu, donc, ajouter dans gspca_core.c l'identité de notre caméra. Perso, je parasite n'importe quelle entrée dans device_table[], mais il serait plus propre d'y ajouter {USB_DEVICE(0x046d, 0x08af)}, /* Logitech QuickCam E1000*/ et d'éditer en conséquence clist[] et l'énumération des caméras.

Avec ça, le driver peut dire au noyau que la webcam est pour lui, mais ça ne suffit pas. La fonction spcaDetectCamera() est appelée chaque fois qu'une nouvelle webcam est branchée, histoire de lui souhaiter la bienvenue, de prendre un verre avec les autres périphériques USB ... euh ... ou pas. C'est là que l'on va retrouver un gros "switch" qui va règler les options de notre driver générique pour chaque modèle de caméra (peut-être pas si générique que ça, donc, en fait :P) Je fais bêtement le pari que ma caméra "8af" sera probablement juste une réédition de la "8ae" (QuickCam for Notebooks), et donc :

   case 0x08ae:
case 0x08af: // uber-experimental.
    spca50x->desc = QuickCamNB;
    spca50x->bridge = BRIDGE_ZC3XX;
    spca50x->sensor = SENSOR_HDCS2020;
    break;

Et hop! ça marche! J'adore linux!

le module recompilé pour gutsy : gspca_e1000.ko le fichier gspca_core modifié pour la QuickCam E1000 : gspca_core_e1000.c (soyons open-source jusqu'au bout ;)

Et pour ceux qui trouvent que "Aarhgh! Skype, c'est le mal", je propose la lecture de l'édifiant "Castle in the Skype" de Fabrice DESCLAUX, puis je leur dirai que MSN, c'est pas forcément mieux ;)

edit: cette manipulation est valable sur Gutsy uniquement. Sous Hardy Heron (et probablement les versions ultérieures), les drivers pré-compilés supportent directement la caméra.