takeout.google.com

• 

I have some photos-takeout-20230630T070258Z-001.zip ... presumably created when Google announced they would do cannot-remember-what to their albums service.

• it has multiple folders for the same blog, with date tags.
• it has 3030 files total. There are 30 pair of duplicates
  
• it finds some duplicates between files, but always in the same folder, like 2007-02-04-Bilou_s Book/biokid-4-superjump.png and the same folder with biokid-4-superjump(1).png
• all the files have the same date as the archive. Proper timestamps will have to be looked up into companion .json files
• there's obviously a maximum filename esp. for screenshots (40 characters ?)
• The date in the folder name seems to be album creation time. For this blog, I have 2007, 2011, 2021 and 2023
• There isn't any file with timestamp earlier than 2007. So where are the pictures from 2006 ? like http://photos1.blogger.com/blogger/5640/3676/320/indigo-hints.png or http://photos1.blogger.com/blogger/5640/3676/320/blending-example.png ? Apparently in another castle.
• The oldest entry for which images are available is http://sylvainhb.blogspot.com/2007/03/vous-courriez-jen-suis-fort-aise-eh.html http://sylvainhb.blogspot.com/2007/02/pour-faire-un-aarbreeeuu.html (unfortunately, that's missing the pictures-heavy http://sylvainhb.blogspot.com/2007/02/un-arbre-cachant-la-fort.html)
• whole chunks (like everything 2014 Q4) is missing

Got a new takeout today, of Blogger data. This one is bigger. 800+ MB while the previous was about 200 MB.

• timestamps are now only in milliseconds-since-epoch format
• time span between oldest and latest timestamps is 6284 days... about 17.2 years
  
• 5640 files for this blog (plus .json descriptors) and 2513 duplicates set... that means about every picture has a duplicate :-/
  
• it seems to have some of the missing files mentioned earlier, like bladorstack
• still no indigo-hints.png or blending-example.png, unfortunately T_T
  

I'll have to dig that more. I'll have to merge that with the "blogpress" tools and possibly make myself a "blogger taken out dashboard".

sprck || fail.

Good news: I managed to reproduce in a controlled environment the corruption of a spriteset. Bad news: because I had no idea what was the possible cause of such corruption, I just went through a random set of deletions and then a random set of recycling of the released blocks. And repeating the process from a sane initial spriteset until the "checker" tool reports something abnormal

One interesting thing, though: what's abnormal is abnormal twice: not only I shouldn't have "cross clusters" in my sprite pages (two slots on two pages actually referring to the same tiles), but I possibly shouldn't have "0" at all (it is reserved on most spriterams) and I definitely shouldn't have some odd tile number since the smallest allocation unit so far is 4 tiles.

edit: Another curious thing, on the "animations" subset: one page makes reference to tiles that are not in the spriteset! possibly unused things that were inserted when the page was first created and then deleted before first saved into the spriteRAM. I guess I'll need to make sure I have some automated test that do something like that, too.

edit++: I think I got most issues fixed now. I'll have to give it a run on a real device and see whether I accidently broke something with all the "refactoring"  ...

./sprdo && ./sprck

Bon, ç'aurait dû être un post illustré avec Bouli en train de déplacer des morceaux de code et de trancher des dépendances foireuses "comme dans un donjon de Zelda" avant de découvrir dans un coffre le nouvel objet ultime (en forme de grappin) pour aller explorer plus loin dans le code et vaincre le Bug Final.

Mais bon j'ai trouvé suffisamment de mini-bugs avec les deux premiers tests (effacer une page de sprites ou copier un page de sprites) pour m'occuper pour ce week-end.

Maybe I'll eventually illustrate this with Bouli-the-Hero crawling into the Dungeon of Technical Debt, moving blocks of code to separate model from view/controller, attacked by unneeded dependencies as he tries to get his hands on the Unittest Fairies Hookshot, which is mandatory to access the Bug's Lair.

But I'm already deeper into that dungeon, in epic (?) fight against mini-Bugs and trying to collect as many small keys as I can to get hints that will hopefully allow me to solve the dungeon's ridle.

Blits!

edit: all the other things are now fixed. If you're here for a download link, head to the real release post.

Si vous me suivez sur Twitter, vous avez peut-être déjà vu cette petite animation avec un flash quand on ramasse un power-up, suivi de petites étoiles sur Bilou. De quoi mettre en évidence (j'espère :P) le fait que Bilou a maintenant un pouvoir spécial. Dans ce cas, il ne vous reste plus qu'à télécharger cette petite version intermédiaire pour vous rendre compte de l'effet en vrai, à 60 fps avec le son.

I can at last release a running .NDS with that blits-and-sparkle effect when Bilou grabs a power-up. I got another instance of a corrupted .spr file which took longer to fix (automatic fixer just dropped the unique content and replicated some Bilou heads instead :(. With some more manual control over sprck, I finally managed to repair the file. Oh, and I got the additional hint for riding Spongebops, too.

Ça reste modeste par rapport à ce que mon frère espérait, mais j'approche tellement des limites de la mémoire vidéo et de mon éditeur de sprites qu'il va falloir vous en contenter: j'ai du carrément modifier mon outil de réparation de spriteset pour pouvoir faire des retouches à la main sur "quel tile est utilisé par quel bloc sur quelle page" pour éviter d'avoir des têtes de Bilou qui apparaissent dans les encriers ^^"

Thanks to Smealum, this is one of the most visited download page. You played the game ? You think something is missing ? Let me know with a comment ;)

What's wrong with my spritesheet ?

Ok, this time, let's try to get that .spr file fixed. That's the right timing to get some framework that read and write .spr files on my host platform with the engine's C++ code.

You may remember this spritesheet captured some times ago, where 'striped'  tiles were suspected to be declared free although containing pixels ... It's a bit more complicated apparently: the tool building those spritesheets wasn't processing 32x16 blocks properly. The real "trouble map" (generated by the C++ tool) looks more like below: everything seems correctly aligned between the two versions. Well, everything except the last tile which is mapped on two different pages ...

Ouf. Longue semaine d'inspection du fichier de graphismes, avec un nouvel outil qui profite de mon système de test pour pouvoir utiliser directement le code du SpriteEditor pour faire l'équivalent d'un "chkdsk" pour les fichiers de sprites. J'en ai profité pour ajuster l'outil en PERL qui m'avait servi pour avoir cette "cartographie des problèmes" (ci-dessus) qui montre plus de problèmes qu'il n'y en a réellement (ci-dessous). En cause, les sprites de 16x32 (ou 32x16) qui n'étaient pas reconnus. Encore une petite étape de reconstruction, plutôt facile dans l'environnement PC, et me voilà prêt à attaquer les animations supplémentaires pour la récupération des power-ups.

It would be tempting to believe that with that double-mapped tile fixed, everything would work fine. For small blocks (16x16 pixels), the "blue-ish" free blocks would be used first, then the "red-ish" blobs (16x32 or 32x16 pixels) would be split by try_harder_alloc(). Except that splitting isn't allowed in normal allocations. In fact, if I can rely on cscope's output, splitting is *never* allowed.
Adding some more 16x16 sprites thus grows the file closer to its limit.

edit: Well, i finally decided to fix that by rebuilding the contents of the SpriteRam according to their appearance in the SpritePage, possibly duplicating whatever has more than one link. Since all animation definitions use : rather than a direct offset-in-SpriteRam, no additional work is needed. Good news.

catch this!

A new animation and a good deal of "sprtools" to merge pixels drawn on "lime" DS and animations built on the DSi ... Unfortunately that will not be enough. There's one "dead" moment where you cannot see the "grab-in-the-air" animation whatever you do: when Bilou reaches the top of his jump. The reason is that there's already a "transition animation" running at this time, and that there is no way so far to cancel such an animation for another. I may have to fix that before I can proceed any further: it will likely be very important for super powers.

Une nouvelle animation, quelques coups de sprtools pour fusionner les pixels dessiner sur l'une des DS et les animations présentes sur la DSi. Eh pas de bol: ça ne suffit pas pour avoir un mouvement 'attraper en l'air' qui rendrait le gameplay de SchoolRush plus fluide. En fait, ça marche presque tout le temps sauf lorsque Bilou est au sommet d'un saut. La faute à l'animation de transition qui s'active à ce moment là: le moteur de jeu n'a pour l'instant aucun moyen 'd'annuler' une animation de ce genre. Je vais aller corriger ça, parce que ça risque d'être critique pour les coups spéciaux.

• [done] "force" flag to override transition animations
• [done] make "grab" a dedicated state
• [done] edit areas directly in AnimEDS
• [done] import AnimEDS areas in GOB states
• [done] selectively activate/deactivate areas in AnimEDS

Start+R+A

Reprise du boulot oblige, la progression de cette semaine est moins impressionnante, mais peut être tout aussi importante. Si DaySi a brillamment repris le flambeau depuis la chute de DarkneSs, elle se fait de plus en plus capricieuse avec son bouton R. Oh, il fonctionne, pas de soucis de ce côté ... mais il n'est plus très fiable. Il peut être nécessaire de pas mal le titiller pour déclencher quelque-chose, et quand il se décide, il n'est pas rare d'obtenir des "rebonds" du genre "on/off/on/off" en une seule pression du doigt.

Pressing Start+R+A or Start+R+R in SEDS lets you chose between "Save" or "Save As", changing the way a back-up copy of your file is created. When your 'R' button may automatically read as "R+R+R" for a single press, it quickly becomes unmanageable to have coherent file history. So I finally took the time to add some LOAD and SAVE clickable buttons (plus a tool option to invoke cursor mode in SEDS from the stylus) to compensate hardware deficiences of the DS.

Dans la mesure où ce bouton contrôle la "sauvegarde" dans SEDS et AnimEDS, c'est plutôt génant. A plusieurs reprises, j'ai du re-transférer d'anciennes versions de mes livres pendant que j'en faisais la mise à jour pour corriger une réécriture intempestive alors que je cherchais juste à activer le mode curseur (lui aussi déclenché par R). Mais voici donc une mise à jour de mes outils qui offrent des boutons cliquables (au stylet, donc) pour compenser ce genre de problème. A noter que le bon fonctionnement du bouton L, lui, reste incorrigiblement critique.

AnimEDS updates

Holly Bells! I don't think I've been waiting so hard for holidays since I graduated 0_0.
And to celebrate that, here's the new "running" animation built in AnimEDS. I also animated Spongebop and added a few animations to inkjet, but there seems to be issues with AnimEDS itself, and which slot it decides to save your current work to, so those got overwritten ...

Aah! Des vacances! enfin! Voilà une petite animation de Bilou occupé à courir réalisée dans AnimEDS. Profitez-en bien parce que je risque justement d'être occupé un bon moment à corriger le code d'AnimEDS qui me fait un peu trop de farces à mon goût. Du style "tiens, et si j'écrasais la dernière animation vue avec la dernière animation éditée avant d'enregistrer le fichier sur la carte mémoire }:-D"

Let's recap the required upgrades so far:

• [1145] use some overlay to show which limb is currently pulled, and make sure pulls are properly reset when loading an animation.
• [1141] fix thumbs in the thumblist. set them to the content of the first frame everytime an animation is saved if needed.
• [1142] fix the multi-sprites thumb generation, and automatically set the scaling factor for the 16-32 pixel sizes used in Bilou when that would be enough (i.e. frame fits a 32x32 bounding box)
• [done] ensure setting "delay=1" in the animation editor means 60 frames/second. Otherwise, "split" time doesn't work properly.
• [done] ensure we can hide *all* the crosschairs so that frame editor isn't hiding things and can preview the animation nicely.
• [tryit] don't pause on the "animation terminated" pseudo-frame, and directly hop to first frame, for smoother looped animation edition.
• [dream] crosschair that gets its due alpha-blending. -- there's no support for Sprite/Sprite transparency.
• [1143] allow edition of color 0 and use that to tune the background colours. 
• [1146] ensure we don't overwrite data when we've just loaded a new .spr file
• [1141] don't overwrite data when saving animations.

cleaning up a git repository ...

That's just some misluck: your git push is taking ages to complete. By checking it out later on, you realise you have pushed videos that do not belong there. git rm Videos/* is merely placing a curtain over a broken window: videos are still in the repository, they still make any clone über-huge.
Take your TARDIS and go erase any evidence of your mistake before someone else clone your repository! But before doing that, a git pull is required so that you're sure you're operating on a fresh space-time.

gitk

with this tool, find the revision where your Videos come from. Then grab the commit-id (sha1 hash) of the commit just before. Let's say you messed up on commit deadbeef and that cafebabe was your commit just before.

the command we want to execute on every commit between cafebabe and now is

git rm --ignore-unmatch -f Videos/*

The way to travel through time on cafebabe..HEAD to enforce that is

git filter-branch --tree-filter "git rm --ignore-unmatch -f Videos/*" cafebabe..HEAD

I bet you want to update gitk's view and explore commits to check all signs of your videos are indeed gone. Good.

Now, let's really cover our tracks:

mv .git/refs/original /tmp/refs-original-git
git reflog expire --expire=now --all
git gc --prune=nowgit gc --prune=now --aggressive

If you were lucky and realised your mistake before the push, you're now done. If you had it pushed to the master repository, you still need to push these fixes ahead:

git push -f

And if you have a second clone of the master (at home?) where the videos still exist and that you want it as clean as the master,

git pull --rebase --verbose

(ooh, I wish so hard it had a "--dry-run" mode. Maybe you're better to clone your @home repository, and give the command a shot on the clone first so that you can check it has no undesired side-effects. The man pages claim that pull --rebase is potentially dangerous as it may affect your history. This is precisely what I want, but if for some reason your control on the master repository is weaker (i.e. someone else could alter its state between push -f and pull --rebase), you may want to follow the manpage advice and read git-rebase manpage first.)

Note to future self

Do *not* plug your DS' microSD card in your funky phone even if you're *desesperate* about shooting picutres/video. You did that on Dec. 6th and you've lost all your SEDS/AnimEDS backup history in crossed cluster chains.

And no, you don't seriously have time to port a journalised file system to the NDS to avoid that further on. Sync on a regular basis, and push to Git master.

Yellowl and Redowl

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 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.

owl story ...

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 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.