I'd say "good, things are progressing" if that progress hadn't been done while I can't get due sleep, coughing and sneezing. Anyway, I'm done with some basic steps to confirm that a multi-slot palette can be loaded in AnimEDS. Much remains, that will
... [More]
need more lunch-thinking.[todo] make sure multi-slot palettes are read correctly.[todo] buttons to pick slot on skeletton-setup page.[todo] palette slot preference stored in animations[todo] frame editor that obey colour preferences[todo] preview using real colours [todo] timeline using real colours [Less]
|
I do want to have multi-palette in AnimEDS as well, so that you can tint your monsters and reuse e.g. the same sprite for Bilou's front and rear foot, or for Bilou and Pendats feet and hands. Right now, each foot sprite is cloned 4 times and I only
... [More]
have 1 monster so far ... seriously.Allons-y: multi-palettes aussi dans l'éditeur d'animation. C'est vrai, quoi: pouvoir repeindre les bouquins dans l'éditeur de niveau, c'est bien beau, mais ça ne change en rien le fait que je suis obligé de maintenir chaque sprite de pied en 3 coloris séparés et 4 coloris pour les pieds. Vous comprenez bien que dans un contexte pareil, tenter de faire un "pendat" avec les pieds et les mains blanches (couleur règlementaire dans l'armée de Sqrt) est totalement hors de question >_<.So it's time I track the core changes made to Level Editor so that it can benefit from multi-palettes:Initialisation of the Engine object needs an (EXTENDED_PALETTES) additional argument;every call that sets DISPLAY_BGx_ACTIVE now also need to set DISPLAY_BG_EXT_PALETTE;SpriteRam should no longer be initialised with e.g. SPRITE_PALETTE but with one of the slots returned by Engine::editpal($slot,false));when calling SpriteSet::setpalette() to copy from/to VRAM, make sure you call Engine::editpal($slot,true); before copying and Engine::editpal($any,false); when you're done.before loading a SPR file, define SpriteSet::ncolors and wrap SpriteSet::Load() with Engine::editpal calls as needed.Now, AnimEDS will mostly require extended palettes for sprites, not for simply for tiles. So ...[done] make AnimEDS compile in the noswap branch[done] get rid of logo display.[todo] make sure a palette is initialised[todo] make sure multi-slot palettes are read correctly.[todo] buttons to pick slot on skeletton-setup page.[todo] palette slot preference stored in animations[todo] frame editor that obey colour preferences[todo] preview using real colours [todo] timeline using real colours [Less]
|
En testant la démo "Back to School", Facet regrettait l'absence d'un bouton "RUN" dans le comportement actuel de Bilou. D'un côté, un mini-jeu comme "nuts'n'bolts" ne devrait pas avoir besoin d'un tel bouton (pas de grand trou à franchir, et un
... [More]
gameplay plus basé sur le timing que sur les réflexes). D'autre part, je ne suis pas encore décidé sur le mode de fonctionnement de la course.Il faut un bouton pour courir, ça c'est assez évident. Mais sur le DPAD ou comme bouton d'action ? Est-il vraiment indispensable de le garder enfoncé tant qu'on veut courir ? A la fin d'une partie de Mario, on finit par attraper des crampes... Pourtant j'aime bien la phase "gagner de la vitesse" que ce genre d'approche permet, par rapport au mode "un coup de bouton X et ça y est, on court à pleine vitesse" dans Rayman. Au point que Peach et Shantae ont carrément un bouton "ne pas courir".Have you felt the lack of a RUN mechanics in the latest Bilou demo too ? Facet surely did. I was really missing a run button and the little pauses and lack of inertia take away from the fluidity. I'd like to bounce and slide more.After I spent some time thinking about it, it becomes clear that "Bilou's adventure" will have such a RUN mechanics, where speed progressively increases, but that this would be absent of "Nuts and Bolts" (and possibly other in-between arcade games featuring Bilou).I would like, however, to be able to release the button, and not force the power-player to keep RUN button pressed for 30 minutes if he wants to speed-run the game. Fundamentally, what I'd love to try is a sort of "cruise control" behaviour, where you press a button only when you want the DPAD to make you "accelerate". Once you release that button, you keep moving at the reached speed until you release the DPAD as well.Mon impression, c'est que le fait d'accélérer progressivement ou non peut être découplé du mécanisme de "lecture" du gamepad. En d'autre termes, on pourrait avoir un bouton qui n'est pas "courir", mais "accélerer". Si le joueur mêne Bilou dans une direction sans enfoncer ce bouton, Bilou ne change pas d'allure. Par contre, dès que le bouton "accélerer" est enfoncé, la vitesse de Bilou augmente (plus ou moins) progressivement jusqu'à la vitesse maximale. Que celle-ci ait été atteinte ou non, Bilou conservera la vitesse acquise si on relâche le bouton d'accélération.The poll is now open: which sort of RUN do you actually prefer ? [Less]
|
Well, granted, 2 years after its initial release, there's not much more novelty I can bring to Apple Assault. I got feedback from Pierrick and his son about the latest modifications, just took the time to bring the last polish, and here's Apple
... [More]
Assault v1.6. At last. In appearance, not much changes since 1.5, but it's quite a strong difference in terms of rhythm and gameplay, imho. Voici la version 1.6b d'Apple Assault, enfin finalisée, avec juste quelques micro-règlages par rapport à la 1.6a sera mon dernier mot. 4 mois pour passer de la pré-release à la release définitive ... je vieillis, moi. [Less]
|
I tried again, with the updated SEDS and properly charged battery. I could save a first draft (just the shadow lines), and then when I tried to save my "finished" work, the editor crashed again. That's *really* getting on my nerves, now. Hopefully
... [More]
enough, I had a real camera powered up and ready-to-shoot just one floor below, this time, so I've shot pictures of my screen and did some Gimp post-processing to try to enhance and restore the picture into something that could be shown or fixed afterwards. I started the owl again, from the 'shadow lines' that were saved, using the version of SEDS I submitted to NEOflash compo. Everything went fine, and I made tons of intermediate saves. Then I thought "oh, well, that should be it for now", and clapped the lid of the DSi. As usual, I then thought of a small last improvement I could do, so I opened the lid, applied the change and tried to save again ... stalled. So this is what goes wrong: I cannot read/write to the SD media card anymore after I put the device in "sleep mode" for a while. And that happens regardless of whether I use the "1.x" or "2.0" version of my GUI engine. [Less]
|
I took the time to print out Facet's edit on my school owl so that I could train myself and draw a new one on my DSi. It was starting to come out quite nicely, but unfortunately, I've lost it. For some reason, SEDS stalled when I tried to save my new
... [More]
piece of pixel "art" on a new file.Voici hélas tout ce qu'il reste de ma scéance de dessin de hibou sur la DS ... l'idée de faire d'abord uniquement les zones les plus sombres dans une "couleur stencil" avant de doubler la taille n'était (à mon avis) pas mauvaise, mais au moment de sauver mon travail sur la carte mémoire, quelque-chose a coincé sans crier gare et je me suis retrouvé (une fois de plus) avec une DS qui ne répondait plus aux commandes au moment de définir quel fichier de sauvegarde devait être utilisé. La batterie de ma console était fort faible (je n'ai même pas su la relancer), j'espère que c'était juste ça... Ce n'était pas encore la dernière mise à jour de SEDS, non plus.Was the linker no longer able to access the media card ? Was there a bug left in that r1056 version of SEDS ? was the battery's low level critical when power was needed again by the flash hardware ? I have no idea, but that's getting troublesome ...N'empèche, ça m'ennuie ... il serait temps que mes outils de game-making sur DS redeviennent fiables. [Less]
|
This time, I do it the correct way: I start mapping which (hardware) palette is used where so that I can later properly track copies that goes on all over the place and figure out why I can't properly load/store palettes in that "multipal"
... [More]
update.Many of the operations you can do on the PaletteWindow actually involve copies from one of the palette into the others. Ideally, they are all synchronised... as soon as you start editing your palette, it differs from those of the "upper screen" which are kept static"okay" button copy the edited palette into SPRITE_PALETTE_SUB, allowing a preview on the current sprite pageif you're fine, "sure" button copies the edited palette on BG_PALETTE_SUB as well. It's now officially your working palette for the grid.At anytime, you can undo something by clicking "oops", which copies BG_PALETTE_SUB back as the edited palette. There's something the multipal approach changes, however: what is now stored in the .spr file is the offscreen set of (up to) 4 palettes, which is updated every time you flip to another slot. So "okay/sure" only affects how you will draw pixels in the close future, not what is actually stored when saving. The bare minimum I can do is to ensure that onscreen->offscreen update is performed when clicking "okay" as well. I *could* also enforce this synchronisation when going out of the PaletteWindow, but that would break the former user interface convention (where going out without having pressed "okay" at all means you won't save your palette edits). To overcome this, and avoid data loss, I introduce an additional offscreen undopal[] where I can automatically store data, and a "lost" button that can recall what was on screen the last time you left the palette edition "window". [Less]
|
Le support du mode "multi-palettes" dans LEDS m'a obligé à revoir un point assez noirâtre de mon moteur d'interface graphiques: les widgets dynamiques. Bon, c'est un peu pompeux de les appeler comme ça, j'avoue: il ne s'agit ni plus ni moins que de
... [More]
pouvoir cacher certains éléments à l'écran ou d'en modifier l'ordre de priorité au fil de l'exécution du programme. La barre de boutons qui apparaît et disparaît dans l'éditeur de niveaux, par exemple ...La plupart du temps, je m'en sors avec un tableau dont je modifie l'emplacement final. Un bouton "undo" à faire apparaître ? nbWidgets++ ... il doit disparaître ? nbWidgets--. C'est aussi simple que ça. Dans le cas des boutons d'édition, c'est un peu plus subtil, parce que la "zone sensible" qui permet de construire le niveau couvre tout l'écran et qu'il n'y a pas moyen de "cliquer à-travers" pour toucher les nouveaux boutons. Jusqu'ici, je me servais alors de Windows::swap() qui permuttait deux widgets dans la liste d'affichage, mais cette façon de faire rend rapidement le code lourdaud et peu lisible, avec pas mal de bugs qui jouent à cache-cache dès qu'on essaie de changer quoi que ce soit.C'était donc l'occasion d'essayer autre chose: des instructions de saut dans la table des "widgets". En clair, je peux maintenant avoir quelque chose commenormal: (grille) (boutons) (palette) STOPcopie: (curseur) GOTO normalrecolor: (bouton sync) (bouton undo) GOTO normal Je n'ai donc "plus qu'à" choisir le point d'entrée dans ma liste de widgets pour avoir le rendu souhaité. Note qu'heureusement, ce type de pratique était resté rare puisque j'ai la possibilité "d'empiler" des "fenêtres" justement pour éviter ce genre de manipulations. S'il n'y avait pas eu en plus la grande tambouille du changement de linker, je n'y aurais d'ailleurs probablement même pas consacré un post. [Less]
|
Okay, hardware is restored, it's now time to merge summer experiments and converge towards a platform for more pixels, more animations, more levels and more monster design experiments ...[done] merge the 'z-order' branch back: it has proved it's a
... [More]
GoodThing[done] 4-palettes LEDS must be backward-compatible with one-palette spritesets[done] make sure we still see the background and monsters in 4-palettes LEDS[done] restore disappeared iprintf (known bug)[done] barebones to update colours on BG layer in LEDSpalette selection in AnimEDS as well[fork] find something better than Window::swap() to structure widgets.decide what to do with left-handed modeensure I've got all the material to edit/test levels on the DSicomplete the books tileset so that I can change books size (cf. CyanGmou's mockup).fix the landing bug for Biloufix blador.cmd so that bladors can be stunnedrevamp the School's owldraw/animate some pendats [Less]
|
Yes! ça y est! Grâce au matos gracieusement donné par ZeBlackOS -- à savoir un linker de bisounours iplayer -- je peux enfin faire tourner mes homebrews sur la DSi rachetée à Mr. Proper l'an dernier! Vu qu'elle avait même un chargeur de poche pour
... [More]
brancher sur port USB, ç'aurait vraiment été dommage de la cantoner à faire tourner Zuma Revenge pour ma fée :PIl pourra se vanter de m'avoir fait suer, note, au point que j'ai fini par craindre de l'avoir mis hors-circuit au moment de lui faire son "upgrade kernel" ... mais non. C'était tout simplement un problème de formattage. Si les gars de SuperCard insistent sur le fait que la carte microSD soit formattée avec leur outil dédié sous Windows, ils ont en fait une bonne raison: la mémoire de la DS étant limitée, il faut que la table d'allocation puisse tenir dedans.If you just found an iPlayer, but that it seems to stall after showing a blue logo screen but without going to the screen that says "DS Video Expert", chances are that you overlooked the vendors' recommendation for using their own formatting tool for your media microSD card. Granted, that sounds plain ridiculous. Every OS (decent or not) comes with a FAT formatting tool, and you shouldn't have to install third party to do that, and certainly not on a Microsoft OS!.Still, as the DS has limited memory, and given that using their formatting tool *did* unleash the linker's full potential, I can imagine the following scenario: the FAT driver of the linker's firmware is so crude that it *needs* to fit the whole FAT within 1Mo of RAM. A conventional formatting tool will instead try to come with settings that minimizes cluster size, so that you're doing the most of your filesystem... and dismiss FAT size as a significant issue.En l'occurence, ici, la carte de 8Go a été formattée avec des clusters de 32Ko (ce qui est modérément large, mais large quand-même), de sorte que la FAT soit juste un rien plus petite que 1Mo ...(Bien sûr ça pourrait être un autre détail: taille du répertoire racine, le nombre de clusters réservés ...)En toute logique, j'aurais pu obtenir l'effet souhaité sous Linux avec mkdosfs -s 64 -F 32 -f 2 -h 8192 ... Mais pour une autre taille de carte SD, il faut ajuster le paramètre -s en conséquence (#Go*8, je dirais).Here's the result of a filesystem analysis after supercard's tool "correctly" formatted my 8GB media card for iPlayer:SchoolTest> sudo dosfsck -n -v /dev/mmcblk0p1Boot sector contents:System ID " "Media byte 0xf8 (hard disk) 512 bytes per logical sector 32768 bytes per cluster 4404 reserved sectorsFirst FAT starts at byte 2254848 (sector 4404) 2 FATs, 32 bit entries969728 bytes per FAT (= 1894 sectors)Root directory start at cluster 2 (arbitrary size)Data area starts at byte 4194304 (sector 8192)242304 data clusters (7939817472 bytes) 8192 hidden sectors15515648 sectors totaldosfsck /tmp/disk.imgBoot sector contents:System ID "mkdosfs"Media byte 0xf8 (hard disk) 512 bytes per logical sector 4096 bytes per cluster 32 reserved sectorsFirst FAT starts at byte 16384 (sector 32) 2 FATs, 32 bit entries 3992576 bytes per FAT (= 7798 sectors)Root directory start at cluster 2 (arbitrary size)Data area starts at byte 8001536 (sector 15628) 998046 data clusters (4087996416 bytes) 0 hidden sectors 8000000 sectors total8GB formatted with special tool4GB formatted with mkdosfs under UbuntuPourquoi "de bisounours" ? Eh bien, parce que ce linker permet de faire tourner les jeux amateurs (dits "homebrew"), mais refusera de lancer les ROMs commerciales. Merci, tata Raymonde. Et merci à Pierrick de m'avoir filé un coup d'EEE main, sur ce coup-là. Et bien sûr Merci à ZeBlackOs pour le linker ^_^My last fear is gone, btw: although the linker's documentation mention directories such as MUSIC, VIDEO and HOMEBREW where we're supposed to place our files, it can still launch files that are at the root (e.g. beta versions of my tools) and that have been downloaded by runME (currently in /moving/) [Less]
|