Coder pour Onyx Boox

Bon, j'avoue que autant installer un devkit android sur mon NUC était un objectif quasi-prioritaire en 2019, autant il ne s'est quasiment rien passé de ce côté-là, en fin de compte. Au mieux j'ai refait le week-end dernier un tour des repositories open-source et Androïd-Demo ... et je trouve assez curieux que l'un des deux soit entièrement avec du code C++ pour Qt. Mais tournerait-il vraiment sur le boox ? Les derniers commits sont de Nokia et on plusieurs années (je dirais qu'ils datent de 2012 ou 2013...) est-ce du code qui était prévu pour un ancien modèle (pré-android) ? Fort possible puisque les boox Androïd arrivent fin 2013.

Since the Cybook, I'd love to be able to run my own code on e-ink devices. Since the Boox is an Androïd, it should have been easy and I had pushed "setup an SDK on the NUC" as a top priority in 2019. I had gathered github links to see what would help me using native stylus recognition and screen driving, but it looks like most of what I got (featuring C++ and Qt) would be for pre-android devices like M9[0..2] while I have N96.

Most of what I did to customize my Boox use was through custom web servers on the NUC, but there is clearly room to do better. And I'd really love to have something feeling like Tomboy with a stylus, and a smart UML-sketching tool...

Moi j'ai un modèle N96, qui est une évolution du M96. Le package "booxsdk" propose des versions de gcc pour les modèles M90, M91 et M92, qui sont tous pré-androïd selon wikipédia.

On ne peut pas vraiment dire qu'Internet croule sous les projets et pourtant, il y aurait moyen de faire tellement mieux qu'un browser classique ou qu'une adaptation poussive de Tomboy ou de l'application Wordpress ... Je devrais peut-être essayer de commencer par termux ? Mais moi, ce que j'aimerais c'est plutôt un stylux :-/

C'est là que j'aurais bien aimé avoir sous la main un pote qui fait de temps en temps du développement Androïd pour me guider un peu dans ce nouveau monde.

Je n'ai toujours pas de solution pour les navigateurs web qui n'ont pas de mise à jour de leur certificats, par contre. C'est particulièrement agaçant, et ça semble même être de pire en pire. Au point que je ne suis pas sûr de pouvoir encore utiliser le Google Play Store. J'aimerais pourtant pouvoir éviter de rooter l'appareil ... 

 Oh, et pour ceux qui n'ont pas de boox, un petit coup d'oeil à EPaper-DIY ?

Life-changing books [3/3]

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

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

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

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

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

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

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

Keen's Inception

Coincé entre deux générations de "game engine" de la série commander keen, on trouve un jeu étrange, faisant presque figure de "lost levels": Keen Dreams. Une grande part du design global de l'excellente série "Goodbye Galaxy" est présent: décor en perspective cavalière, personnage de 40 pixels de haut, environnements variés et son SoundBlaster. En revanche, keen se promène en pijama et en pantoufle et ne dispose ni de son neurolaser, ni de son célèbre pogo. A la place, Keen peut lancer en cloche des mines transformant les ennemis en fleurs à leur contact. Le gameplay demande donc beaucoup plus de précision que dans les autres épisodes, d'autant plus que les ennemis ne resteront pas transformés éternellement. Ça n'est pas sans rappeler le lancer de taille-crayon dans Bilou, je l'avoue, mais si je vous en parle, c'est surtout à cause de ses sources, ajoutées sur github début septembre, et que je suis occupé à analyser. Les sources sont essentiellement en C avec quelques blocs d'assembleur en ligne, chose plutôt rare pour l'époque.

Bien sûr, j'aurais préféré que Javier et Chuck nous proposent le code de Goodbye Galaxy, notamment à cause de l'absence de pogo dans cet opus, mais c'est le premier Keen à proposer des pentes, ce qui n'est déjà pas si mal.

Keen Dreams' source code has been released last September. I wish it was the code for one of the Goodbye Galaxy episodes, of course, as it is one of the games I played the most, and the one with the richest features set -- pogo, gun, moving platforms and shooting ennemies -- which isn't crippled with clipping bugs. Anyway, Keen Dreams has slopes and shooting/pushing ennemies. The map design with its "info layer" suggests that most of the engine has been kept between Keen Dreams and Goodbye Galaxy. The character's moves (jump, run and pole-climbing) are direct translation of GG spritesheet. The pogo is missing, and I will have to define how the lone "canteloupe cart" can be ridden. 

Rather than stunning gun, Keen throws "flower power" seeds that are affected by gravity somehow like my dumbladors. Gameplay-wise, I cursed that decision quite often. Aiming for those fast-moving, aggressive vegetables with something that follows an arced curve, bounce on the ground and only stuns for a limited amount of time made imho this episode almost the hardest of the series. So far, I haven't found arced curve of bladors that hard to use, but on the other hand, monsters in Bilou's Schoolzone don't kill you instantly on contact.

N² with high N could turn Nightmare.

En plus de leur calques "graphiques", les niveaux possède une couche "info" qui indique quels monstres créer au chargement du niveau (scaninfoplane et HandleInfo). Les monstres de l'ensemble du niveau sont conservés dans une liste liée, mais seuls sont "actifs" ceux qui sont assez proche dans l'écran. Leurs collisions sont gérées par un parcours imbriqué de la liste (N²) -- rien d'équivalent à mon système de "castes", donc --  mais vu le nombre réduit de monstres par écran dans le level design, celà ne pose pas de réelle difficulté, sauf peut-être dans le niveau des vignes.

Compared to my own engine, code for managing collisions looks quite simple. There is no Hero/Ennemy casts, nor collision masks. The engine checks every pair of "objects" for intersection of axis-aligned bounding-boxes. That could easily turn into programmatic nightmare in a game with heavy number of monsters like Apple Assault (up to 10,000 checks per frame), but here, the test is skipped as soon as one of the monsters is off-screen (active is false), and there quite little places where the screen shows more than a handful of ennemies at once. 

Funny enough, although everything may have its own contact() function and both are invoked when two objects come in contact, there is no passive/active role... yet, monsters typically don't use their contact() function at all, and whether Keen should die or be granted more points is all encoded in Keen's own contact() function, and contact() function for the flower-power seeds has knowledge of which monster can be stunned and which object shouldn't be affected.

Casts make it linear and scalable

On a une fonction "contact()" pour chaque monstre qui régit les changements en cas de collision. Pas non plus de notion de "actif/passif" mais une organisation où "PowerContact" (pour l'arme de Keen) transforme tous les objets en fleurs et KeenContact() mêne à la mort de Keen presque systématiquement. Ces fonctions contact ont la possibilité de faire n'importe quels tests (on est dans du code C), y compris aller tester l'étape d'animation de l'objet avec lequel on est entré en contact ... ce qui permet de concentrer toute la logique de collision dans quelques objets. Pour les monstres, il n'y aura en fait aucun code pour les contacts.

Ça vaut aussi la peine de regarder de plus près le système des "ticks" qui règle le comportement des personnages. Ce type de code est le plus souvent absent sur console. La vitesse du CPU est connue et la mise à jour de l'image à l'écran assez rapide vu la structure choisie pour le processeur graphique. Mais on est ici sur (vieux) PC, avec une vitesse quelque part entre 6 et 40MHz pour le processeur principal et un système de rafraîchissement de l'écran passablement complexe. Le jeu ne tournera certainement pas à 60 images par secondes, ni même à 30 ou à 12. On aura plus que probablement un temps de rendu (entre l'instant où la logique du jeu a fini sa mise à jour et le moment où la nouvelle image est effectivement visible à l'écran) variable.

The game logic is built around the notion of time ticks, which are a virtual equivalent to video frames on a game console like the Nintendo DS. However, unlike a console, the PC (ranging from 6 to 40MHz by that time) cannot guarantee we'll have a new frame rendered every 1/60th of second -- maybe not even every 1/12th of second. It's much more likely that the framerate will be irregular, depending on bus availability for memory transfers and complexity of the current scene. ID software developers thus measure how much time elapsed since the last rendered image and deduce how much game logic _ticks_ corresponds to this time. The StateMachine() function then compensates by stepping the characters by (xspeed,yspeed) the appropriate number of time, invoking the think() function when needed. Rather than experiencing slow downs, we'd experience a drop in the frame rate, but no kid on earth would complain about that from a shareware

The code logic deciding whether think() should be called or not is quite complex, allowing some part of monster behaviour code to indicate "do not think for N ticks, and slide me at constant speed" or "only invoke think() when time is ready for the next animation frame", etc. The benefit is that most of the code that accommodates for "process N ticks at once" is in that generic logic, and the monster-specific code remains as simple as updating speeds, not moving coordinates. Another function will then react() to the new position of the character on the level (does it still has ground under its feet ?)

L'idée (toujours présente dans les Quake modernes, pour ce que j'en sais) consiste à mesurer le temps qui s'est écoulé depuis la dernière demande d'affichage et à exécuter k "pas" (les ticks) de la logique de jeu, où k * durée_d'un_pas = temps_écoulé. Ainsi, la fluidité varie mais le timing du jeu reste constant et on ne perçoit pas de réel "ralentissement". Ce qui témoigne de la qualité du design, c'est le fait que le code du comportement des personnages peut être écrit sans devoir se soucier de ce mécanisme: les fonctions DoActor et StateMachine prennent intégralement ce comportement en compte et sont capables de gérer une transition d'état au milieu du laps de temps à simuler sans pour autant faire N appels aux fonctions think() des personnages. Autre élément qui se retrouve aussi dans les FPS d'ID software: la fonction "think" n'est pas forcément appelée à chaque moment. Selon les besoin, elle peut être invoquée sur les étapes d'animations, à intervalle régulier ou aléatoire.

Dernier traît intéressant dans les grandes lignes de l'organisation du code: la fonction think() d'un personnage ne se préoccupe généralement pas des collisions avec les murs. Elle se contente de lire l'état du jeu et de décider de la direction/vitesse/animation à suivre. Une deuxième fonction, react(), associée elle aussi aux états du personnage, sera appelée après que le déplacement ait eu lieu et s'occupe d'aligner un personnage qui aurait rencontré un mur. J'y reviendrai dans le volet prochain.

¿ Che Passa ?

Une semaine après un e-mail curieux de SourceForge annonçant une tentative d'infiltration dans leur systèmes qui les auraient obligés à bloquer tous les comptes jusqu'à ce que leurs mots de passes soient changés, voilà une drôle de bourde de configuration qui m'indique que je suis le seul à pouvoir dire à mon ordinateur de faire confiance au serveur SVN sur lequel se trouvent les sources de mes outils. Là, je regrette, mais je vais faire une pause "no sf.net" le temps que les choses soient corrigées...

Slightly more than one week ago, SF.NET announced a hacking attempt. Today, I cannot update my svn working directory because of some certificate issues. That shouldn't impact my hobby too severely, but I'm afraid that means you might see a larger amount of technical self-comments

* Merry Christmas *

Joyeux Noël. je vous invite à prendre livraison des sources du jeu de l'année 2010 : Apple Assault.

Merry Christmas, everyone. I managed to clean up and comment the source code for Apple Assault, which you're now welcome to download. See you in 2011 ^_^

* Merry Christmas *

Pendant que Bilou et Bouli se font une bataille de boules de neige, je vous invite à prendre livraison des sources du jeu de l'année 2010 : Apple Assault.

Merry Christmas, everyone. Bilou and Bouli are currently having a relaxing snowball battle on planet 2412.0 ... Meanwhile, I managed to clean up and comment the source code for Apple Assault, which you're now welcome to download. See you in 2011 ^_^

PS: les p'tits graphismes de Bilou et Bouli viennent d'un vieux PCX datant de ... hooouuuu ... 1999 ? Je voulais faire un Worms avec des boules de neige ;)

source setup-r32

Bion, un package sources pour Apple Assault, c'est sympa, mais si le code pouvait être compilé avec les versions en date du devkitpro, ça ne serait pas plus mal, hein ? Il faut dire que j'étais resté à la version r21 qui doit dater d'octobre 2007 et sur laquelle j'ai pas mal bricolé entretemps.

I guess it'll make more sense to do a source release if you're able to compile Apple Assault from the source, right ? That's where you'll need devkitpro, the open-source cross-compiling and core-libraries project for homebrew console development ... as it was back in October 2007. Sticking to a working -- but obsolete -- development kit helped me during 3 years to stay focus and work on my tools rather than doing pointless bugfixes, but now it's time to move on. I fear it won't be an easy task, though, as I use a custom ARM7 and so on ... Hopefully, again, the ease of branching with subversion should help a lot.

• gcc 4.5.1 râle sur char * x = "hello" et insiste pour qu'on ait const char* x = "hello", histoire que la chaîne (normalement considérée comme une constante) ne puisse pas être altérée par le programme. Dans l'absolu il a raison et c'est facile (mais chaint) à corriger... d'autant (C++ oblige) que le code de la bibliothèque doit lui aussi être recompilé pour bénéficier de l'update :P
  
• IPC n'existe plus ou a été modifié. Je m'en servais pour gérer la mise en veille de la console ... 'faudra trouver autre chose. Plus gênant, mon code custom pour le côté ARM7 devra sans doute être mis à jour lui aussi, et de manière substancielle.
  
• SUB_DISPLAY_CR a été renommé, de même que BGx_CR, BGx_X0 et leur variantes SUB_xxx (pour assurer la cohérence avec GBAtek, ce qui n'est pas plus mal, soit dit en passant). Pas vraiment gênant pour l'exécutable lui-même, mais ça va être pénible pour la mise à jour de mes bibliothèques

Bien sûr, mélanger les libgeds.a ou libpppnds.a de devkitpro r21 avec AppleAssault.o compilé pour devkitpro r32 (libnds 1.4.8, libfat 1.0.7, dswifi 0.3.13) serait voué à l'échec. C'est donc l'ensemble du projet qui a besoin d'être migré >_<

L'alternative, c'est de fourguer libnds, libfat et dswifi précompilé dans le "package sources", mais ça me tente tout de suite moins :P

PS: "source setup-r32" parce que j'ai pris l'habitude d'avoir un script shell nommé "setup" à la racine de chaque projet qui configure toutes les variables d'environnements (CLASSPATH, LD_LIBRARY_PATH, CFLAGS, voire même PATH pour utiliser des cross-compilers) ce qui me permet d'utiliser la commande shell source pour "activer le mode OMNet++" ou "activer le mode devkitpro". En l'occurence, pour devkitpro, j'ai un setup-rxx selon que je veux utiliser la release 19, 20, 21 ... ou maintenant 32.

open-sourcing apple assault ...

The engine behind apple assault is open source from the start: this is my (modest) gift back to the world for having provided wonderful open tools such as Firefox, Linux, gcc and devkitpro. The problem so far is that pixel art, on its side, required a lot of work from myself, and I consider it as my own intellectual property that I want to keep under control. As a result, Apple Assault itself was closed source so far: publishing source without the art would not have run properly.

Le moteur d'Apple Assault -- tout comme l'ensemble des outils que j'ai développé pour DS -- est Open Source. C'est ma manière de récompenser tous ceux qui ont travaillé à d'autres produits open source que j'utilise tous les jours. Pourtant, jusqu'ici, il n'était pas possible d'avoir les sources complètes du jeu lui-même, notamment parce qu'il aurait de toutes façon été impossible d'obtenir une version fonctionnelle du jeu à partir de ces sources sans que je ne vous donne également les planches de sprites utilisées par le jeu. Et ça, je n'y tient pas: elles m'ont demandé des heures de travail créatif et acharné. Je souhaite qu'elles restent ma propriété intellectuelle.

Mais le petit script "8-bit-ify.pl" écrit ce midi devrait prochainement changer la donne: j'ai la possibilité de réduire la qualité des graphismes (leur donnant au passage un petit look 'C64' assez rigolo) tout en conservant l'entièreté de la fonctionnalité du jeu, et sans devoir passer par des phases de conversion de données fastidieuses. Avec le passage vers SVN comme outil de contrôle des version en prime, je devrais pouvoir vous proposer une version "commentée tutorielle" du jeu d'ici la fin du mois ^_^

Hopefully, I wrote a quick "8-bit-ify" script that convert the art (mostly killing details) such that it is still possible to compile and experiment, but not to fork a new project reusing the original sprites and tiles. Together with a switch to Subversion rather than CVS as the project revision control, you can expect a full open-source Apple Assault to come out soon as tutorial to the usage of my tools and libraries.

Somehow, it's fairly odd to play with those C64-feeling graphics at full framerate :P

source released on 24.12 MMX on Sourceforge.net

NitroTracker

Nitro-tracker, the homebrew soundtracker running on the Nintendo DS written by 0xtob and based on libntxm has been open-sourced a few monthes ago. Sounds like it is time for me to embrace the open-source spirit, grab the sources and port the improvement I made locally to a wider audience. That should be my "hobby-priority" once Apple Assault is released.

L'auteur de la libntxm a publié les sources de son NitroTracker il y a quelques mois. Ce serait justice que de m'assurer que la gestion des effets que j'ai ajoutée pour mes besoins personnels y soient également disponible ... et pourquoi pas en profiter pour ajouter un bouton "quit to runme" ? Allez, je boucle "Apple Assault" et je m'y mets.

Xargon : may the source be with you ...

Vous ne connaissez pas Xargon ? pensez à Jill of the Jungle avec un chromosome Y et vous ne serez pas loin... Vous ne connaissez pas Jill of the Jungle non plus ? Ah. Bin probablement que votre PC n'avait pas encore de carte SoundBlaster ou d'écran VGA en 1992. C'est vrai que ça coûtait un peu cher, à l'époque.

Quoi qu'il en soit, si je vous en parle, ce n'est pas parce que les 3 épisodes de Xargon sont disponibles sur classicdosgames.com. Non, c'est parce que le code source de Allen Pilgrim est également disponible. C'est du code C, mode réel pour le DOS, mais suffisamment propre pour que tous les aspects "hardware" soient extrait de la logique du jeu -- et croyez moi, sur PC, c'est un exploit majeur.

Ce n'est pas la bibliothèque d'abstraction du hardware qui m'intéresse, bien sûr. Même si c'était impressionnant à l'époque, le scrolling des jeux de plate-forme Epic ne pouvait concurrencer celui du moteur de John Carmack (commander Keen & autres), le player de fichiers CMF (adlib/midi) était bien connu, mais je n'ai jamais vu d'éditeur correspondant, et si l'on se laissait impressionner par un "yeeaaah" en ramassant un gros bonus, le mixage des effets sonores était en réalité peu convaincant (voire absent).

I'm currently studying the game logic of Xargon from Allen Pilgrim's sources. I hope that giving a look on someone else job will help me to overcome that "analysis paralysis" in my own game engine. I know i tend to overcomplicate things ... The management of objects-to-world collision has already shown enlightening... more to come. And, by the way, if anyone of you is interested into porting Xargon to the DS (or whatever other system), you may want to give a look to information gathered on the game modding wiki at shikadi.net in addition to the source code. Personnally, it's not in my to-do list :P

Non, ce qui m'intéresse c'est la logique du jeu. Et quelque-part, cette logique me crie le maître-mot de Mollusk: "ne vous posez pas de question: codez". C'est vrai quoi. Je me prends la tête avec mes test-points alors qu'en fait, ce n'est qu'une optimisation bancale que je traîne depuis l'age du BASIC, renforcée par l'étude d'un jeu NES. La gestion des collisions perso-monde dans Xargon est bien plus simplement basée sur les possibilités de l'ensemble des tiles recouverts et l'affectation de propriétés sur chacune de ces tiles.

int cando (int n, int newx, int newy, int ourflags) {
 int x,y,temp;
 int flagor, result;
 int startx, endx, starty, splity, endy;

 startx=newx/16;
 starty=newy/16;
 endx=(newx+objs[n].xl+15)/16;
 endy=(newy+objs[n].yl+15)/16;
 splity=(objs[n].y+kindyl[objs[n].objkind]+15)/16;

 flagor=f_notstair;
 result=0xffff;
 for (y=starty; y<endy; y++) {
       if (y>=splity) flagor=0;
       for (x=startx; x<endx; x++) {
         temp=(info[board(x,y)].flags|flagor)&ourflags;
         result&=temp;
       };
 };return (result);
};

Comme disait Colomb en quittant le Portugal "Il suffisait d'y penser": le tout est de concevoir les propriétés des tiles de manières à ce qu'elles "s'additionnent" bien. Un personnage ne peut se déplacer vers un nouvel endroit que si tous les tiles possèdent les bonnes propriétés ("pas un bloc", ce que Allen appelle f_passthru. Celà demande parfois un peu de jonglage mental. f_water est évident, f_climbable aussi. f_not_stairs un peu moins...

int trymove (int n, int newx, int newy) {
 int ourflags;
 ourflags=f_playerthru;

 if (newy>objs[n].y) ourflags|=f_notstair;
 if (cando (n,newx,newy,ourflags)==ourflags) {
    moveobj (n,newx,newy);
    return (1); // successfully made it to new location.
 } 
 else if (cando (n,objs[n].x,newy,ourflags)==ourflags) {
    moveobj (n,objs[n].x,newy);
    return (2); // could only move vertically
 }
 else if (cando (n,newx,objs[n].y,ourflags)==ourflags) {
    moveobj (n,newx,objs[n].y);
    return (4); // could only move horizontally
 };
 return (0);    // couldn't move at all.
};

J'aime bien aussi la manière dont il a réussi à capturer les comportements de déplacement simples Il faudra que je tente d'en faire autant. Bion. Je vous en dirai sans doute plus. Malgré tout, la routine de gestion du personnage principal fait quand-même 7 pages, et je n'ai pas encore tout lu.

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.

"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 là (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.

ntxm->play();

j'ai des petits soucis avec la bibliothèque mikmod qui aurait du servir de soundplayer dans mes jeux. De plus en plus de soucis, en fait ... Du coup, j'ai l'intention de passer à libntxm, le modplayer qui est au coeur de l'excellent NitroTracker de 0xtob, et qui nous fait pleinement profiter des capacités audio de la console (mixage hardware sur 16 canaux).

Le seul hic, c'est que pour l'instant, je n'arrive pas encore à lui faire cracher du son dans runme :( Une fois que ce sera règlé, il me restera à assurer le support des S3M (minimum) et des IT (là, ça va être plus chaud) pour pouvoir profiter des petites musiques du frérot.

Howdy! I got libntxm working in runme this lunch time. I was getting less and less satisfied with libmikmod's quality (corrupted playout buffer) and wanted to switch to hardware mixing instead. This is still a very basic test atm (e.g. just playing a pre-configured XM song when you enter the "beam out" window), but you can expect "play XM received by WiFi" feature within the week ...

Once i get that done, i bet i'll try to write a S3M reader (drawing inspiration from mikmod's source, of course) and add support for S3M effects to the libntxm. That should bring me most of my bros' music library (before he switched to Impulse Tracker -- which will be a higher challenge to deal with) for my games, with minimal CPU load and best possible output quality.

edit: okay. ça marche. J'avais fait l'andouille suprême: contrairement à la bibliothèque libmikmod, libntxm n'utilise *pas* le FIFO interne de la DS pour transmettre ses commandes. On a tout simplement un tableau circulaire dans lequel les commandes successives (e.g. playSong, stopSong, etc.) sont inscrite et que chaque "moitié" du modplayer manipule. Le tout est placé dans une zone de mémoire spéciale (qui sert également pour s'échanger les coordonnées du stylet, et tout ça).

Et pour la petite histoire, la bibliothèque réseau dswifi, elle, utilise encore un autre mécanisme (une zone de transfert dans la RAM principale, mais dont l'adresse est bidouillée pour court-circuiter le cache du processeur). Là, l'ARM7 apprend l'adresse de la structure (allouée côté ARM9) lors d'une phase de dialogue initial à travers le FIFO, et les mises à jour de la structure sont également annoncées "over FIFO". 0xtob, lui, reprenant le code du modplayer posté sur le forum GBAdev, vérifie gentillement si un nouveau message est arrivé tous les 60èmes de secondes (et donc dans le "Vblank" handler plutôt qu'en réponse à un évènement sur le FIFO :P)

Ca y est ? vous êtes perdus ?

2024 #choice reality check: I'm still using libntxm and don't intend to change. Significant work was needed to add effects support and I failed to push that back into the original repository. Oh, and I never added S3M or IT support. Instead, I just went on converting files into .XM with schismtracker :P

wifi + DS + libmikmod = ^_^

yeah! J'ai réussi à intégrer la nouvelle mouture de libmikmod (et ses drivers DS) de tetattds (sten larsson) avec le petit framework de téléchargement d'image pour la DS.

Résultat ? je peux transférer des fichiers .pcx et les visualiser (enfin, une portion de 256x256) sur la DS, transférer des .mod, des .it et des .s3m et les écouter (à 22KHz), et toujours sauver des fichiers et faire les mises à jour du soft depuis un serveur HTTP.

Ca commence tout doucement à ressembler à une extension de mon PC. C'est probablement encore très loin d'être "user friendly", mais ça prend forme ;)

Ceux qui veulent rejoindre mon cyborg de frère et k93 dans les rangs des béta-testeurs sont les bienvenus sur la page "download" du projet sourceforge . Les impatients qui veulent du code peuvent déjà faire un tour dans le CVS .

"This is a small step for humanity, but a giant leap for me!" ... I now have the latest DS port of libmikmod (from sten larsson's tetattds) integrated with my current beamed-picture-viewer (aka. runME) on the DS. That means in addition to .PCX pictures wifi transfer and display, i can also receive .MOD, .S3M and .IT tracked format (up to 256KB) and play them back on the DS. The ability of software upgrade through HTTP server is still there too and dramatically helps fast development.

The subtle rendering difference might be important for artists working on a PC for the DS platform (e.g. my bross will ultimately write/adapt tunes for DS games, so he'd love to listen what it sounds like without having to compile a binary or depending on an actual game. Still, both PC-server and DS-client sides are far from being intuitive or user-friendly, but that's a small step in the good direction.

As always, code is already available through the Sourceforge CVS if anyone is interested ^_^. I would just appreciate to be notified of it ;)

rumbling session

A small 'rumbling session' this lunchtime, after Cyril teased me about using apples to do "gravity experiments" on the DS -- "just like Isaac Newton, hmmm".

I managed to replace the 'decompress(VRAM, some_file_bin)' by tiles loader from my Sprite Editor, and started exploring the internals of Tetris Attack source code. I like how Sten Larsson did split his code between "PlayField" (that is basically how i would code the game in QuickBasic) and "FieldGraphics", which offers an abstract -- and adapted -- interface to push blocks on the screen, add effects, and the like.

Now i can enjoy a completely screwed "Tetris Attack" with random blocks of wood and apples as graphics :P

On discutait DS et sprites avec Cyril, et je lui explique que je voudrais faire quelques essais de gravité pour mes jeux DS, par exemple avec mes petites pommes -- "Comme Newton, hein?" qu'il rajoute.

Donc vous avez la un aperçu de la session de 'rumbling' de ce temps de midi, avec "TetattDS" qui ressemble de moins en moins à un jeu de Tetris depuis que j'ai intégré mon code du Sprite Editor DS pour récupérer mes pommes :P J'en ai aussi profité pour regarder un peu (et documenter en UML) la découpe du code de Sten. J'aime encore bien le partage entre les classes FieldGraphics (tout ce qui est dessin un peu bas niveau) et PlayField (grosso-modo, c'est l'algorithme de jeu comme je l'aurais écrit en BASIC si le jeu avait utilisé des caractères sur un fond tout noir -- sauf qu'on fait appel à FieldGraphics)

TetattDS sources show a good example of game-specific engine. On a sidescrolling platformer, i'd have avoid per-block state as much as i could, still tetattDS has "BaseBock *field[FIELD_WIDTH*FIELD_HEIGHT]". In other words, the whole grid contains pointers to instances of blocks or garbage blocks. Pretty odd. Well, for me only, actually. Unlike blocks in e.g. SMB, here you need to 'stress()' 'pop()' and 'drop()' blocks individually, and you need to tell apart garbage block (unmovable) from regular blocks. Yet another puzzle-specific thing is the effect handler. Anything that requires a fancy animation goes through a class that extends "effect" baseclass and that is registered in the EffectHandler. The EffectHandler is a singleton that will evaluate each effect, calling their individual 'tick()' and 'draw()' routines appropriatedly and collecting effects which duration is over. I claim this to be puzzle-specific because in a sidescroller, you'd have rather implemented such effect by transient Sprites among the character and foe sprites.

Unfortunately, that means i cannot just use it as such to implement falling apples (since they'll fall until they hit the ground, not simply for a fixed time interval.