r4volu7ion

Bon. Si je veux convaincre mes potes de tester mes p'tits Bilous sur leur DS, il serait temps que je m'assure de la compatibilité avec les linkers autres que mon "supercard".

Mon frère est sur le point de se marier, donc il n'a pas vraiment besoin de sa DS pour les semaines qui viennent. Je la lui chipe donc, histoire de voir ce qui coince...

• 26 juin : selon Smealum, ma p'tite démo ne passe pas sur le R4
• 29 juin : premier test sur la R4 de mon frère, visiblement c'est l'initialisation ARM7/ARM9 qui coince
• 30 juin: ouf. la R4 est quand-même capable de charger un .nds avec du code 'custom' sur le processeur ARM7. C'est donc juste que mon code est foireux.
• 13:37 petit debugging à coup de "changement de couleur de fond". l'ARM7 compilé sans NTXM entre bien dans la routine "setupWifi()", mais reste bloqué en attente d'un fifo_temp==IPC_WIFI_INIT. Normal : j'ai retiré toute référence au wifi du côté ARM9 :P ... A noter malgré tout que celà n'empêche plus le traitement des autres évènements ...
• 17:00 "si tu veux, je teste ça ce soir sur mon M3" dixit Oli ... wait'n'see
• 20:00 je re-teste entre deux copies ... apparemment, c'est l'activation de la bibliothèque NTXM qui pose des problèmes ... je reprends mes habitudes de développeur de bootsector: on change la couleur de l'écran en fonction des étapes franchies dans le code, avec une légère variation pour prouver que le CPU est toujours bien actif ;)
• 22:30 ok. c'est l'interruption timer qui douille. je la désactive, ça me fait toujours un runme fonctionnel sur R4 (auto-update et téléchargement compris. fini le card-swapping) mais pas de son :'(
• 22:55 YES! on rajoute Song=0 dans le constructeur de Player et hop! ça marche "revolution ... r4volu7ion ... mem0ry ... m0re mem0ry" comme disais JMJ ;)

I'm doing tests with my brother's R4 this week and trying to find out what's going wrong with that latest demo. After a couple of hacks, it turned out that the ARM7 is apparently halting at some point when the NTXM player is enabled ... weirdo. I already found a couple of uninitialized pointers, but unfortunately, the problem can only be reproduced when launching the software from R4 menu (launching from runme works like a charm, but then you need a no-sound version of runme to get bootstrapped :P)

I've been somehow cheated in my attempts, though, by the fact that i kept the SuperCard in slot 2 while doing tests from the R4 on slot 1 ... Somehow, the FAT library "prefers" the supercard and i ended up running program out of the R4 that was doing I/O (and WiFi upgrades) through the SCSD :P

(PS: je ferai une nouvelle release demain, après m'être assuré que j'ai bien un binaire qui marche, l'EFS lib et le DLDI fonctionnel, etc)
edit: éviter le mélange SCSD dans le slot 2 et R4DS dans le slot 1 pour le dev. on est jamais trop sûr duquel est utilisé par la libfat :P du coup, je m'interroge ... est-ce que j'ai vraiment réussi à avoir le son et le wifi sur la R4 ?

1036 tiles is far too much.

J'ai foiré. Vendredi soir, j'ai voulu pour rire animer une petite touffe d'herbe en plus de mes pommes et après avoir sauvé, vlan, plus rien. Je ne panique pas et je démarre le moteur de jeu qui refuse de charger le niveau avec le message "1036 tiles is far too much". Argh! J'avais oublié ... A force de dupliquer des pages de sprites pour faire des essais, etc. J'étais arrivé *tout juste* à 64K de graphismes, ce qui correspond à la limite que j'avais imposée pour rester dans une gestion toute simple de la mémoire.

Bon, le problème sera vite résolu dans l'éditeur de niveau (qui était de toute façons prêt à gérer 256K de graphismes, c'est juste un oubli), mais pas en ce qui concerne le moteur de jeu. Il va donc falloir que je fasse le ménage mais pour l'instant, SEDS est complètement dépourvu de toute fonction "effacer". On peut dupliquer, ajouter, remplacer par un bloc complètement transparent, mais effacer, ça, non.

Oops. Trying to animate the grass in Bilou's woods turned out in no fun at all when the game engine refused to launch the game with "1036 tiles is far too much" error message. It seems like i forgot that i just reached the 64K of pixels the day before (well, out of which only roughly 1/4th of the tiles need to be kept :P) ... Patching the Sprite Editor to let it edit the spritesheet again was trivially easy, but it won't help as there is so far nothing that *deletes* data in my sprite editor ...

Du coup, je me suis fait un nouveau petit "plan de bataille" pour y remédier:

• [done] remise en route des "fichiers backup" en cas de sauvegarde
• [done] construction d'un "fichier archive" lorsqu'on remplace un des fichiers de travail par un nouveau tileset (p.ex. importé par WiFi)
• [done] une petite mémoire "undo" et un bouton pour rappeler sur la grille d'édition le dernier bloc "écrasé" lors d'un enregistrement dans la "SpriteTable"
• [done] ajouter la possibilité d'avoir un "bloc manquant" dans la SpriteTable, pour effacer des blocs tout en conservant l'alignement général -- et réorganisation des tiles contenus en conséquence.
• [done] effacer toute une page

Ceci fait, je devrais pouvoir 'réparer' ma p'tite forêt. Ensuite, eh bien, il sera temps de penser à la possibilité de séparer les tiles à charger directement en VRAM de ceux qui restent "dormants" en mémoire centrale (p.ex. pour les animations)

Une nouvelle démo

Bon, une petite anim' enregistrée et un nouveau petit .nds autonome pour que vous puissiez tester les amélioration de mon moteur de jeu sur votre DS à vous. Au programme, le nouveau scrolling , la gestion des collisions , les test-points conditionnels (avec moins de bugs dans la gestion des déplacements de Bilou).

Bref, faites-vous plaisir: téléchargez la "ROM" ;)
le programme va démarrer et afficher "Ready." sur la console, sur l'écran du haut. A ce moment, appuyez plusieurs fois sur Y pour exécuter le niveau pas à pas jusqu'à ce que Bilou tombe. Vous pouvez alors le diriger avec le pad. Vous pouvez aussi changer de méthode de scrolling en appuyant sur START.

Here comes a new demonstrator of my game engine, so that you can test the latest improvements on *your* DS : collision management, conditional test-points, new scrolling ... So stop hesitating and start downloading. Once launched, the program will display "ready" and then wait for you to press 'Y' button half a dozen of times to perform step-by-step initialization of the level. As soon as Bilou starts falling, you can control him with the D-pad. You can also toggle the scrolling algorithm by pressing "START".
Les bugs connus:

• lorsqu'il retombe sur le sol, il arrive que Bilou se mette à glisser sans s'arrêter
• si Bilou heurte un mur en saut, il y reste "scotché" tant que vous gardez le bouton "gauche" ou "droite" enfoncé
• quand Bilou n'est qu'à moitié sur une plate-forme, il "tremble" et l'écran du haut défile à toute vitesse. (ce n'est pas vraiment un bug: je n'ai pas encore d'animation pour le montrer en déséquilibre)

PS: il va falloir que je chipe le R4 de mon frère par contre. J'ai régulièrement des testeurs sur dev-fr qui m'indiquent que mes roms ne marchent pas chez eux, et là, en principe, c'est tellement simple que je ne vois pas ce qui peut ne pas marcher. Le DLDI, peut-être ?

edit: j'ai retiré le lien vers la version "efs2.0", qui ne résout apparemment rien pour les utilisateurs de R4. J'ai visiblement un problème avec le code ARM7 qui ne fonctionne pas comme prévu. Investigation en cours ...

Let's >> scroll >> baby ...

Hop. Un p'tit temps de midi et je rattaque le scrolling, maintenant capable de "suivre" véritablement Bilou (plutôt que de se contenter de mimer ces déplacements au risque de finir par le faire sortir de l'écran :P)

Le plus délicat, c'est d'éviter un scrolling "par à-coups" comme on avait tendance à le voir dans les jeux Titus, ou (pire) dans le Game Maker de mon enfance :P

It's about time I focus on scrolling again, so that we can actually "track" Bilou's position. So far all it did was mimmic'ing Bilou's moves but as you hit ceilings and floors, it slowly gets off. I realise when playing games of my childhood that a smooth and smart scrolling is the key to a great platformer experience. I want to avoid "quantum leaps" that was typicall from Titus games and that sloppy "I'm following you at my speed don't move soo fast" scrolling coded in the Recreative Game Maker my Brother(s?) and I used for Badman series.

J'ai eu droit à quelques effets marrant en débuggant (ou déboguant?), comme l'écran qui fait le point-fixe autour d'un moustique invisible tournant autour de Bilou (ça, ça fait mal aux yeux), d'où les dernières lignes) ... ou alors le scrolling qui fait des sauts de puces en arrière après avoir fait un pas de géant en avant ...

Bref. Le dernier truc qui reste douteux, c'est le fait que l'écran scrolle presqu'immédiatement vers le haut dès que Bilou saute ... je suis pas fan (ça donne un peu le mal de mer), mais je ne vois pas trop comment l'éviter proprement.

As usual, there has been some odd-and-funny bugs while working on it, such as the camera suddenly tracking "a bee that fly around Bilou" rather than tracking Bilou himself. The last 4 rows of code shown above are designed to avoid that : they prevent counter-centering moves from happening. Yet, it turns out that perfectly keeping Bilou in the center of the screen isn't so sexy. You quickly get sick when you jump often ...
I dug for Commander Keen videos, where you can observe a surprising but efficient approach. The camera only keeps Keen in the center of the screen (vertically) when he's on the ground (not quite at the center, but almost. I'd say some 32 pixels lower than the centre). However, when Keen jumps, the camera remains at its current height, giving a better view of where you're going to land. The only exception is when Keen gets really close to the edges of the screen (some 8 pixels close from the top or 32 pixels close from the bottom). Only when Keen *lands* does the camera quickly bring him back at the center of the screen.

Si on compare, la politique dans Commander Keen est assez particulière. Tant que Keen est au sol, il est maintenu dans une zone proche du centre (pas exactement au centre, mais presque; je dirais à 32 pixels du centre au maximum), mais lorsqu'il saute, on ne scrollera verticalement que si Keen approche le bord haut (ou bas) de l'écran (je dirais de 8 pixels au moins, probablement plutôt 32 pour le bas), et ce n'est qu'au moment ou Keen "atterit" sur une plateforme que le scrolling vertical se recentre. Je trouve que c'est un assez bon choix en somme : celà permet de conserver le point de vue que le joueur avait au moment de prendre la décision de faire un saut, et donc de mieux gérer l'endroit où le personnage retombe, tout en ayant un bonne vue d'ensemble du niveau pendant que le personnage "marche", tout simplement.

Bang!

Alors ? Quoi de neuf dans ce code, me demanderez-vous ? Eh bien, la gestion des collisions. Oui, je sais, c'est assez élémentaire et il y a tellement longtemps que ç'aurait dû être fait qu'il n'y avait vraiment pas de quoi en faire un fromage ... En plus, on en est encore qu'au balbutiements puisque ni Bilou ni les petits vers ne se "rendent compte" que la collision a eu lieu (entendez par là que leur comportement n'est pas affecté d'un iota). Seul le fond de l'écran virant au rouge me permet de m'assurer que la collision a bel et bien été détectée...

Alors pourquoi avoir attendu aussi longtemps ?

Bin parce que je voulais faire ça proprement, tout simplement. En donnant à chaque composant du système son rôle et pas plus. Je veux aussi pouvoir me restreindres à certains types de détections (par exemple, aucune des collisions ver-ver ne m'intéresse), permettre à un sprite d'avoir différentes régions qui réagissent différemment (des "points faibles" et des armes, par exemple) et changer tout ça en fonction de l'état du personnage ... Le taille-crayon "furieux", par exemple, n'aura plus de point faible et même lui sauter dessus blessera Bilou, alors que le taille-crayon assomé n'aura plus aucune zone dangereuse mais au contraire sera "transportable".
L'astuce, c'est donc de garder une liste séparée par "type" de collision, et de définir, pour chaque collision, quel personnage provoque la collision et quel personnage la subit. Bref, vous l'aurez compris : je n'ai pas fini de vous en parler ;)

Edit: oh, oui, j'ai essayé d'améliorer le scrolling (et surtout le tracking de Bilou) ... C'est mieux, mais pas encore vraiment ultra au point.

Woods In Progress

Thanks to some awesome guys at pixelation, my little woods are progressing rather nicely. It's not always very easy as i cannot manage to come with decent pixels with PC tools only, so i need PC-to-DS and DS-to-PC conversions quite often.

After Zeid and tehWexxlorz convinced me (and helped me) to re-think the look of Bilou himself, after Zeid (again) bringing me to give those trunks another try with a "more interesting palette", after Ichigo pointed out how to get a coherent contrast/lightness/saturation over the whole forest, i'm now trying to follow Lackey's advices (and a bit of AdamAtomic's too) to get a fresh new look for my treetops. The picture above, for instance, was a print out of Lackey's edit (bottom) and my first attempt to re-produce it with a simple "bunch of leaves" shape (top).

Les conseils glanés sur Pixelation commencent à devenir porteurs ... Après la révision du look et des couleurs de Bilou (grâce à Zeid et theWexxl0rz), les nouveaux troncs d'abres et l'ajustement du contraste du décor (grâce à Ichigo), c'est au tour des feuilles d'en prendre pour leur grade. Je me suis d'ailleurs imprimé les commentaires de Lackey (image d'en-bas sur la photo d'en haut ;) et ma première tentative avant de ré-importer mon gros feuillage tout plat pour le remanier avec SEDS.

This is a definite departure from the "minishcap style" that i wished to follow initially, and imho, it's not really a bad thing. Unfortunately, i don't have anything like a "level map exporter" so far, so all i can offer you is a screenshot of the level editor showing you a new tree i've been working on yesterday.

Comme vous le voyez, on est bien loin du style "minish cap" imaginé au début ... Ceci a un look ... plus commodoresque, je dirais. Et je vous prie de me croire que j'utilise à 200% mes deux plans de décor sur ce coup-là! Il me faudra d'ailleurs un "copier/coller" sur des zones entières dans l'éditeur de niveau si je veux pouvoir continuer dans ce sens-là.

Pretty nice, but pretty hard to do, and fully using my two layers of background tiles. I will really need an "area cut&paste" tool in the editor if i'm to live with trees like that.

I don't know how you like it. Personally, i think it has some kind of C64 look, and that i still lack some alternate tiles to avoid getting something that shows collection of leaf balls next to each other ;)
Oh, et côté code, j'ai une autre bonne nouvelle à annoncer, mais vous attendrez que ma petite illustration soit faite ... na.

ça grimpote ...

Petit aperçu de ce que m'ont permis mes derniers bricolages sur SEDS et LEDS. Le champignon, tout d'abord, qui a bénéficié du curseur défini dans le post précédent.
Puis les blocs d'herbe qui utilisent la pleine puissance de la construction de niveaux sur deux plans séparés (il n'y a que de l'ombre sous l'herbe, la terre, bin c'est juste des blocs de terre ordinaire qui sont sur le calque d'en-dessous). Et enfin les petites pentes, construites avec seulement 5 tiles supplémentaires, à grand coups de "mode rafistolage" dans LEDS (comprenez: édition tile par tile plutôt que bloc par bloc). Allez, je rajoute les boutons "retourner horizontalement" et "retourner verticalement" dans l'éditeur de niveaux et je pourrai vous faire des "descentotes" aussi ;)

Cursor for picking tiles ...

Hmm ... j'ai un peu bricolé quelques nouveaux tiles pour la forêt, et plus j'avance, plus le côté 'édition bloc par bloc' me cause des soucis. J'ai une technique assez simple pour m'assurer que les objets de plus d'un bloc aient une forme correcte : le scrolleur.

Je dessine la gauche de mon champignon, je sauve sur un bloc, puis je le décale de moitié, je garde la moitié droite à gauche et une moitié vierge à droite. Reste à construire le début de la droite de mon champignon. Ce bloc (central) ne sera évidemment jamais sauvé : une fois la "droite du centre" dessinée, je re-décale pour la ramener à gauche en tant que "gauche de la moitié droite".

C'est tordu, pas vrai ? et le plus casse-pied, c'est que du coup, c'est pratiquement impossible de venir ré-éditer l'objet plus tard (à part chipoter à gauche ou à droite, mais plus au centre). D'où l'idée de rajouter à SEDS un widget "curseur" qui permettrait d'aller chercher n'importe quel groupe de tiles dans la SpriteTable (y compris à cheval sur plusieurs blocs) pour l'éditer. Ce curseur permettrait aussi de réécrire rapidement le sprite en cours d'édition là d'où il vient (par un R-R, par exemple), ou d'éditer 4 blocs 16x16 dans une matrice 32x32 ... Bref, il y a du boulot.

Oh, je n'oublie pas non plus mon fameux "éditeur de dégradé HSv", ne vous inquiétez pas ;) Et tiens, puisque j'ai la ligne de commande sous la main, je vous fais un snapshot de l'évolution dans desmume. Pas encore super-utile, mais j'ai la fonction "charger un ensemble quelconque" qui marche. Allez, je m'ferai le retour vers la SpritePage un autre jour ;)

edit : status

• [done] move cursor around
• [done] load/store tiles from the cursor
• [done] dismiss cursor
• [done] clicking the sheet moves the cursor
  
• [done] fix 32x32 grid edition
• [done] meaningful buttons in "file" window
• [done] fix sheet-to-sheet copies
• [done] decouple grid/sheet size
• [done] toggle grid size when "zoom" button is pressed.

disons, vu les changements que ça amène dans le coeur du software que ça marque le début de l'ère "0.3"

Pharaohs Curse

Un de nos favoris sur C64 : Pharaohs curse (Synapse Software, 1983). Malgré un look minimaliste et une bande son surprenamment pauvre pour le SID, c'est un jeu qui mérite que l'on s'y arrète. L'idée est simple : la course au trésor dans une pyramide égyptienne. Une sorte de précurseur de Rick Dangerous, mais dont les niveaux manquaient cruellement sur VGmaps :P

Pharaoh's curse. A flip-screen platformer where you need to collect every treasure in the pyramid before you're allowed to play a deeper game at increased speed. Annoying random traps, fast-moving mummies that shoot at you ... hours of child fun back in time. A testimony that people first tried to have VIC20 games running on the C64 before they started to make use (and then only overuse) the C64's specific chips.

Ce qu'il faut savoir, c'est que le jeu a été conçu à l'époque du VIC20 et de l'Atari800 (comme en témoigne les vidéos "speed run"). On démarre avec relativement peu de vies, mais chaque trésor collecté rapporte une vie supplémentaire. L'antique version VIC donnait directement accès à l'entièreté de la pyramide, mais ce n'est plus le cas dans la version C64 où seuls 8 tableaux sont disponibles au début du jeu, et chaque fois que tous les trésors d'un niveau ont été collectés, le joueur redémarre à l'écran d'accueil avec 4 trésors supplémentaires à récolter. L'astuce c'est qu'évidemment celà s'accompagne d'une augmentation de la vitesse du jeu, pour corser un peu la chose.

The most notable feature of the game is likely the presence of free (organic?) level design element that make some screen looks more like caves, where most platformers by that time had pure geometric shapes. Everytime a treasure is collected, an extra life is granted. Because treasures don't respawn during the game (dying make you restart at your entry point on that screen), the further you go, the harder it is to find another extra life.
The player can leap over holes rather than really "jumping": there is no gravity whatsoever, making some timing of actions easier, and that also packs more action and puzzle into one screen. That's a common point in many platformer of the era (Monty series, Willy series ...). On the other hand, you can fall from any height without damage -- fairly rare -- but trust me, you'll be given much enough way of dying without that.

Another point -- shared with Qwak -- is that you rarely play the same game twice. There's a single "entry level", but from there, you'll end up into one of the 4 levels of the second row randomly. It's not as "unique experience" as in random-generated levels such as spelunky, but it avoids annoying feeling of "dejavu" and gives the player the impression that "he might be more lucky the next time". One of the antagonist -- the Winged Avenger -- can also carry the player at random location (and steal the key he's carrying). That's annoying as hell for the experienced player, but that gives the beginner a neat way of exploring more in a short amount of lives.

Torx s'étonnait lors de la C64-party de cette évolution impressionnante entre "pharaoh's curse", "Giana Sister" (Time Warp, 1987) et "Flimbo's Quest" (1990), pour la même machine. Sur console, celà se comprenait par l'évolution du hardware de la cartouche (RAM embarquée = plus de niveau, d'animations, etc.) Mais sur un micro ?
Eh bien, comme je disais, même si les trois jeux sont réalisés sur le même hardware, PC a été conçu pour VIC, et donc n'exploite absolument pas les possibilités de caractères multicolores du C64 (d'où le fond tout noir) et même les personnages sont monochromes et peu nombreux. Giana, lui, est pleinement prévu pour le C64. Les développeurs se sont assurés par exemple que 8 sprites seraient toujours suffisants. Quand à Flimbo, c'est au départ un jeu amiga "rétro-porté" sur C64. La conception était donc d'autant plus ambitieuse (scrolling parallaxe), et le portage présenté uniquement comme un ultime défi technique à des programmeurs déjà bien équippés pour travailler sur le C64 (toutes les routines son etc. réutilisées depuis des jeux antérieurs) là où un Giana devait apporter presque l'intégralité du code.

Et si le hardware qui faisait tourner le jeu était toujours le même, on peut s'attendre à ce que l'équippe de Flimbo ait utilisé des compilateurs et un environnement de programmation sur amiga même pour la version commodore. Croyez-moi, ça fait un monde de différence par rapport au BASIC du C64 qui ne permettait pas de scrolling sur les lignes de code ...

Une reprise de Pharaohs Curse avec les sprites de Rick Dangerrous sur la DS ? Ouaip ... pourquoi pas ... pour les 40 ans de CJ, peut-être ;)

Bilou par Wifi ...

Hehe. Je vais me faire enflammer avec un titre pareil. Non, on ne joue pas encore à Bilou par Wifi, mais j'ai transféré les couleurs de mes tests sur Pixelization vers SEDS histoire de pouvoir essayer un p'tit Bilou (mais alors vraiment tout petit, là). Ce qui veut dire que les réorganisations de couleurs dans la palette, c'est fait aussi. Je me ferais bien un petit "publier le sprite courant par Wifi" avec conversion immédiate en .png à la réception sur le PC, tiens ;)

Oh, keep cool. You cannot play Bilou vs Bouli over wifi. Not yet. But i can beam my palettes to SEDS using Wifi and give a try on new looks for Bilou. I made quite a bunch of very funny animations with those colours, and i have to admit that it's working well. Unfortunately, i made *too much* animations, and i should rather have polished my code instead. When i tried to finally save my work and go to sleep, the display looked strange, and when i later tried to re-load the sprites, all i got was a guru meditation.

The most likely explanation is that the code for managing animation is very rusty -- one of the very last remains of the initial code for SEDS that has never been refactored, and it obviously contain bad practice memory management stuff that have last beyond initial expectations. I lost a couple of things in the process, but nothing i couldn't re-do. Hopefully enough, it happened on a testbed spritesheet, and not on my preciousss "greenzone" tileset. It's a good thing to see that my tools for handling .spr files can recover some corrupt data too ;)

Aaargh. sur ma lancée, j'ai essayé de faire un deuxième Bilou un peu plus grand. Puis je l'ai animé pour donner l'impression de "respirer" et j'ai refait des balles de formes diverses (plus applatie et plus ronde) sur la même base. Puis j'ai joué à faire marcher mon p'tit Bilou et donner quelques expressions au plus grand.

Ouais. Bin j'aurais mieux fait de finir le debugging de mon éditeur, pas encore capable de gérer correctement les longues animations qui s'en sont suivies. Au moment de sauver tout ça, il m'a montré des pages de sprites de plus en plus louche ... Pas dupe, j'ai voulu recharger : bardaf : Guru Meditation.

Comme vous pouvez le voir, la plupart des "tiles" seront récupérables (à la main dans Gimp, j'imagine), mais les infos qui disent quel bloc utilise quel tile, là, c'est irrémédiablement foutu >_< edit: comme je m'y attendais, c'est plus que probablement dans la gestion des animations que se trouve le gros bug. C'est du vieux code d'avant que je ne me mette à la bibliothèque standard du C++ (vecteurs, maps, etc) qui est encore plein de malloc(sizeof(x)*n) et qui manque de if(i>n) return; si vous voyez ce que j'veux dire

blogger/picasa

Bien sympa, cette nouvelle fusion blogger/google/picasa, en ce qui me concerne. Je peux avoir toutes les images de mon blog sous la main en un instant ...

Téléportage de palettes ...

De nouveau, c'est sur mon éditeur de sprites que les lumières du développement se braquent. Si je veux continuer à faire de zolis pixels, il me faut plus d'outils pour manipuler les couleurs au coeur même de l'éditeur.

J'ai donc un peu bricolé, en attendant d'avoir mon "générateur de dégradés HSV", de manière à pouvoir quand-même tester de nouvelles palettes de couleurs sans être nécessairement obligé de chaque fois transférer une image complète (après traduction par "imlib2spr.pl") etc.

Once again, development efforts are concentrated on the Sprite Editor, which somehow explains why there are so little posts these last days :P
I finally completed the new feature that should help me doing more cute pixel art on my DS: the palette beamer. Sure, it won't completely remove the need for an in-editor colour manager (such as HSV raster generator), but at least it allows me to play with imported colours without requiring the boring work of converting some picture into a spriteset, importing it via runme and then (at last) working on it.

Voici donc, pleinement fonctionnel, le téléporteur de palette, capable, grâce au petit serveur beampal.pl de recevoir de nouvelles couleurs via le Wifi et de les stocker ou bon vous semble dans la palette courante. Je suis limité à 16 couleurs par fichier pour l'instant, mais c'est une question de règlage de pouvoir voir défiler les autres couleurs sur un des "slots" ... Le prochain stade, maintenant, c'est de pouvoir réorganiser les couleurs via le nouveau widget "QuickPal", en-dessous de la grille ...


Next step ? Well, the "QuickPal" widget currently allows one to build his own raster by picking individual colours from an image, and then "lock" that raster while you're going on with edition ... all it still lacks is the ability of re-inserting those colours in the palette in the order they are found in the QuickPal. Wait and see.