Balazar III 0.1
La première version de Balazar III est disponible !
Cette version est entièrement fonctionnelle, mais ne contient qu'un seul personnage jouable, qu'un seul monstre, et peu d'objets, de pouvoirs magiques et de salles. Il y a de quoi s'amuser et se faire une idée du potentiel du jeu, mais on en fait évidemment vite le tour... Le mode réseau est assez avancé ; il est relativement "costaud" et devrait pouvoir supporter un nombre important de joueurs simultanés.
Soya 0.14 is out !
The new version of Soya, 0.14, is out. Here is the complete changelog for 0.14:
August 2008 : Soya3D 0.14
Improved the cell-shading algorithm, by anti-aliasing outlines and disabling normal lighting when cell-shading is used
Bugfixes:
When re-starting a MainLoop, define it as the current MainLoop (aka. soya.MAIN_LOOP)
Test du chargeur solaire Solio avec un Zaurus
Introduction
On dit souvent que les meilleures choses sont celles que l'on fait soit-même. C'est vrai pour les gâteaux... et si c'était vrai pour l'électricité ? Je m'étais rendu compte un peu par hasard que mon Zaurus consommait moins d'1W par heure (il tient 8 heures sur une batterie de 1800 mA à 3,7 V et consomme donc 0,83 W par heure). D'où l'idée de le charger avec de l'énergie solaire !
Après avoir fait le tour des modèles disponibles, j'ai finalement choisi le capteur Solio, disponible en France chez Websolaire. Ce choix est motivé par les raisons suivantes :
Le Solio est compatible avec de nombreux appareils (téléphone portable, lecteur de musique,...), et une prise pour charger une PSP est disponible (en option). Il est connu que les Zaurus C1000 / C3x00 sont compatibles avec les alimentations des PSP.
Le Solio génère presque 1 W par heure à plein rendement, ce qui signifie qu'une heure de plein soleil équivaut à une heure de Zaurus ! (en théorie car il y a évidemment toujours des pertes !)
L'institut Fraunhofer (grand organisme de recherche Allemand) a démontré que ce capteur générait plus d'énergie au cours de sa vie que sa fabrication n'en a coûté.
C'est un des rares capteurs pour lequel j'ai pu trouver des tests positifs sur Internet, contrairement à beaucoup d'autres modèles (notamment ceux vendus par des sites orientés "gadgets informatiques" pour lequel je n'ai trouvé que des tests négatifs).
Commandé chez Websolaire, je l'ai reçu quelques jours plus tard sans problème.
Déballage
Au déballage, l'aspect écolo du capteur saute au yeux. L'emballage est quasiment exclusivement composé de papier recyclé et imprimé avec des encres propres. Le capteur lui-même est fabriqué avec des plastiques recyclés ; pour autant l'ensemble apparaît de bonne qualité. Le capteur comprend 3 petit panneaux solaires qui peuvent être pliés ou dépliés, ainsi qu'une batterie interne. Cette batterie est chargée par les rayons solaires, et ensuite cette énergie peut être transférée dans la batterie d'un autre appareil (comme le Zaurus).
Charge solaire
La notice indique qu'il faut 8 à 10 heures de plein soleil pour charger complètement le Solio. Mes tests montrent que le capteur tient ses promesses ! Le test a eu lieu à Paris, en été (mais avec un mois de juillet pourri !). La lumière directe du soleil est nécessaire, éventuellement à travers une vitre. Le soleil de fin de journée (entre 17-20h) permet la charge mais de manière moins efficace (60-75% environ).
Afin de suivre le chargement de la batterie, deux moyens sont disponibles :
Une LED rouge s'allume lorsque la charge est en cours.
Une LED verte permet de savoir le niveau actuel de la batterie, lorsque l'on appuie sur un bouton. Le niveau de charge est indiqué par 0, 1, 2, 3, 4, ou 5 clignotements de la LED verte qui correspondent respectivement à 0%, 20%, 40%, 60%, 80% et 100% de charge. Mes tests montrent cependant que le niveau est assez approximatif, par exemple il me faut significativement plus de temps pour passer du niveau 2 au 3 que du 3 au 5.
Connection au Zaurus
Une fois chargé, le capteur se connecte sans problème au Zaurus avec l'embout PSP. Le témoin de charge du Zaurus s'allume et les journaux du système indique qu'une alimentation de 1 A a été reconnue, ce qui correspond aux caractéristiques de l'alimentation fournie avec le Zaurus (1 A à 5 V ; le voltage étant a priori de 5 V pour un chargeur de PSP).
Lorsque la batterie du Zaurus est vide et celle du Solio est pleine, le transfert de la batterie du Solio vers la batterie du Zaurus prend environ une heure et demi. Après cela, la batterie du Solio est quasiment vide et celle du Zaurus est pleine à 60%. Cela signifie donc qu'il faut 1 heure et 40 minutes de soleil pour 1 heure de Zaurus en tenant compte des pertes (notamment lors des multiples conversions énergie chimique <=> électrique et des changements de voltages, et pour l'éclairage des LED du Solio et du Zaurus). Ce qui n'est pas si mal !
Conclusion
Le capteur solaire Solio fonctionne bien, sans être miraculeux non plus. La combinaison Zaurus + Solio permet d'avoir un (mini-)ordinateur qui tourne à l'énergie solaire ! Cela n'est possible que grâce à la très faible consommation du Zaurus, sans doute liée à son processeur non Intel x86, mais de type ARM (et donc ayant des performances limitées).
En revanche, un de ces "netbook" à la mode ne pourrait a priori pas être alimenté par l'énergie solaire sans utiliser un capteur significativement plus encombrant (un Asus EEE PC 701, un Acer Aspire One ou un MSI Wind consomme chacun environ 10 W par heure, soit l'équivalent de 10 Zaurus...). Ce qui me conforte dans l'idée que les processeurs de type Intel x86 sont très gloutons en énergie, y compris les récents Atom et compagnie pourtant censé être économes, par rapport à d'autres architectures. Et du coup je ne regrette pas l'achat de ce petit Zaurus, malgré l'ancienneté de cette machine !
Cerealizer 0.7
Cerealizer 0.7 is out!
It now allows to dump() things repeatedly to a stream or file, and then load() things repeatedly out of it.
Many thanks to Peter Eckersley !
Tom de Bombéo, la chanson !
Voici (enfin) l'enregistrement de la chanson de Tom de Bombéo, ainsi que les partitions !
Les paroles sont aussi disponibles dans la BD.
J'essaierai de faire un enregistrement un peu meilleur à l'occasion, je suis toujours moyennement satisfait de celui-ci...
(Avis à ceux qui se croiraient malins : toutes les chansons que je publie sont déjà protégés. Inutile d'aller faille l'imbécile en les déposant à la sacem ou ailleurs...)
Élodie, moi, tout : BD expérimental
Voici deux pages d'un futur projet de BD, qui reprend le style graphique du Guide Balazar, dans un cadre contemporain.
J'ai enfin publié un article !
Un premier pas important franchi dans ma vie de chercheur : j'ai enfin publié un vrai article (c'est à dire pas une conférence), en premier auteur !
Et pour une première fois, c'est réussi : l'éditeur (sympa) nous a fait un communiqué de presse et l'article a ensuite été repris dans plusieurs site oueb médicaux. Encore mieux, il a été commenté dans Science et le sera bientôt dans Nature, deux revues scientifiques parmi les plus prestigieuses !
L'article est dispo librement ici : http://www.biomedcentral.com/1472-6947/8/16/abstract. Le choix d'une revue disponible en ligne permet non seulement de satisfaire mes idéaux de chercheur public en ayant une publication sous licence libre Creative Common (CC-BY), mais aussi d'avoir une diffusion bien plus large (plus de 2200 lectures en moins d'un mois !).
A propos de la licence...
Certaines personnes s'étonnent du choix de la licence pour ma BD : une licence Creative Commons avec la clause NC (non commerciale), que certains jugent "non libre".
J'ai fait ce choix car je trouverai injuste que quelqu'un exploite commercialement ma BD sans rien redonner en échange. L'exploitation commerciale d'une oeuvre libre nécessite évidemment une "valeur ajoutée" par rapport à la version libre. Dans le cas d'un logiciel libre, l'exploitation passe par l'amélioration du logiciel ; une licence de type "gauche d'auteur" (GPL par exemple) permet alors d'obliger la personne à redonner les modifications (La vente de support ou de formation pour le logiciel n'est pas une exploitation commerciale du logiciel lui-même, il est ainsi possible de faire de la formation à un logiciel propriétaire sans avoir l'accord de son auteur).
En revanche pour une BD, l'exploitation commerciale évidente est la vente d'exemplaires papier. Dans ce cas, rien n'est redonné à l'auteur originel ou au "pot commun libre". Ce qui est difficilement acceptable !
Enfin, je n'estime pas que la clause NC soit "non libre" pour une BD, car les 4 libertés fondamentales sont bien respectées :
liberté de lire la BD
liberté de regarder les sources de la BD (les fichiers SVG vectoriels)
liberté de modifier la BD
liberté de redistribuer la BD, en version originelle ou modifiée, en gardant la même licence
En conclusion, une BD n'est pas une oeuvre comparable à un logiciel, et la notion de "liberté" ne peut donc pas être la même. Elle reste à définir ; ce qui devra bien entendu être fait par des dessinateurs et des scénaristes, et pas par des programmeurs de logiciel libre !
Essai de dessin sur l'écran tactile du Zaurus
Le dessin a ensuite été vectorisé dans Inkscape.
Petit Zaurus s'améliore en français
J'ai enfin trouvé comment traduire les applis de Cacko sur le Zaurus... en fait l'original est en anglais, des fichiers de traductions ont été ajouté pour le japonais, puis enlever pour retourner à l'anglais... il suffit donc d'en refaire pour la langue de Colin Marchika (écrivain français pas du tout connu mais très bon... pourquoi dirait-on toujours "la langue de Molière" ? il est pas le seul à la parler, cette langue !).
Du coup les traductions sont en cours et vont bientôt se retrouver en jolis petits paquets IPKG ici !
Soya 0.14rc1 is out !
A new version of Soya, 0.14rc1, is out. This release includes many bugfixes and has been updated for latest release of Pyrex. It also includes a new GUI module called soya.gui (see the gui-* tutos for demo).
Here is the complete changelog:
January 2008 : Soya3D 0.14rc1
Allow the centre of mass of a Body to be anywhere in its local coordinate system (thanks Greg Ewing)
Improve tutorial README (thanks Jacques Rebourcier)
Update for Pyrex 0.9.6.2 (thanks Greg Ewing)
Blender => Cal3D can now run with Python 2.3 (thanks Greg Ewing)
New GUI module soya.gui
Bugfixes:
Fix the weird segfaulting bug in terrain (thanks Souvarine)
Fix GL_INVALID_ENUM crash with the OSS ATI DRI driver (thanks Zoltan Dome)
Fix data/worldS and data/blender in the yet-in
Fix speed-1.py tuto
Fog was activated by error on partial camera with no atmosphere
Fix descender computation in font
Fix ODE on terrain (tuto ode-collision-8-terrain.py)
Fond d'écran pour Zaurus
Voici mon fond d'écran pour Zaurus. Quelques astuces :
Avec Cacko, un fond d'écran en JEPG est beaucoup plus rapide qu'un fond d'écran en PNG ! Donc préférer ce format.
L'écran du Zaurus n'affiche "que" 64 000 couleurs, ce qui provoque des "sautes" de teinte dans certains dégradés (lorsque le dégradé couvre plusieurs teintes). Pour éviter ça, on peut faire du tramage (dithering). Dans Gimp, je n'ai pas trouver d'autre moyen que de passer l'image en couleurs indexées (dans le menu image puis mode, en activant le tramage des couleurs) puis de la repasser en RGB (il doit sans dout y avoir un moyen mieux de faire du tramage, si quelqu'un a des idées je suis preneur !). Cette opération réduit le nombre de couleurs utilisées, et cache cela en "étalant" les pixels. Du coup il n'y a plus les sautes de couleurs dans les dégradés. Par contre, il y a un léger effet "granuleux", mais sur l'écran très fin du zaurus ça ne rend pas forcément mal !
Petit Zaurus devient grand !
La connection d'un Zaurus a un vidéo-projecteur, c'est un peu la quête du Graal ou la pierre philosophale dans le monde du Zaurus : tout le monde veut le faire mais personne n'y arrive... et je l'ai fait ! Petit Zaurus peut maintenant avoir un grand écran. Petit mais costaud ! Bien sûr il n'est pas question de projeter de la vidéo mais seulement des images fixes (diaporama).
Récapitulons les étapes :
Le CFXGA, accessoire officiel de connection Compactflash => VGA pour Zaurus, est épuisé et totalement introuvable.
Sur un forum russe (j'avoue, je ne parle pas un mot de russe, mais google sait traduire !), j'apprends que tous les accessoires de type Compactflash => VGA ont le même chipset, et fonctionne donc de la même manière... et donc avec les Zaurus ! Il y a une demi-douzaines de modèles : Prolink PK201 et PK203, Pretec CompactPresenter, Margi Presenter-to- go, Colorgraphics voyager VGA, LifeView FlyPresenter CF.
Bien sûr, tous sont épuisés. Manifestement, les interfaces Compactflash ne sont plus à la mode...
EBay, Amazon,..., c'est nul : impossible de trouver un de ces accessoires d'occasion.
Par contre, les petits revendeurs, c'est bien ! En fouillant bien je trouve (là encore, traduisez avec google) :
Une boutique au Danemark qui vend des Prolink PK203
Une boutique en Grèce qui vend des Pretec
Une autre boutique en Grèce qui vend des Pretec
Une boutique en Israel qui vend des Prolink
HP aux états-unis qui vend des Colorgraphics Voyager
Un site de matériel spécifique pour personnes handicapées, en France qui propose un appareil ressemblant furieusement à un Colorgraphics Voyager
Je contact la boutique au Danemark, pas de réponse... la première boutique grec refuse de livrer en France... mais la seconde accepte pour la "modique" somme de 150€ ! Donc je saute sur l'occasion.
Je reçois l'engin 3 semaines plus tard
Il existe un driver pour le Pretec dans la ROM Cacko que j'utilise. Manque de bol, le driver est pour un noyau Linux 2.4.18 alors que les Zaurus récents ont un noyau 2.4.20. Donc pas compatible... Il suffirait de recompiler les sources, mais seuls les sources du driver originel pour le CFXGA sont disponibles, et pas celles pour le Pretec !
C'est l'occasion de s'essayer à l'ingénierie inverse. XDelta m'apprend qu'il n'y a que deux octets de différences entre les driver compilé pour noyau 2.4.18 pour le CFXGA et pour le Pretec ! Ensuite, objdump -D m'apprends que ces différences se situent dans des segments de données appelés "crt_800x600x60x16" et "crt_640x480x72x16" que je retrouve dans les sources. Et ça compile !
Vient le moment d'essayer... alors je branche mon Zaurus à un moniteur via le Pretec ; j'obtiens quelques images puis tout se met à planter. C'est l'hécatombe : les processus meurent sans raison apparente !
En supprimant une à une les fonctions dans le driver et dans le programme "mirroir" (cfxgamirror) qui lit l'écran du Zaurus (FrameBuffer) et écrit dans la carte Pretec, j'obtiens la conviction que le problème ne vient pas de l'écriture dans la carte, mais bien de la lecture du FrameBuffer ! Cela colle avec des messages de forum indiquant le même type d'erreur avec des CFXGA sur les Zaurus récents.
La lecture du FrameBuffer est faite via une série d'appel à mmap auquel je ne comprends pas grand chose... je vire tout ça et je le remplace par une simple lecture du fichier /dev/fb0
Et là... ça marche :-)
Plus d'info sur le forum Zaurus FR.