jeudi, novembre 19, 2009

November Checkpoint

I see coming another Square of Time where all i'll be able to do is small step improvements. Working on the "remaining 10%" and so on. So here's the "achievements" that happened lately.

  • Dynamic Sprite Priorities is implemented and tested.
  • fixed a nasty memory error (bad_alloc thrown) that occured on level loading in runme
  • provided a "action-step-report" system that keeps "logs" unprinted until something "goes wrong", in which case it can dump the whole history of the failed action.
  • fixed the "push-tiles-across-layer" option of the level editor.
  • "prev / next" buttons in the level editor now skip spritesheets (and thus only show tiles)
To be investigated "tomorrow" (maybe not "this" tomorrow, but at least "a" tomorrow).
  • Odd-bonuses obviously have a dormant bug. I suspect clearblock() auto-aligns on 16 pixels, making "half-an-apple" pending uncleared.
Bion, j'ai plein de chose à faire dans la maison, donc le tir d'étoiles, assomer les pommes pour les porter "façon koopa shell" et tout ça, ce sera pour plus tard. Je me contente de "petits pas". Voici les quelques dernières choses sur lesquelles je me suis attelé.

dimanche, novembre 15, 2009

Opérée


Fameuse épreuve passée pour notre petite *deline. Ce 3 novembre, elle subissait une intervention à coeur ouvert destinée à corriger sa tétralogie de Fallot aux cliniques St-Luc. Après 4 heures d'angoisse, nous l'avons accompagnée tout au long de sa récupération et nous sommes rentrés le 11. Tout se passe pour le mieux. Son "p'tit coeur tout réparé" lui a valu une mention "très bien" auprès des docteurs. Maintenant, il lui faut se réhabituer à notre rythme de vie ...

Merci à vous tous qui nous avez soutenus le long de ce chemin.

Il nous reste à veiller encore un peu plus sur sa santé, puisque pour les 6 semaines à venir, elle sera particulièrement démunies contre les maladies de l'hiver, et une infection risquerait d'entrainer des complications.

I'm glad to announce you that the heart surgery planned on *deline happened last week, and it happened very well. She's now back at home with her (exhausted) parents to slowly resume the "normal" live (you know, the one where you sleep during the night ;)

mercredi, octobre 21, 2009

ratchet & clank

Jusqu'ici, mon Cyborg de frère m'avait surtout fait tester du "concept game" téléchargé sur PSN. Le week-end dernier, entre deux dessins pour mes p'tits n'veux, je n'ai pas pu résister à la tentation d'essayer moi-même le Ratchet & Clank que Ciji avait mis dans sa PS3 pour eux...

Pas de mode 2 joueurs ?

Je me souviens de "Rescue Rangers" sur la NES et "Mickey & Donald" sur la MegaDrive. Je me souviens aussi de "Two Crude Dudes" et de "Super Probotector". Quand on peut participer à deux dans le même monde virtuel, le fun est immédiatement porté au carré, et dans R&K, un mode coopératif aurait sans aucun doutes pu être envisagé. Alors bien-sûr, peut-être mon frère n'a-t-il tout simplement pas mis ce mode-là en route, mais ça m'étonnerait de sa part. Au temps des MMORPG, obliger les gamins à se passer la manette après chaque vie perdue, c'est quand-même du beau gâchi. Quel est l'intérêt d'avoir une console, si c'est pour jouer tout seul ?

monde cruel ?


Plutôt sympa, l'idée de l'attaque des robots (Rayman était passé par là ... Sonic aussi, d'ailleurs): ça permet de se défouler à tout faire péter sans s'embarasser avec des détails éthique. Une fois le robot détruit, reste une pitoyable créature sans défense qui gigote par terre ... pourquoi donc avoir construit un gameplay qui octroie un double bonus au joueur qui massacre ces bestioles ? J'ai peut-être tort de ranger "Ratchet" dans la catégorie "jeu pour enfants", mais je vois là une cruauté gratuite.

caméras, non de ...

Rien à faire: c'est systématiquement là que le bât blesse dans les jeux 3D. C'est bien beau de nous mettre un environnement à tomber par terre et des animations à couper le souffle... S'il me faut 2 minutes pour arriver à mettre la caméra dans l'axe de sorte que je voie les monstres que je suis sensé dégommer, ça ne sert à rien. J'avoue que le problème était un peu moins crucial quand j'avais la manette en main que pour mes n'veux qui tournent en rond un bon moment avant de comprendre vers où ils sont sensés aller, mais ça reste un point faible énorme, en particulier pour un premier niveau.
De ce côté-là, par contre, j'aimais assez bien le gameplay de Rayman 3, qui utilisait les boutons-gachettes pour passer en "mode flingueur" : caméra pile de dos, et on se déplace par bonds latéraux plutôt qu'en pivotant sur soi-même. Ratchet propose un "mode sniper" qui n'est pas aussi convaincant.

sélection d'armes ... bof bof ...

Ratchet joue du phaser et de la clé à molette. Sympa. Bonne combinaison qui permet à la fois des mélées intéressantes et de l'attaque à distance (avec un viseur automatique si la distance est bonne). Par contre la première "weapon upgrade" est passée complètement inaperçue. Le menu de sélection des armes est lent à activer, le choix difficile à faire. Ca casse le rythme. Je préférais de loin l'approche "cave story". Avec une manette qui a autant de bouton que le Dual Shock, on était en droit d'espérer mieux.

Et je pense que personne n'a besoin que je dise le fond de ma pensée sur les cinématiques. Par vrai ?
Voilà, donc. Mon impression de retro-gamer réfractaire envers ce monument du jeu vidéo moderne, médiatisé et marketisé. D'un autre côté, avec un peu de chance, les développeurs ont eu droit à un salaire. Chose plutôt inhabituelle parmi les pionniers de l'ère 8bit ...

mardi, octobre 20, 2009

Sprites à Priorité Dynamique

Voilà typiquement le genre d'environnement qui était pénible à construire avec l'ancienne version de LEDS et qui devient simplissime avec le curseur de copie et autres nouveautés.
Mais c'est aussi le genre d'environnement qui pose problème au moteur de jeu dans sa version ".999" parce que j'utilise les deux plans de tiles comme arrière-plan alors qu'à d'autres endroits dans le jeu (p.ex. quand Bilou est dans un arbre), il se situe en fait _entre_ les deux plans.

Bushes like these were typically the kind of background that was a real nightmare to build with the previous release of LEDS. And with the "copy cursor" and "pull to foreground" modes of the new prototype level editor, it's really easy and funny. On the other hand, it was also the kind of background that challenged the game engine. It is acutally built by "flattening" the two layers in such a way that i never need more than two tiles at a place, and yet simulate much more planes. Unfortunately, as i wish some elements to hide Bilou (such as walls and trees in secret places), Bilou actually stands "between" the two layers i'm using here, while in this specific case, he should be on top.

Le résultat, c'est que souvent, les pieds de Bilou étaient masqués, comme sur l'image ci-contre, soit parce que j'avais oublié de repasser l'herbe en arrière plan, soit parce qu'il y avait déjà un autre élément de décor par-derrière l'herbe.
Quand j'avais lu les spécifications techniques de la console Genesis, j'avais été plutôt étonné de voir qu'il n'y avait que deux plans de tiles. Or, Sonic est parfois devant le décor et parfois derrière (sans compter l'image de fond, bien sûr, qui occupe le 2eme plan). Le truc, c'est que contrairement aux console de Nintendo, la Genesis permettait de définir pour chaque tile si les sprites avait priorité ou pas pour l'affichage.

As a result, it is common to see Bilou's feet hidden by the grass in the latest demo, either because i forgot to move the grass to the bottom layer, or because it has to be on the front layer due to some other object (e.g. vines or bushes) in the background. I'm trying to address this by reproducing in software the technique used in the SEGA Genesis, as illustrated in Sonic II.

Je vais donc tenter de reproduire cette approche en software: puisque je dois tester les "flags" de chaque tile lors du déplacement de Bilou, je peux assez aisément en ajouter un qui force Bilou (et les autres sprites) à "passer par-devant le décor" quand ils sont au moins partiellement en contact avec ce tile-là. Ca risque bien de compliquer un rien l'édition de niveaux, mais ça devrait valoir la peine...


Despite the Genesis had only two "scroll layers" (against 4 for the DS), it dynamically evaluated tile-to-sprite priority: while all the tiles involved in the "tunnel" on the picture above were on scroll layer A, Sonic can be hidden by the "front pillars" and still seen in front of the dark checker tiles. I'm unsure whether this implies that rings in Sonic were sprites, though. I cannot change the DS hardware, but i can mimmic this technique by having some of the tile attributes (F_RAISER) that forces any sprite that hits it to appear above all the "scroll layers" rather than between "F scroll" and "B scroll" for this specific frame. It's still to be tested.

mardi, octobre 13, 2009

Ziggy, il s'appelle Ziggy ...

Unfortunately, I'm not the author of these graphics (2Dhero is), neither am I working on a nintendo DS port of this indie game running on Game Maker for Windows. So why does it appear here ? because I'm studying it as much as I can: character design, graphic style, palette choice, composition. This is truly a platformer gem that we are offered here, reminiscence of Superfrog (with so much better gfx!)

Je ne peux pas m'empêcher de comparer Ziggy à Superfrog. C'est un excellent exemple de "jeu d'auteur" où la passion (et le talent, je dois l'admettre) nous apportent un jeu d'une qualité rare en ces temps de crise. Vous l'aurez compris: il ne s'agit pas de graphismes à moi, ni même d'un homebrew pour DS (dommage, d'ailleurs). 2Dhero nous a concocté son jeu "en indépendant", avec le Game Maker pour Windows, comme beaucoup d'artistes du pixel le font ces derniers temps.
De mon côté, j'étudie tout ça avec beaucoup d'intérêt ... palette de couleur, composition de la scène, style graphique, etc. J'imprime en gros plan, je colle des petits extraits dans mon agenda, etc. Je ne "relookerai" probablement pas complètement Bilou pour suivre le "style ziggy", mais comme je coince sur les lianes et les fleurs ces temps-ci ...

A noter au niveau gameplay une "attaque aérienne" qui permet de sauter horizontalement en plus du saut ordinaire, ce qui ouvre presque plus de possibilité que la "glissade", plus classique.

Oh, et pour ne rien gâcher, il tourne dans wine...

dimanche, octobre 04, 2009

L'île des colons -- that was Bilou RPG

Je m'offre un petit moment de nostalgie... En cherchant "Bilou et son astro-flasheur à perforation en vrille" pour mon frère, j'ai repris une série de captures d'écran d'un de mes plus gros projets en QuickBasic: Bilou's Quest. Un Zelda-like dont j'ai retrouvé une version sur diskette en fouillant chez mes parents il y a quelques semaines de ça. Le montage n'est pas génial: à l'époque de la sauvegarde, j'étais alors occupé à remplacer le joystick par la souris, ce qui fait que la version récupérée a besoin de la souris pour diriger Bilou et d'un gravis 4 boutons pour parler, soulever, etc. Bref, j'ai triché en démarrant les fichiers .BAS directement.

I'm taking you back 15 years ago, with a couple of screenshots i've taken this morning. Here comes the island that Bilou explores in Bilou's Quest -- one of my largest QuickBasic games. I recovered a backup on a floppy a couple of monthes ago and finally managed to make it run again ... well, sort of.
I agree there isn't much to be proud about anymore: that's just a nostalgic memory, and the first occurence of Flower Power and Badman in pixels.

Du coup, je goupille comme je peux, je remplace les écrans auxquels je n'ai pas su accéder par des captures de l'intérieur des maisons et des grottes, etc.

Bon, je vous le concède, en dehors de l'aspect "nostalgie", il n'y a pas grand-chose à en retirer. La maniabilité était innomable, les graphismes de Mystic Quest sous GameBoy sont bien plus réussis, le scénario manque cruellement d'inspiration, etc. Rien qui ne justifie que je cherche à en tirer une adaptation DS, quoi.

Mais en son temps, c'était chouette de bosser dessus ;)

Et puis, ne lui retirons pas sa valeur essentielle: c'est un projet qui a été transformé en un jeu. Compte tenu de la quantité impressionnante d'idées de jeu que "la farde PPP" contient, Bilou's Quest a tout de même le grade de "réalisation", même si ça ne couvre que 10% du scénario prévu (à la fin du niveau 1, le joueur n'a pas encore d'épée et ne peut se défendre qu'en lançant des pommes). Merci à mon frère Piet de me le rappeler.

mardi, septembre 29, 2009

IRQ_VCOUNT

Voilà exactement le genre de technique de programmation que j'ai toujours admiré sur les consoles (et les ordinateurs Commodore, qui d'une certaine façon, sont des consoles avec un clavier et un lecteur de disquette). Mettons que je veuille modifier au milieu d'une image les paramètres de l'affichage, comme la palette de couleur, la priorité et la position de tel ou tel plan du jeu, etc.

Pour un jeu vidéo, ça me permettrait par exemple de garder une zone de score fixe dans un jeu à scrolling, ou (*ze* cas d'école) de virer la palette dans les bleus à la hauteur du plan d'eau. Dans mon éditeur de niveau, ça permettrait aux boutons de rester affichés correctement malgré les choix d'afficher ou de masquer les différents "calques".

Bien sûr, ça peut être approché aussi sur les cartes VGA etc. à condition de bien synchroniser le timer avec les débuts et fin de ligne à l'écran. Et c'est là toute l'élégance de la "solution console": il y a une ligne d'interruption dédiée directement à cette synchronisation (donc plus besoin de timers), et dans le cas de la DS, on a carrément le luxe d'un registre supplémentaire qui indique si la ligne courante correspond ou non à une ligne indiquée.

void vcountirq() {
if (REG_VCOUNT<192) {
BG_PALETTE[0]=RGB15(0,0,31);
REG_DISPSTAT = (REG_DISPSTAT&0xff)|(192<<8);
} else {
BG_PALETTE[0]=RGB15(0,0,0);
REG_DISPSTAT = (REG_DISPSTAT&0xff)|(160<<8);
}
The 'vertical count matched' interrupt is a perfect explanation of why I prefer underground console programming against overworld PC games. It is a very simple mechanism that lets code be run when the graphic controller is about to process line Y, and yet it enables a wide panel of special effects in games. The most common "showcase" is for sure implementing water: at a given horizontal position, you swap the palette and provide a "bluer" one so that bottom of the screen looks sunken.
The above code snippet does just that in a "raw" fashion where only backdrop color is changed. Don't let yourself scared by those bit masking, combining and shifting. It is just another facet of computing that is *very* handy when dealing with hardware registers. If you think of your process as an "electronic process" taking place on an array of bits, it just becomes natural.

Une petite fonction toute simple donc, qui sera appelée "sur la bonne ligne" et qui change les couleurs (ici, une seule, et entre deux valeurs pré-calculées, mais c'est juste pour la démo). Astuce, pour pouvoir être invoquée sur plusieurs lignes (plutôt que toujours sur la même) et donc remettre la couleur à sa valeur précédente, je change le numéro de la ligne où l'interruption doit se produire pour lui donner la valeur suivante dans l'interruption elle même (c'est le code avec REG_DISPSTAT).

Bon, okay, le code avec les & et les << fait un peu peur: c'est des manipulations de portions d'entiers pour modifier un byte qui se trouve en réalité dans la moitié d'un registre de 16 bits. La programmation DS est remplie de bidouille de ce genre. C'est de l'informatique d'avant XML, qui exploite pleinement la structure binaire des nombres.

Bien sûr, pour que ça fonctionne, je dois enregistrer la fonction vcountirq via la libnds (il ne suffit pas de lui donner le bon nom pour que ça se fasse tout seul. Vous rêvez, les gars!)
irqSet(IRQ_VCOUNT, vcountirq);
REG_DISPSTAT = REG_DISPSTAT|(160<<8);
irqEnable(IRQ_VCOUNT);
Vous remarquerez qu'on retrouve ici aussi les "manipulations bizarres" sur DISPSTAT, pour l'initialisation. Heureusement, le web est plein de gens qui passent leur temps à expliquer "X&FF = garder les 8 bits de poids faibles de X", etc.

Et pour désactiver l'effet,
irqDisable(IRQ_VCOUNT);
tout simplement.
J'aurais pu vous bricoler tout ça juste pour le fun ou parce que je prépare en secret un nouveau niveau de Bilou avec de l'eau. Malheureusement, je n'en suis pas encore là. Je suis dans une impasse avec mon éditeur de niveau, tout simplement: les boutons qui me permettent de décider si je veux voir ou non le fond, le plan principal, les sprites, etc. disparaissent ou deviennent illisibles par suite des manipulations pour changer la visibilité des plans. Résultat, rien de tel qu'un bon "virq" pour forcer l'affichage à "revenir" dans le bon état le temps de m'afficher la barre d'outils qui doit se trouver en bas de l'écran tactile...

Well, i wish i was posting this message because i'm working on an impressive water level. Not yet. I'm simply stuck with the UI of my level editor, where i need more layers than the console actually provide, so I'm doing a dynamic "horizontal split" when the user press "down" to access layer visibility setup. The hardest part is to integrate this properly in the GuiEngine (as usual with OOP >_<)

... Reste à intégrer ça dans le GuiEngine ...

edit: i managed to integrate and test on real hardware. It works, despite the amount of time taken by the operations confirms just "dma'ing" a new palette wouldn't work. The actual code for my 'vcount' handler is only 8 lines long (50 instructions, involving 8 stores to video registers), but it takes two scanlines to be fully processed. Plus, the first scanline shows a "flickering" area of some 24 pixels wide, suggesting that even the "companion code" that brings us from the interrupt to the "virtual void online" snippet is also too long. Maybe pushing it to ITCM would help ... and having the interrupt taking place one line in advance and forcing a busy loop until we encounter a HBLANK.

update: Pour la petite info, c'est maintenant intégré et testé sur la DS elle-même. Et ça marche, même si je suis surpris de voir 8 modifications de registres (les données sont constantes: ça se voit dans l'assembleur généré par le compilo) prendre quand même deux lignes d'affichage pour s'exécuter ! Je devrais peut-être essayer de mettre les routines concernées en ITCM, histoire de m'assurer qu'elles soient toujours en cache, ou qqch comme ça (sur du C++, ça va être coton, tiens!).