Saturday, December 13, 2008

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.

Monday, December 08, 2008

Seafox

petit mockup avec les sprites du week-end dernierUn 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.

Seafox sur C : l'original 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 ...)

Monday, November 03, 2008

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.

Friday, October 24, 2008

:* idle mode *:

Le boulot en Suisse est plus trépidant que prévu ... peu de temps consacré à Bilou (entre-autres pour des bêtes détails de prise électriques non-compatibles qui rendent l'allumage de portable un peu lourd).

Mais bon, j'ai re-fini Zelda: Phantom Hourglass, et donc je vais sans doute passer plus de temps sur de la bidouille plutôt qu'à jouer en "pur consommateur" dans les prochains week-ends ...


My first weeks in Switzerland have left me much less spare time that i initially thought ... Partly due to the Generic Path idea that is drawing nearly all my attention ... and combined with the fact that i haven't set up a convenient place to code at "home" yet, nor a comfortable place to sit down and think (which should fix tonight).

Plus i could not resist the Phantom Hourglass box on the shelf and played the game once more (and confirming that it is damn too easy, way too short and stuff ... i'm going to let my nephew have it, i think)

Friday, October 10, 2008

mon routeur à un DNS qui rame ...

Bon, avec ces routeurs Wifi qui deviennent de plus en plus fréquents, j'imagine ne pas être le seul à avoir le problème : ce genre de routeur se renseigne généralement comme "serveur" DNS local (en gros, c'est lui qui se chargera de savoir qui est "google.com" et tous les autres sur le réseau), supplantant le serveur de votre ISP ... Ce qui ne serait pas bien grave si ce brave petit routeur WiFi avait la puissance et la mémoire nécessaire pour faire ce boulot ...

Résultat: une navigation ralentie par de longues attentes sur des noms par rapport à une connexion directe avec le modem de l'ISP. Que faire ?
Première chose, apprendre l'adresse du fameux serveur DNS (serveur de nom) de votre ISP. Jetez un coup d'oeil au fichier /etc/resolv.conf ... s'il renseigne "nameserver 192.168..." ou "nameserver 10.0..." (qui sont des adresses IP "locales", utilisées uniquement derrière ce genre de routeur-pare-feu), c'est qu'effectivement le routeur sert de serveur de noms. Réessayez alors sans le routeur, et vous aurez peut-être droit à quelque-chose comme "nameserver 123.56.1.1", que vous vous empresserez de copier sur un post-it (c'est le serveur de nom de votre ISP ... le vrai). (PS: vous pouvez sans doute aussi apprendre ça en interrogeant l'interface Web de votre routeur ou en retrouvant dans votre fouilli le contrat de l'ISP ;)

Rebranchons notre routeur, maintenant, et une fois le réseau prêt à fonctionner, éditons comme un grand sauvage le fichier /etc/resolv.conf (à coup de sudo, bien sûr) pour remplacer "nameserver 192.168.1.1" par "123.56.1.1", par exemple ... Est-ce que la connexion a l'air de se faire mieux ? Si oui, c'est qu'il y avait bien un soucis de DNS ...

Evidemment, ce serait trop simple que cela suffise. /etc/resolv.conf est un de ces fichiers qui est écrasé à chaque démarrage par le client DHCP (celui qui demande au routeur gentillement de lui donner une adresse et de s'ajuster au réseau et qui vous permet du coup de vous ballader du bureau à la maison sans vous poser trop de questions). On va donc devoir aller éditer cette fameuse config DHCP (dans /etc/dhcp3/dhclient.conf sur mon ubuntu), le truc étant d'utiliser la commande "prepend" pour forcer une configuration statique à prendre le pas sur la config automatique.

send host-name "";
#send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
#send dhcp-lease-time 3600;
#supersede domain-name "fugue.com home.vix.com";
prepend domain-name-servers 123.56.78.1;
prepend domain-name-servers 123.56.1.1;

et voilà. Les "sudo /etc/init.d/networking restart" n'auront plus raison de notre beau resolv.conf ...

PS: c'est geek, hein ;) oui, je sais, c'est plus simple quand il y a des cases à cocher, mais à défaut, on a un peu appris comment ça marchait ;)
PPS: oui, j'ai finalement moins bricolé ma DS pendant ma première semaine en Suisse que je ne l'aurais cru ... et je n'ai pas senti le besoin de blogger les petits progrès qui avaient quand-même été réalisés ... d'où un blog un peu plus calme, ne vous en déplaise.

Friday, September 26, 2008

Screwed up terminals: the solution

Anyone who has been doing C programming on Linux has encountered this at least one, or is a very rigourous programmer. A certain binary sequence (that you normally never encounter in ASCII text, but that might be present in that binary file you accidentally dumped on your terminal) will switch you to the "graphical and lines" character set where everything gets completely unreadable.

Si vous programmez sous Linux ce genre d'écran illisible ne vous est forcément pas inconnu. Tôt ou tard, vous (ou un de vos collègues) a forcément malencontreusement envoyé un fichier mp3 ou une image ou un programme sur la sortie du terminal et pas de chance: il contenait cette petite séquence ANSI qui force la console à passer sur le jeu de caractères graphiques, utilisé entre autres par ncurses pour dessiner ses boites et ses menus.

It was fairly easy to fix under SuSE and RedHat back in Y2K as a simple "reset" command typed on the terminal restored the display. Unfortunately, ubuntu Linux distributions do not seem to think a terminal reset should include reset the character set to its default value...

It occurred once again today. Once too much. I dug the ANSI commands set and wrote a small perl tool that let me toy with ANSI escape codes. Here it comes: ANSIHACK.PL (in uppercase so that you can recognize it even when your terminal is screwed :P)

#!/usr/bin/perl
print "\x1b($1\nMODE $1 ENABLED.\n" if $ARGV[0]=~/\-\-SET([0-9A-B])/;
print "\x1bc\x1b(A" if $ARGV[0] eq '--RESET';
shift @ARGV if $ARGV[0]=~/^\-\-/;
print "\x1b[$ARGV[0]\n";
print "done/DONE.\n";
exit(0);
Actually, the commands that trigger a charset switch are Esc(x and Esc)x. Charset A is our default, regular 'ascii' charset (used in --RESET form) but you can also toy with other charsets (B, 0, 1 and 2) with e.g. ANSIHACK.PL --SET0 (that screws things up) and ANSIHACK.PL --SETA (which restores things to normal).

C'était assez simple à résoudre du temps de SuSE et RedHat (tapez 'reset' en aveugle, puis appuyez sur ENTER les doigts croisés en sautant sur un pied un soir de pleine lune avec un baton de réglisse entre les dents). Mais sous ubuntu. Rien. reset efface le contenu du terminal, mais ne résoud pas le problème qui nous occupe. D'où ce petit script pour jouer avec les commandes ANSI. Les vieux de la vieille pourront se faire un alias reset='bin/ANSIHACK.PL --SETA' ;)

|-|oPe !7 |-|e|_p$ ;)

edit: the real explanation is that a '0x0e' character (shift out) had been issued and only a '0x0f' character (shift in) would bring the default charset. The ANSI hack almost works, but it screws up the '#' character into some £...

Tuesday, September 23, 2008

Biokid NT : countermeasures

Quelque part en 1996, mon frère Piet me pond une storyline un peu abracadabrante inspirée d'un vieux souvenir (le Stoner): votre PC est infecté par le terrible virus Terminator 007. Le seul moyen d'en venir à bout, c'est le nouvel anti-virus interactif de PPP Team Software: Biokid.

Back in 1996, my brother's mind give birth to a curious story: your PC is infected by a dangerous virus -- the Terminator 007 -- and the only thing that can get rid of it is the brand-new interactive antivirus from PPP Team Software: Biokid. To put it simpler, Biokid is a crossing over between Megaman character and Commander Keen level design where you hunt for keys and weapon upgrades in maze-like platformer. It turned into one of our best production on RSD Game Maker.

L'idée, c'était de tenter de s'approcher du gameplay d'un Megaman. Mais là, j'ai envie d'un petit jeu au principe plus simple (un shoot'm'up) que Bilou pour roder un peu mon Game Engine, et plutôt que de ressortir Bilou Sky Quest (C64) ou d'essayer un portage de Out'm'up (assembleur, Y2K), je me suis dit que j'allais ressortir Biokid dans un nouveau mode de jeu: "Counter Measures".

Plus question d'assurer passivement la défense de votre réseau: Biokid prend les devant et part vaillamment à l'assaut du plus grand Botnet qu'il vous a jamais été donné de combattre.

I was thinking of giving my game engine for DS a try in a different setup : a shoot-m-up. I could have reused "Out'm'Up", our brain-free shooter that won the 100K game competition at Inscene Y2K. Or I could have revived "Bilou Sky Quest", the test game I made on C64 with the "Shoot-Em-Up Construction Kit". For some reason I started dreaming of a shooter featuring Biokid who'd now have to protect your corporate network proactively and fight the largest and scariest Botnet ever fought. (hmm. I could have been "inspired" by the Bionet EU project a colleague of mine is working on, btw).

edit: bon, comme vous le voyez, côté graphique, il y aura du boulot ... je voudrais recréer une ambiance "newschool" inspirée de Matrix, Tron et autres Space Invaders Extreme ... on verra ce que ça donne ...

Monday, September 15, 2008

Programmatically surrealistic

Earlier in the day, i had an argument with the update-manager of my test machine who was refusing to update my Dapper Drake because of some "hash mismatch" at the mirror. For some reason, i didn't trust the ubunutu forums that state that "this occur when you try to update while mirrors are synchronizing" and finally discovered that the way hashes (that confirm your softwares' authenticity) are managed has changed with Hardy Heron ... Doh. Fortunately enough, someone is still thinking that some user prefer to update from a text console rather than having a "user-friendly" graphical interface but only at the cost of burning a new ISO distribution and moving your feets two level down in the lab.

So my thanks fly to the maintainers of the update-manager-core package and the sudo do-release-upgrade -m desktop trick that did the whole upgrade without pop'ing any window and without silly hashing bugs.

You thought that would have been the weirdest thing around? You were wrong.

With the machine updated, i'm now able to test the new release of that European project i'm working on ... The software has a thing called "the minmex" which spawns thread for various sub-tasks and i thought it would be handy to catch those "logfile " lines it produces on stdout, and process them in a script that would automatically start following each new log. Easy as (s)hell :


# invoke this as:
# sudo bin/minmex | perl myscript.pl
while ($_=) {
print;  # just echo back the filename
chomp;
sleep 1; # just let the minmex actually create the file
system "tail -f $1 &" if (/logfile (.*)/);
print "waiting for more ...\n";
}


Except it didn't worked. Only the "master thread" displayed something. Of course, running a plain "sudo bin/minmex" show you all you wish to know on the console :-/
And of course, as usual with the latest libc6, you don't even see any write(1, ...) in the output of an strace bin/minmex. My colleague Cyril supposed something odd with termcaps, but there was absolutely nothing that sophisticated in the minmex. Just a very plain printf("logfile %s"); ...

Fairly puzzling, don't you think ?

Well, now it started getting funny when i realised that i actually was facing this in the 'master' thread:

mkdir("/tmp/log", 0777) = -1 EEXIST (File exists)
fstat64(1, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf97285c) = -1 ENOTTY (Inappropriate ioctl for device)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f7f000
write(1, "logfile /tmp/log/26274_"..., 71logfile /tmp/log/26274_anaMinmex
) = 71
brk(0)                                  = 0x806b000
brk(0x808c000)                          = 0x808c000
open("/tmp/log/26274_anaMinmex", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
.

I'm not very comfortable with those termcaps things, but that ENOTTY error clearly suggested that Cyril was right and that the source code was wrong 0_o ... Using plain write(1,...) instead of printf(...) let me see all the stuff i wanted, but that can hardly be called a solution. After a bit crawling in the sourcecode of libc6, i could not find any direct relationship between tcgetattr (the function using that TCGETS argument) and printf, but some reference to glibc-2.6.1/misc/getpass.c did ring a bell in my mind ...
What if the problem was actually coming from the sudo not liking me to redirect the program's output ? what if, for some reason, it *had* to ensure the access to a terminal (e.g. to prompt me for a password) and failed to properly restore the output-to-next process ?

And indeed, running the whole chain in a regular root session has now shown a perfectly regular behaviour, in other terms:
  • either you shouldn't try to redirect stdout when using printf
  • or you shouldn't try to build multitasking programs
  • or you shouldn't try to run those programs as a sudoer
  • and you certainly shouldn't do all these three things "for chaos and maddness awaits thou at thee end" ...
For your mind's sanity, i just hope that you'll never ever find such a post useful. But in case you happen to struggle with such a debugging nightmare, i hope i've got a sufficiently high pagerank to get ahead all these mailing list that discuss about whether a bug is a bug or not and that you'll get a clear understanding of the situation faster than i did...

HAve a nice day,
/Pype, the crazy coder.

edit: the problem seems to be tcsh-specific (e.g. doing the plain sudo bin/minmex | perl myscript.pl in bash will work) and there are two possible (and both equally surrealistic) work-around for those who don't want to switch to bash:
  • sudo -c tcsh "bin/minmex | perl myscript.pl"
  • sudo -c tcsh "bin/minmex" | perl myscript.pl
I'm accepting any explanation for this, and myself strongly suspecting tcsh to do something wrong when building the pipes between minmex and perl...

Friday, September 12, 2008

Model, View, Controller

Tout à commencé par ED, l'éditeur le plus imbuvable que l'on puisse imaginer (à moins que l'on ne soit un VIMeur auquel cas le pire éditeur possible est évidement EMACS :).

Au commencement, il n'y avait rien que des 1 et des 0
et le souffle d'ED qui planait au-dessus du tout qui n'était rien.
Puis ED dit "# Que le Code soit"
Et le Code fut.

ED sépara les Données du Code;
Il appela le Code ".text" et les données ".stack"
Et il vit que c'était bon.

Bref. Tout ça m'a amené à télécharger la chanson Model View Controller sur le blog de Peteris Krumins. Non seulement c'était bien drôle, mais je crois que c'est l'explication la plus claire du modèle "MVC" qui m'ait jamais été donnée de lire (et écouter). Au départ, j'avais plus ou moins tenté de respecter ce modèle dans la construction de SEDS, quoi que la plupart du temps le "modèle" n'était que des données brutes ... un tableau de bytes ou de shorts dont le rendu est assuré par les widgets.
Model objects represent your applications raison d’tre.
Custom classes that contain data logic and et cetra.
You create custom classes in your app’s problem domain,
then you can choose to reuse them with all the views,
but the model objects stay the same.

Les "fenêtres", elles, assuraient la "glu": c'était mes contrôleurs. Mais là, ça ne va plus du tout. Je me retrouve avec ma fenêtre "éditeur en grille" qui commence a avoir des méthodes "remplir_grille(un_sprite)" ou "remplace_couleurs(une_couleur, autre_couleur)" sans parler de "affiche_tiles_utilisant(une_couleur)" etc.

Bref, il serait sans doute temps de promouvoir le tableau affiché par la Grille en un objet à part entière, et idem pour la palette ... Ca m'éviterait, soit dit-en passant, de copier/coller le code de "affiche_tiles_utilisant(une_couleur)" pour avoir la "méthode" "tue_les_couleurs_inutiles()" sur l'éditeur de palette.

edit: en fait, non. La majorité de SEDS n'a rien à voir avec du MVC. Ce serait presque l'inverse, en fait ^^"
Il faut dire que (paradoxalement), la programmation d'interface graphiques dans les règles de l'art, j'ai toujours trouvé ça chiant comme la pluie >_<

Et pour ceux qui se demanderaient toujours dans quel cerveau dérangé un outil aussi anti-ergonomique que ED a bien pu germer ... regardez donc cette antiquité, encore commune au temps du dévelopement d'Unix: le terminal teletype. Remis à jour pour s'interfacer par RS-232 avec Linux.

On ne sait pas "effacer" de caractère avec ce truc. On ne sait même pas se déplacer de haut en bas dans l'écran. La seule interface, c'est la ligne en cours. On aurait aussi bien pu fonctionner avec des numéros de lignes, façons MS-BASIC...

Wednesday, September 10, 2008

Sharp lane pour moi

L'application tomboy devient de plus en plus un élément central de mon activité professionnelle. Ce n'est plus simplement un moyen de me faire des todo-list, mais c'est devenu à la fois la "fournaises à idées" où je prépare mes articles, un substitut à mon ancien "meta-do comment" pour conserver mes réflexions à propos de mes lectures, et même dernièrement ze moyen de corriger les TP des étudiants.

Bref, tomboy (l'éditeur de post-it) est devenu mon blog non-publié ... mon wiki perso. Si bien que je voudrais pouvoir commencer à bricoler un peu autour ... annotation d'image, lien vers des fichiers, intégration avec mon outil "doclocate", etc. Je m'attends donc à me lancer dans la programmation mono (c#) d'ici peu ... Avec comme premier contact un "gmcs not found" lors de la tentative de ./configuration du bazar. Heureusement, depuis mes premiers pas dans RedHat 5 et SuSE6, la gestion des packages sous linux a méchamment évolué. J'enfile donc ma toge de guru et déclame un

$> sudo apt-get build-dep tomboy

et mon gibbon, si vaillant soit-il, ne peut faire autrement que de me demander la confirmation des 65MB de bibliothèques, compilateurs et autres qui vont faire de beetle une bête de développement mono. Quelques instant auparavant, un simple
$> apt-get source tomboy
avait suffit à obtenir les dernières sources de l'application telle que je l'utilise.

En comparaison, j'avais essayé en 2001 de compiler moi-même gnome, qui manquait alors sur ma SuSE, et après de vaillants combats avec le Gardien des Parchemins (traduisez scrollkeeper, un obscur gestionnaire de config pour gtk/gnome), j'étais bon pour réinstaller tout mon serveur X avec la SuSE suivante ...

Bref, je n'ai plus qu'à arriver à éditer un billet sans repasser en mode HTML et je serais définitivement 21eme-siècle-ready.

et si ça vous a plus, vous allez adorer les incantations magiques de Drake dans le webcomic 0xbabf000L, malheureusement en veille

edit. J'ai eu droit à un cryptique The following assembly referenced from Tomboy.exe could not be loaded en essayant de démarrer le programme compilé. Je crois que j'irai voir quelques liens histoire de rattraper mes années de retard :P

Tuesday, September 09, 2008

Color Reduction.

au centre: mon arbre, sans les couleurs inutiles; à gauche: mon arbre, revu et corrigé par Helm; à droite: j'essaie d'appliquer les conseils de HelmA nouveau, ma palette de couleur est devenue quasiment inutilisable. J'ai bien un outil de "réorganisation" efficace pour construire des dégradés, mais à force d'importer et de réimporter les pixels depuis mes bricolages dans Gimp, je me retrouve avec 3 ou 4 instances de la même couleur (à quelques variantes près, voire exactement les mêmes). Bref, l'arbre que j'avais soumis faisait 28 couleurs, alors qu'il n'y avait que 16 teintes vraiment uniques (au centre). Ce n'est qu'après cette étape de "réduction du nombre de couleurs" qu'on peut commencer à jouer sur le contraste des éléments (à droite) pour arriver à ce que Helm proposait (à gauche).

Je ne suis pas pour la réduction du nombre de couleurs à tout prix, mais là, j'avoue que ça devient ingérable. Trop de micro-variation sur la même couleur, je ne sais plus laquelle utiliser quand ... Bref, si je veux pouvoir continuer à faire des mockups facilement, à ajuster les niveaux de contraste, etc. , il faut que je bricole quelques nouvelles fonctions dans l'éditeur de palettes.

Once again, my palette is a big mess, which makes my art more and more difficult to manage, since some colors do not fit any raster any longer ... If i want to save hours of "clean up" duty when publishing a mock up, i'll have to improve the palette editor too ...

  • [done] zap unused colors in the palette.
  • click on color in the preview, and see where it is on the palette
  • R recalls the former color (undo) ?
  • swap mode for the PaletteEditor widget
  • [done] click a color in the palette and see on the upper screen the n first blocks featuring that color
  • [done] flashing the color for easier identification. This happens on the spritesheet only (not on the grid, nor on the lone tiles) when you hold on the color square.
  • split the color square view out of the Palette widget, though, to be implement flashing correctly
  • [done] after such identification, allow color to be replaced by another one. (but only the grid is modified)
  • [done] fix block mode
  • [done] fix overlay-loading
  • remember grid size when switching windows
  • [done] provide some "undo" for accidental (misplaced) R-R combos.
  • [now] fix imlib2spr script so that it picks the *closest* SNES color for a given RGB color (not simply killing bits) and that it kills redundant SNES colors (even if they differ in the initial RGB space)
  • [now] allow spr-addpage tool to understand the "extra tileset" ... and do a major rewrite of that tool to ease further development.
Parmi les outils manquant, identifier les tiles qui utilisent une couleur donnée est évidemment primordial ... Vient ensuite la possibilité de remplacer cette couleur par une autre. Curieusement, ne lister que les tiles véritablement utilisé se révèle plus complexe que prévu.

Monday, September 08, 2008

Gravity Hook

Quittons un moment le monde du homebrew pour nous intéresser à ce qui a été rebaptisé le "casual gaming". Un phénomène prétendument nouveau qui existait déjà en 1980 (pensez à Frogger, Congo Bongo, Pooyan ...) d'un jeu pas prise de tête, dont le gameplay est axé sur un ou deux mécanismes faciles à expliquer et dont l'intérêt principal réside dans la table des highscores. Oui, en gros, un jeu d'arcade mais sans le monnaieur.

Bref, voici un petit jeu tout simple, mais au gameplay inédit (à ma connaissance) où vous allez devoir, tel un Spiderman acharné, grimper toujours plus haut en vous accrochant à des espèces de mines anti-gravité qui vous propulseront toujours plus loin, toujours plus haut. Mais si jamais vous heurtez une mine ou que vous redescendez trop bas (l'écran ne vous suit jamais que vers le haut) c'est fini. c'est le game over assuré.

Tout ça avec du tout bon pixel art de Adam Atomic, sur une petite musique chippy et un concept de Arne (l'homme à la palette magique). Allez, laissez-vous tenter.

You may call it "casual gaming", i do call it "quarterless arcade games". Anyway. AdamAtomic released a nice little game (that i wish i could run as a homebrew on my DS) where you have to swing from node to node to climb up an apparently endless pit. A fairly novel gameplay that is easy to learn and hard to master, but definitively fun to play.

Beware, though: those apparently helpful nodes turn into deathly mines as soon as you hook on them, so you'll have to get as close as possible, but not closer.

Or read the whole story on Pixelation board.


edit: si vous êtes plutôt "développement flash" que "DS", Adam nous a offert flixel, le moteur avec lequel Gravity Hook avait été programmé. Merci qui ? ...

Saturday, September 06, 2008

Bilou relooké : les résultats.

Bilou il y a 1 anVoilà donc, le look qu'avait Bilou quand j'ai démarré ce blog. Je partais d'une planche de sprites construite en 2001 avec la palette de Tyrian pour essayer de transformer mes petites BD en animations 320x200. Tout naturellement, dès les premiers pas de SEDS, j'ai bien vite converti ce PCX en nouveaux .spr pour la bidouille.

Tout impatient que j'étais d'avoir un moteur de jeu fonctionnel, j'ai assez peu travaillé l'aspect graphique de Bilou lui-même (allant jusqu'à attendre d'avoir un programme d'animation "à la rayman" pour lui ajouter pieds et mains). Entretemps, je découvrais le forum 'pixelation', et donc quand est sortie la première démo de mon moteur de jeu et que j'ai enfin réussi à en prendre une vidéo (via l'émulateur), j'ai tout naturellement posté ça sur le forum pour avoir un avis sur le graphisme ...

When i started this blog, Bilou's look was just as you can still see him on the top banner, about to land on the tree trump. This post relates the long process of improving my graphic skills following the advices of people on 'pixelation' board, and how it led to the design i'm using from now on. A small poll revealed that 71% of my "readers" love the new one. At least it wasn't time lost. Since you can read english, you have no need for me to translate the story: you can directly follow the forum's thread here ;)

Bilou, vu par ZeidBin, au départ, ça a été assez dur d'encaisser le "encore moins intéressant que Kirby", de AdamAtomic, mais assez rapidement, Zeid a proposé un relookage complet de Bilou, plus axé 'pixel art' (moins de couleur, mais plus de contraste) j'ai hésité. Ca n'avait plus rien à voir avec mes pixels d'adolescent, mais ça en jettait! Bref, complètement indécis, j'ai décidé de tenter le coup et de vous demander par la même occasion, à vous, chers lecteurs, quelle version avait votre préférence ... Un sondage de deux mois sur 35 participants dont voici les résultats:
  • 71% de "j'adore"
  • 17% de "mieux"
  • 5% de "bof"
  • 5% de "laisse tomber"
Bilou aujourd'hui ...... avec un peu de 'subpixel' dans la coursePlutôt encourageant, donc. Evidemment, entretemps, c'est presque toute la forêt qui a été remaniée, et je n'ai pas encore fini, loin de là. Un nouvel arbre est né, régulièrement relooké, puis un appleman dodelinant ... Révision de l'herbe, du sol, des couleurs du décor... tout y passe en fonction des évolutions de SEDS, bien que je me permets parfois des bricolages dans the Gimp pour chercher les bons contrastes, faire les montages, etc. L'un dans l'autre, le principe des éditions "tu pourrais faire mieux, regarde" me fait pas mal progresser, même si j'ai encore fort tendance à me justifier d'abord et à retravailler ensuite. Par exemple :
les monticules, revus par Lackeyréduction de couleurs par victorXPixelaroo augmente le contraste des arbres de Lackey
En vrac, de gauche à droite, les retouche de lackey, victorX, encore lackey réédité pixelaroo. En dessous, des modifications plus récentes dûes à arachne et zeid que je suis toujours en train d'essayer d'intégrer.

L'arbre, revu et corrigé par ArachneJ'ai eu assez peu de commentaires des participants (et c'est de bonne guerre) et j'avoue que j'ai été un moment perplexe par les votes "laisse tomber". J'imagine a posteriori qu'il s'agit de personnes qui considèrent qu'une balle bleue ne vaut de toutes façons pas la peine d'être un personnage de jeu vidéo (cf. Lololo et son chateau) et que je ferais mieux de m'orienter vers un autre genre de personnage. Zeid pousse le volume Mais comme je suis sentimental, je vais quand même garder Bilou ... Avec un peu de chance, ses détracteurs pourront jouer en incarnant Bouli à la Casquette Magique ... d'ici un bon paquet d'années ^_^

Mes pixels (ou presque), les couleurs de HelmPS: alors que je pensais avoir compris la technique d'Arachne pour les feuilles, c'est au tour de Helm de me faire remarquer que mon choix de couleur reste trop plat, pas assez contrasté pour un avant-plan de jeu... Bref, il faut que je fasse le ménage dans ma palette et que je re-bosse mes couleurs...

Recreational Game Maker

Après les éditeurs Borland et Quickbasic, voici probablement l'écran que j'ai le plus vu pendant mon époque "MS-DOS". L'éditeur de blocs du Récréational Game Maker. Une de mes références (en particulier du point de vue de ce qu'il ne faut pas faire) pour SEDS et les autres éléments de mon "game maker pour DS" à venir ...

Premier reproche: la palette. Avec un pixel de large par couleur, c'est quasiment impossible de prendre la couleur recherchée du premier coup. Il faudra peaufiner avec les touches [+] et [-] le plus souvent. On aura droit à deux couleurs (bouton gauche et bouton droit) comme sur la plupart des éditeur graphiquesde l'époque ... et il faudra aller cliquer sur la case avec la couleur en question qui se mettra alors à passer toutes les couleurs en revue jusqu'à ce que vous cliquiez quelque-part sur l'écran ... tu parles d'un truc intuitif !

I've been spending *hours* on those screens ... Recreational Game Maker has been both a way to experiment more games than i could program myself, but also the program that made me realising that i wish to run my own (ultimate) game maker at the end of the nineties. Most of the user interface was absolutely horrible to use, left very little room for mistakes (e.g. no undo feature except re-loading a tilesheet and saving often) and led to fairly blocky object design. Somehow, it is my reference on "what not to do in [SGL]EDS".

L'outil que l'on retrouvera sans doute le plus, c'est cette liste déroulante de blocs dans laquelle il faut aller pêcher le bloc qui nous intéresse. Assez pratique quand vous avez les blocs de plusieurs niveaux dans un seul "bloc set", dès que l'on complique un peu les niveaux, en revanche, ça devient rapidement une horreur absolue ... On passe plus de temps à regarder défiler ses blocs qu'à véritablement construire son niveau, si vous voulez mon avis!

Autre défaut à mon avis, l'omniprésence du glisser-déplacer. Vous voulez choisir un bloc à éditer? déplacez-le vers la grille. Vous voulez le 'déplacer' dans la liste des blocs ... de nouveau, copier/déplacer. Même l'écran de réglage des paramètres fonctionne entièrement ainsi. Ecran qui en-dehors de ça n'était pas mal fait, d'ailleurs, donnant assez bien de flexibilité avec ses "special counters" (en fait, des clés), les hit points, les blocs générateurs de monstres ou animés ... Croyez-y ou pas, mais quand il s'agissait de créer un boss, c'est le plus souvent ici que tout se jouait, grâce au fait que le contact bloc/perso était géré indépendamment de l'animation du bloc ...

My #1 rant on that software was about monsters management. Basically, a monster had a single animation sequence and a single movement pattern (though it could have a separate "attack pattern" when player comes close enough). The only way to build more sophisticated monsters was to "chain" them once killed. That meant that they could not change their behaviour on their own without being indestructible and (vice-versa) that they couldn't require several hits without having their state reset while switching to their new animation/pattern.

They couldn't shoot either (though i managed to have bosses transforming harmless, almost-invisible dots into deathly fireballs later on, but only at the expense of complicated monster/room inter-dependencies), nor could they detect when they were stopped by a wall (but they stopped nonetheless) or that they were walking in the sky. Most of my "state machine scripts" in the current GEDS engine are designed to work around those limitations and still allow graphical edition... yet i have no graphical editor so far :P

Là où j'ai plus galéré, c'est avec l'éditeur de monstres. Au départ, les blocs sont créés tout à fait normalement (mais avec une couleur de transparence quand-même). Il faudra alors construire des séquences pour animer tout ce petit monde (heureusement, l'éditeur de blocs nous avait déjà permis de tester des animations, mais il faudra les reconstruire ici. Pas de chance.

Le "comportement" de ces monstres sera définit d'abord par "quand il est touché, il se transforme en ...", ce qui permet explosions et compagnie (le plus simple) mais aussi des effets plus intéressants, comme de rendre le monstre "furieux" et de le faire courir droit devant lui s'il est touché. Le joueur aura alors intérêt à être rapide pour tirer encore. A noter aussi que ce sera le seul moyen d'avoir un monstre qui nécessite plusieurs coups pour être éliminé définitivement.

L'autre point-clé, c'est cet espèce de "radar" dans lequel on va définir la succession des mouvements (genre trois blocs en avant, trois blocs en arrière, trois blocs sur le côté, trois blocs de l'autre côté ... Il était une bergèèère qui allait auuu ... euh ... pardon, je m'égare). Le hic, c'est que tout celà se détermine de manière complètement indépendante des maps. Il faudra donc être particulièrement vigilant à la longueur que l'on donne à nos plateformes si l'on ne veut pas qu'un monstre se mette à marcher dans les airs, car s'il sont capables de ne pas rentrer dans les murs, rien n'a été prévu pour les obliger à rester au sol, ni à faire demi-tour dès qu'un mur les arrète (on se retrouve alors avec un monstre occupé à faire du sur-place pendant deux secondes avant de se retourner).

Voilà. Il y aurait beaucoup d'autres choses à en dire, j'imagine, mais j'ai d'autres projets pour le week-end. Je vous laisse donc avec ce petit screenshot de Twinbee Land, collaboration de Pascal Deiting et moi-même à l'époque ... Un tileset de base que j'avais dessiné pour Badman II et qui a eu la vie dure, vu le nombre de jeux dans lequel on l'a retrouvé :P

Read the whole story on "my RSD game-maker years" side-page

Friday, September 05, 2008

Text around figures in Latex

It gave me headaches, but finally i got it working. I discovered this morning that Computer Networks required pictures and bios of the authors, and that the elsarticle.cls latex class did not provide any standard mechanism to build these (not mentionning that my bio so far was entertaining, but absolutely not scientifical at all).

i finally used the warpfig package (preinstalled) in this way :

\begin{wrapfigure}{l}{1in}
\includegraphics[width=1in]{SMA.eps}
\noindent \hrulefill
\end{wrapfigure}
\input{biosylvain}
now let's see if that is understood by the editor's auto-generated pdfs ...

User-friendly

Petite release pour moi, milestone pour l'humanité (enfin, peut-être. L'avenir nous le dira). J'essaie de rendre SEDS plus "grand public". Exit les messages de debugging abscons (enfin, j'ai toujours moyen de les invoquer grâce à mes méditations de gourou, mais vous ne les verrez plus) et du coup, la "console" est libre pour donner à l'utilisateur des petits conseils "tutoriels" sur l'utilisation du logiciel en appuyant sur L et R simultanément (oui, Cyril, ça marche aussi si tu appuies sur R et L, maintenant ;).

Au passage, ce sera aussi la première release avec l'éditeur de palette.

Small step for me, milestone for humanity ... maybe. I'm trying to make SEDS more user-friendly, mostly by hiding all the debugging messages that noone cares about and replace them by some "tutorial" messages that teach you step by step how you can do pixel art with my little homebrew.

So if you're wondering "how am i going to do xyz", try pressing L and R simultaneously, and you should enter tutorial mode. By the way, it's also the first release featuring a decent palette editor.


download SEDS 0.3.3
vu sur dev-fr


note: Xelados from Pixelation boards provided a couple of reflections on the UI. I'll have to go through them once i resume development on SEDS.

Wednesday, September 03, 2008

.spr

Okay. Let's say you've downloaded the latest SEDS version and gave it a try. You loved the pixel art you've drawn and hopefully pressed START + R + A to save them on your media card. Then you either transferred them with runme or simply used a media card reader to retrieve them.

SpriteA.spr at the card's root. Most likely to be your drawings. As a matter, it is.

But what are you going to do now with that .spr file that your file explorer doesn't know and that do not open in Graphics Gale, Photoshop or whatever other spriting program you could think of.

If you are a "power user", you may already have
perl installed or find it not that complicated to install. In that case, you're suggested to install the Image::Imlib2 package as well so that you can run spr2png.pl conversion script directly on your machine and have your sprites converted in a more user-friendly format.

If you're just a regular user, or if you haven't used SEDS often enough to find it is worth that much installation trouble, you still have an escape route: the brand new online conversion tool that can convert your art into a regular .png file with just the help of a regular web browser. Just select the picture with the "browse ..." button, click "post" and wait a couple of seconds to have the script doing the conversion and replying with the picture.

Have Fun ... i also submitted a "job offer" on sourceforge to find someone willing to write a batch conversion tool for Windows ... wait'n'see.


Costz dit : Mais on peu récup les sprites dans un autre format que le tien ?
Je veux dire y a un convertisseur pour que l'on puisse avoir au final une .png ou .gif ?


Oui, tout à fait. Il y a tout d'abord le script spr2png.pl qui, moyennant installation de perl et du module Image::Imlib2, permet de convertir tout ça localement sans soucis.

Et pour ceux qui auraient du mal à installer tout ça sur un Windows (sous linux, c'est juste apt-get install libimage-imlib2-perl), ou qui voudraient tout simplement essayer le sprite editor sans se prendre la tête, j'ai bricolé un convertisseur en ligne: tu uploades ton .spr et tu reçois le .png en échange.

PS: j'ai les sources en Perl du convertisseur et une esquisse du format de données avec le convertisseur en ligne. Je cherche quelqu'un qui connaisse la programmation windows (C, C++, VB, C# : tout est bon) pour écrire un convertisseur "user friendly" pour les wutilisateurs.

Si vous êtes partant, contactez-moi : pype_1999.geo@yahoo.com.

Monday, September 01, 2008

En couleurs ...

Pour un week-end aussi chargé que ces derniers jours d'août passés à rentrer les foins à Stoumont, je ne suis pas trop mécontent d'avoir eu le temps de bricoler une petite fenêtre d'édition de couleurs assez convaincante... enfin, nettement plus que tout ce que j'avais fait jusqu'ici, avec une prévisualisation immédiate de l'effet du changement de couleur, des glissières au comportement plus intuitif, et surtout une synchronisation entre édition en RGB et en HSV.

Evidemment, j'avais oublié le bouton "oui, j'aime bien, je veux utiliser cette nouvelle palette maintenant", donc pas eu la possibilité de jouer avec les nouvelles couleurs :P

There was quite some stuff done IRL this week-end and yet I managed to craft some satisfying color edition widget. Much more convincing than my previous attempt, at least. This time, we have real-time preview of what new color will be and how it integrates in a test sprite. There are intuitive (?) sliders to use and simultaneous update of RGB and HSV sliders. It just lacked a 'neat, let me draw with this great new color'...

Evidemment, le fait que le boulot sur le R4 ait aussi permis d'utiliser à nouveau desmume sans bloquage me simplifie méchamment la vie pour le test de tous ces nouveaux widgets ^_^

Prochaine étape: les dégradés.

Friday, August 29, 2008

montre moi ta VRAM et je te dirai qui tu es ...

Sans doute juste une curiosité pour vous, mais de plus en plus important pour moi : voici le contenu de la mémoire vidéo de mon SpriteEditor, vu sur un plan "16 couleurs" (1KB par ligne) à gauche et sur un plan "256 couleurs" (2KB par ligne) à droite.
Du temps du DOS, j'avais refais et plastifié sur un carton de 16x16 centimètres la table ASCII pour mes programmes en BASIC et en assembleur. J'ai d'ailleurs eu droit à du "oh! great! Can i borrow you your mouse pad ? please ?" en pleine démoparty parce qu'un gars qui passait par là avait bigrement besoin de ces infos pour continuer son intro 4K.

Les vieux de la vieille reconnaîtront pas mal de ce jeu de caractères, d'ailleurs, même si j'ai remplacé les symboles "coeur, pique, trèfle, carreau" par une animation de pacman qui me sert de 'scrobber' et que vous reconnaitrez à partir de la 4eme ligne quelques éléments de l'interface de SEDS (accessibles à l'aide de YOUR_CHARSET(0), et programmés à grand coups de codes hexa ... ça rappelle des souvenirs de CPC, ça, hein ;)

Version 256 couleurs, évidemment, ça ressemble furieusement à ma palette, puisque -- souvenez-vous -- j'avais reprogrammé un caractère par couleur pour pouvoir redessiner facilement ma grille ...

Il y a des curieux qui se demandent ce que peuvent bien être ces 8K de n'importe quoi entre les caractères et les couleurs ?

Allez, je vous aide: il y a quatres plans sur un écran DS et chaque écran peut contenir 32x32 caractères encodés sur 16 bits ...

Thursday, August 28, 2008

"Use the Source, Luke"

La nouvelle structure de l'éditeur de palette commence à prendre forme dans mon esprit, mais avant de tout casser, cette fois, je vais profiter pour faire une petite "release sources" du sprite editor : version 0.3.2x32. Eh oui, c'est quand-même un projet Open Source (j'ai finalement opté pour du LGPL+GPL), donc il faut que je fasse une release source de temps en temps ;)

Pour mon frère et les autres qui ne pensent jamais à cliquer sur les images de mes articles (et ils ont bien tort), c'est ici, et pour ceux qui n'ont pas besoin des sources mais qui veulent quand-même essayer la dernière version, c'est (md5sum ba88e6b898297d5fe99a918f70c47f8e).

Combo release, with both sources and binary version of SpriteEditor for DS, version 0.3.2x32 with eased edition of large regions. This is of course motivated by the fact that the current palette edition 'window' is completely messy and is the next big thing to be revised. As the new interface is getting clearer in my mind, i found it was about time to release what's working before breaking everything into puzzling pieces again.

Tuesday, August 26, 2008

Messy Colors ...

J'ai essayé d'ajouter un petit mode de composition RGB "semi-graphique" dans SEDS, mais j'ai bien l'impression que je suis bon pour tout reprendre depuis le début. C'est foireux au possible. Complètement anti-ergonomique. La pire interface utilisateur que j'aie jamais conçu. 

Voyons. D'abords, un "load" est nécessaire pour choisir les couleurs que l'on va manipuler. on sélectionne et sauve des couleurs comme on le faisait avec les sprites, mais celà n'est qu'une zone à part. Il faudra cliquer sur un des "w8", "w16" ou "w32" pour réécrire 8, 16 ou 32 couleurs de celles que l'on a modifiées dans la palette d'origine et ensuite cliquer sur "ok" pour que le résultat s'affiche.

I want new colors in my sprite editor I tried to do something half-GUI to enter RGB colors, but I feel like I can redo from scratch: this is possibly the worst user interface I've ever designed.

  1. you cannot directly edit colors on the palette. Instead you have to click 'load' to fetch them, and click one of the w* buttons to write them back (8, 16 or 32 of them at a time) when you're done.
  2. when you've written back colors, you can't see the result yet. You'll have to click 'OK' to do that (and then you have no undo step available)
  3. You can't slide R/G/B fields to the desired values. You have to click the '+' or '-' button as many times as needed to get the value you want. And you better have to know what you want, since no feedback will show you what color it will give.

Comme en plus, j'ai des widgets "+/-" sans répétition, il faut compter une bonne vingtaine de clics pour éditer quelques couleurs ... en aveugle, évidemment. Ce n'est qu'au moment de cliquer sur "ok" (sans undo possible par la suite) que l'on saura l'effet de nos transformations sur les sprites. Bref, avant de jouer à rajouter les dégradés HSV, je devrai reprendre ça depuis le début, repenser le "workflow" et construire mon interface en fonction de ça, et pas en fonction de ce qui est simple à programmer.

Monday, August 25, 2008

SEDS 0.3 user guide

Here come some new features of SEDS in version 0.3.x. Note the "cursor mode" that can be enabled with R-shoulder button to load/save anywhere in the grid. Note too the "quick palette" widget below the grid that automatically fills when you L-click the grid to pick some color and which can be used to reorganize your palette after a messy conversion.

All the former commands are still available

Now officially released download here.

Seen on dev-fr, tehskeen, gbatemp, pdroms

Friday, August 22, 2008

Canon!

"Tiens, toi qui aime bien tout ce qui est embarqué, tu vas adorer ça", me dit Oli ... A priori l'appareil à l'air tout à fait normal, plus récent que le mien, mais c'est tout. "J'ai fait tourner mon algorithme de détection de fond dessus" ... Je suis paf! Du code custom sur un appareil numérique !? C'est possible ça ?

Voui, ma bonne dame. Ca s'appelle CHDK, et c'est principalement utilisé par les gens qui veulent pouvoir stocker leurs photos au format .RAW avec un appareil qui, au départ, n'est pas prévu pour ça... On peut aussi s'en servir pour jouer à sudoku, si on préfère.

I loved that era of the 8-bits where every device sold with a processor was open to homebrew development (or so it seemed). So discovering the first pocket calculator where you could run your own stuff, or the first PDA always felt awesome. But I was far from imaginating what my colleague brought me today. He's runnig his own custom code on a camera! Compared to the odds of running homebrew code on game consoles, he doesn't even have to tweak the device. A small code of your own dropped on the SD card will automatically hook into this or that behaviour of the camera's code, like what-happens-when-I-push the trigger, and voilà. Exactly the kind of things DOS games trainers did when hooking the clock interrupt to keep your lives count at their top.

Et le tout sans devoir altérer l'appareil, rien qu'avec un petit bout de code à soi sur la carte SD qui va aller détourner l'un ou l'autre comportement de l'appareil au profit des siens (le bout de code qui réagit quand on appuie sur le déclencheur, par exemple). Oui, exactement comme au bon vieux temps du MS-DOS quand le trainer de votre jeu favori s'insérait par-devant l'interruption d'horloge du PC pour pouvoir aller bidouiller la mémoire du jeu et garder votre compteur de vie à 99 en permanence quoi qu'il arrive (le jeu étant en général incapable de se rendre compte de quoi que ce soit, mais étant quand-même bien forcé de continuer à appeler ce code sans quoi l'heure du PC serait complètement fausse à la fin du jeu).

Après les consoles de jeu et les PDA, ce sont les troisième petits gadgets numériques que je pourrais bien avoir envie de bidouiller ... enfin, je dois avouer que vu leur capacités, je ne sais pas trop ce que je pourrais leur faire faire à part un "hello world". Lecteur mp3, peut-être, mais l'intérêt resterait limité vu la taille de mon powershot :P Oli, lui, il est dans le traitement d'image, donc c'est une véritable mine d'or "à gauche dans la mémoire, j'ai le capteur CCD, à droite le buffer d'affichage. C'est génial, me dit il, je fais ce que je veux".

N'empèche, je regarderai quand même en rentrant pour mon GPS ... des fois que ... Et le micro-ondes, aussi.

Thursday, August 21, 2008

CrocoDinguS in Cube Island

previously seen on http://www.dev-fr.org/index.php?topic=3673.msg33853#msg33853 and http://www.madpxl.com/crocodingus/screenshot_1.png

Je suis doublement fier: Crocodingus sort sur DS ! Et pourtant je n'ai rien fait (à part un ou deux commentaires sur les graphismes 2D de madpixel), mais je suis fier quand-même, parce qu'à ma connaissance, c'est le premier homebrew réalisé en collaboration entre un membre de "pixelation" et "dev-fr", deux forums dont je suis membre. (chapi) Chapeau, donc Birslip (code) et Madpixel (gfx) pour ce petit bijou qui nous prouve une fois encore que le homebrew, c'est chouette comme un commodore! J'aurais aimé avoir plus de contrôle sur la vitesse du croco, mais c'est déjà très chouette comme ça ^_^  

I'm twice proud, and still i've done nothing on my own. But here it is, Crocodingus in Cube Island, the first (to my knowledge) homebrew game made by a dev-fr coder teaming up with a wayofthepixel graphist. It looks good. It works fine. And it runs on a real gaming platform. It rocks. This proves once again that homebrew is a fun alternative to Flash casual games.  

ci-contre, photo bonus du projet initial en pixels bien 2D... oh, je n'avais vraiment pas changé grand-chose à la version de Madpxl, vous savez. Un petit détail par-ci par-là dans les ombrages du sol, ou qqch comme ça (genre, le sol sous Croco est modifié et celui sous les singes est l'original) ... Et oui, comme le faisait justement remarquer mon frère, je crois me souvenir que c'est en jouant à Zoo Keeper qu'il est venu à Madpxl l'idée de faire passer son croco dans un monde "tout cubique". Résultat, il est maintenant le deuxième reptile à s'être fait "avaler" par un jeu vidéo. Tout ça à cause d'un sprite renversé ... moi j'avais fait tomber du coke sur mon C64, et ça avait juste bousillé le C64. Je ne me suis jamais retrouvé nez à nez avec une saucisse géante ou un extra-terrestre unijambiste au langage coloré. Mauvais drink, sans doute...

Wednesday, August 20, 2008

zoOom zoOom

Bin c'est la semaine des bonnes surprises, apparemment. Je m'attendais à avoir du mal avec cette histoire de "zoom" et ça marche en fait comme sur des roulettes. du coup, je me suis amusé à animer mon petit "chibby keen". Bon, c'est assez sommaire comme animation, évidemment -- ça me change pas mal de mes Bilous -- mais ça ne donne pas si mal que ça, je trouve. Et le plus marrant, c'est qu'au départ je m'étais trompé, j'avais mis les mains en avant en même temps que les pieds. Bin je suis redescendu en "16x16" pour aller récupérer les bras et les changer d'image ^_^ It seems to be a good week for coding. I expected troubles and debug sessions darker than night when de-coupling grid size and block size, but it finally worked flawlessly in one shot. Neat. Using that, i managed to fix the "walking animation" i just sketched for my "chibby commander", using the 16x16 cursor to overwrite the arms of sequence 2 with the one of sequence 4 and vice-versa.

Tuesday, August 19, 2008

32x32 : ça y est (presque?)

Je vais éviter de crier définitivement victoire trop tôt, mais je crois que cette fois-ci, je tiens le bon bout pour l'édition en mode 32x32. Preuve en est ce 'chibby commander keen' bidouillé "en vitesse" avec la bonne vieille palette EGA (plus une petite couleur qui joue les trouble-fêtes :P

L'est-y pas mignon ^_^
plus inspiré par le webcomic de bob que par les vrais jeux EGA, en fait.

I came up with this chibby Commander Keen as result of my experiments with the 32x32 editing mode of my sprite editor tonight. (yes, fairy is away, that means too much pixeling and midnight coding for my health and funny eyes in the morning %P) Kinda cute, isn't he ? All i hope is that i didn't erase anything important while saving him before beaming up to the Web. It's really about time i make that "backup system" when overwriting sheets or at least that i give SEDS the ability to beam things without altering the existing spriteA.spr..spriteY.spr files.

J'espère juste n'avoir rien perdu dans le transfert. Il serait vraiment temps

  • [done] que je remette en place les fichiers .bak quand on sauve
  • [wish] que je permette de voir ce qu'il y a dans les différents fichiers au moment de sauver...
  • [wish] ou au pire, que j'autorise l'export d'une page isolée par le Wifi...
  • [done] vérifier que les animations, les copies, les effacements et tout ça fonctionne toujours.
  • [done] zoom pour changer la taille de grille en cours d'édition.
  • [done] pouvoir choisir la taille des blocs quand on construit une nouvelle page
  • [wish] support des sprites "rectangulaires" 16x32, 16x8, etc.
  • [done] "overlay sprite over current grid content", p.ex. avec B en mode curseur.
  • [done] tri automatique des couleurs par QuickPal (via le bouton 'scan')
  • [done] remettre en route la fenêtre d'édition de palette qui ne marche plus du tout ^^"
et toujours, pour LEDS
(wouw. finalement, ça fait une belle liste tout ça)
Ensuite, on pourra lancer la release ... je sais pas moi ... 0.3.2 ?

*edit*: oh. Bonne nouvelle. Depuis la correction de l'ARM7 (ou la mise à jour de desmume ?) SEDS, malgré son wifi, peut tourner sur desmume (et peut-être d'autres émulateurs ? l'avenir nous le dira ;)

Sunday, August 17, 2008

ramno 1/2

Aah. Eh bien finalement, ça n'aura pas été aussi difficile que je ne l'avais cru. Je parle de la possibilité d'avoir plusieurs "zones de stockage" dans un seul fichier .spr, bien sûr. En fait, une seule classe dans tout mon imbroglio était sensible à l'emplacement réel des tiles en mémoire. Il a suffit de l'éditer pour que tout se mette en place. A part ça, il y a juste SpritePage qui a chopé une nouvelle variable "ramno" pour indiquer le numéro du SpriteRam utilisé ...

"Mais par l'espace, pourquoi tient-il absolument à regrouper dans son fichier des choses qui n'ont aucun rapport entre-elles ?" vous demandez-vous (si, si, sondez le fond de votre coeur, vous verrez)

Eh bien, la première raison, c'est évidemment le hardware de la DS. Si on dispose de 640K de mémoire vidéo, en revanche, les différents plans, les sprites, etc. utilisent généralement des zones mémoire séparées. Or, si je pourrais me satisfaire d'avoir Bilou complètement séparé de mon décor de forêt, l'appleman, le petit ver et d'autres éléments font un tout avec cette forêt. Supposez que je veuille faire un monstre comme "mimerock" dans Keen4: le même graphisme est utilisé à la fois comme élément du décor et comme sprite mobile. Idem avec le "bloc-question" de Super Mario (dans la version ou il 'sursaute' une fois coud-boulisé). Il serait vraiment pénible de devoir gérer un tel bloc dans deux fichiers séparés (croyez-moi: c'est ce que j'ai du faire avec mes Badman sous Game Maker :P)

La seconde raison, ce sont les blocs animés. Reprenons le bloc-question de Super Mario. Il va apparaître comme un seul bloc sur notre map, mais son contenu sera remplacé régulièrement par les étapes suivantes de l'animation. Evidemment, cela signifie que l'animation complète doit bien être stockée quelque-part, et si le nombre d'animations devient un peu important, ce serait ridicule de stocker tout ça en mémoire vidéo (alors qu'on a 4Mo de RAM à côté).

Voilà. Je n'ai peut-être pas convaincu grand-monde mais je me sens mieux. Plus léger d'avoir pu vous confier tout ça. A la semaine prochaine, docteur ?

Friday, August 15, 2008

"il pousse encore moins vite que ma barbe"

J'ai encore quelques ajustements à faire, mais l'un dans l'autre, je ne suis pas mécontent de mon tout nouvel arbre, héritier de la technique "curseur" et des nouvelles couleurs importées hier. Avec un peu de chance, j'attaque ce week-end la souche, j'ajuste les herbes (là, c'est un peu brol). Mais il faudrait bien que j'adapte l'éditeur de niveau pour pouvoir placer des "blocs" 16x16 à cheval sur la grille. Parce-que l'édition en 8x8, c'est bien pour ajuster quelque chose par-ci par-là, mais pour le reste, c'est pénible et ça tend à donner de drôles de résultats. Trop peu de différence entre les feuilles "avant plan" et celles en arrière plan.

I still have a couple of things to adjust here and there, but all together, i think the new tree (leftmost) comes quite nicely. The "cursor" technique definitely proves to be a very valuable tool. I'd like to work on the tree trump this week-end and fix the messy grass (i currently have up to 4 different variants that do not match together :P)
Now, it's really time that i adjust LEDS so that it could work with 16x16 blocs with more flexibility and manipulate complete objects so that i don't have to redo trees tile per tile everytime.

Thursday, August 14, 2008

spraddpage et compagnie.

Bon, puisque SEDS est "réparé", j'ai essayé de ramener l'entièreté de mes graphismes vers la DS. Certains avaient été faits sur la DS de mon frère (l'appleman, par exemple), d'autres sont des retouches dans Gimp, d'autres encore viennent du "vieux" jeu de tiles (oui, oui, celui qui a tout explosé en dépassant les 1024 tiles ;)

Découper, aligner sur la grille, rogner, convertir, re-convertir, compresser les palettes, transférer, fusionner, re-transférer ...

Je vous donne un petit aperçu en image de ce que ça donne, simplement pour fusionner un .spr qui était sur la DS et une image .png déjà préparée qui traine sur le PC ... puis je vous laisse imaginer le tableau quand il faut répéter l'opération avec quatre sources différentes ^_^

Ennfin. Je crois n'avoir rien perdu ni oublié dans la bagarre, ce qui relève presque de l'exploit !

Wednesday, August 13, 2008

Size'd up!

Un petit bug assez mal venu dans les effacements de sprites m'a fait reprendre le code de SEDS plus en détail. Je sais qu'il faudra que j'adapte SpriteRam et autres SpriteSheet pour pouvoir passer à la vitesse supérieure (ç.à.d. des animations gérées directement dans SEDS), mais là, je prends plutôt le temps de passer en revue ces "petits détails" qui trainent dans les todo list depuis ... hoouuuu ... aout dernier ? réparer ceci, arranger celà ...

Je mets la "priorité" sur la réparation du mode 32x32 et la possibilité d'éditer dans la grille 32x32 ou 16x16 indépendamment de la taille des blocs (donc prendre un quart de sprite 32x32 pour ajuster quelques détails, ou un groupe de quatre blocs 16x16 pour faire une esquisse).

An unexpected bug (sic) in the recently introduced "block erase" feature made me print SEDS code once again to track oddities. There is a growing list of "todo" items on this blog, with some of them dating back to ... augustus 2007 ^^". So i still have a couple of "fix&tune" things to do -- the most important one being to ensure 32x32 edition grid works fine (atm. it cannot scroll or use the cursor, for instance) and then allow the "zoom" button to switch between 16x16 and 32x32 regardless of the size of the blocks on the current page. After which i'll try to work on a "sketch mode", to avoid depending on Gimp for sketching larger pictures.

Et ensuite, je tente un "sketch mode": dessin libre sur toute la surface de l'écran, comme dans un programme de dessin classique, histoire de pouvoir donner l'allure générale d'un élément encore plus grand (un arbre ?-) avant de le détailler en mode "grille".