Sprite Editor for DS : la photo

Bien, j'ai tout un tag pour les photos - les vraies - et dedans quelques-unes avec des prises de vues sympathique de mon éditeur de niveaux ou de l'éditeur d'animations que j'utilise depuis School Rush, mais une photo de mon "Sprite Editor" ? eh ...

Je ne peux pas dire "rien", mais ce sont des photos tellement vieilles ou ne montrant que partiellement l'interface. Il était temps que j'y remédie, même si je n'ai pas de développement en cours sur SEDS pour l'instant.

Would you believe it ? Sprite Editor for Nintendo DS is my oldest homebrew, and yet there was no satisfying photo of it running on real hardware on this blog !? There were some, sure, but either showing uninteresting screens, or with a user interface so old that it barely looks like SEDS at all.

I had to got that fixed, be it only to have something for people following my #SpriteEditorForDS hashtag on mastodon or bsky ! 

Corrigeons l'appleman ...

Bien, j'ai pu un peu montrer l'appleman qui roule à mon frangin lors de l'anniversaire de J.L.N l'autre jour, et il avait plutôt apprécié. Surtout les interactions supplémentaires que j'envisage avec les autres ennemis du jeu.

We have rolling appleman now, and both my son and my brother do like it. But before I start adding all the fun interactions I envision (and they're awaiting) using that new mechanics, I have some clean up to do.

Mais avant de m'attaquer à ce genre de jeu, il me fallait d'abord corriger quelques étranges bugs apparus près de ces plateformes rajoutées dans le niveau de l'arbre creux en construction.

Le premier est un curieux alignement: au moment où la pomme commence à rouler sur une plate-forme à sens unique, elle se retrouve curieusement alignée fort bas. Comme si le bas des tiles était le sol, plutôt que le haut comme prévu. Ou comme si la géométrie de la pomme était beaucoup plus plate que ce qu'il faut.

Two bugs were requiring some attention. The first affected the ground height of the rolling appleman on jump-thru platforms. A quite perplexing thing which I expected to require tracking of coordinates and tile properties as the debugger would let me dig within some of the more complex functions of the engine such as "do_slopes". So I went on posting debugger screenshots as bread crumbles for a non-existent time machine. 

Post by @PypeBros@mastodon.social

View on Mastodon

C'est le genre de situation où je sais que je vais devoir regarder en détail ce qu'il se passe dans les fonctions do_slopes ou cando, parce que c'est là que se prendront les décisions. Et je sais d'expérience qu'il va me falloir une idée précise des coordonnées impliquées, où noter les résultat intermédiaire etc. 

Je suis donc reparti à me faire des petites annotations dans mon carnet et une série de captures d'écran du débuggeur qui me servent de machine à voyager dans le temps. Et on retrouve bien les deux problèmes: la bounding box definissant la taille de l'appleman grandit entre l'état "lancé" et l'état "roule", ce qui veut dire qu'il se retrouve automatiquement avec les pieds dans le sol. Mais en plus de ça, la hauteur du sol n'est effectivement pas correcte. Un résidu du passage au nouveau système de propriétés du décor qui n'avait pas encore été corrigé.

After numerous breakpoints and conditions and instructions stepping, after using a second emulator in parallel to figure out coordinates, check bounding box size and the like, I eventually noted that the height for a "direct" tile like those used for jump-through  is 0. That's intended for "look at what's beyond" when walking on some ground. That's fine for water or air or maybe even vines to be climbed. Not for any sort of ground. Easy to fix.

Now, the second one the appleman didn't pretend to enter the "jump-thru" platforms while being carried. That led to weird situation where it would push on Bilou, preventing him from even approaching the platform. Here the issue was in the properties we told the gravity controller to test for. It doesn't need to be AIR for the appleman to move through. In fact, anything the carrier could move through would be equally fine for the carried object. In the capture below, I only fixed the state when the appleman is facing right, so that gives you a nice fixme/fixed comparison.  

Autre effet bizarre: l'appleman ne voulait pas entrer dans ces régions "jump-thru" pendant qu'il était transporté. Un choix malheureux des propriétés recherchées qui insistait sur le fait que "ça doit être de l'air". En fait, non: partout où le joueur peut passer, ce qu'il transporte doit pouvoir passer aussi.

(la petite capture animée montre un état intermédiaire où j'ai utilisé ddd pour modifier les propriétés recherchées quand on est tourné vers la droite, mais pas encore quand on est tourné vers la gauche, pour vous faire un "avant/après" plus parlant)

Vous noterez peut-être dans ces petites captures un moment où Bilou se retrouve avec 4 mains. C'est le problème que j'avais cherché à (et cru) résoudre en Mai dernier ... manifestement, ce n'est pas encore complètement au point. 

20 ans de Nintendo DS

Il y a 20 ans, j'ai reçu plus qu'un nouveau gadget. Une nintendo DS .. avec aucun jeux, en fait. On nous avait annoncé un nouveau Super Mario, un nouveau Zelda et un nouveau Yoshi Island. Bien plus intéressant que les projet rub et zoo keeper qui avaient accompagné la sortie.

Comme j'avais envie de revenir un peu sur tout ça, j'ai fait un petit récapitulatif de la première année de développement et blogging sur bsky ... et d'une façon assez surprenante, ça a explosé les réactions.

Et ils n'ont pas encore vu cette ligne du temps tortueuse qui reprend les milestones, les releases et les interventions et commentaires de "guest stars" 

bin/Eterm-borderless

Ah. I'm still using Eterm from times to times, but its default color palette isn't that impressive. I've been using it without border or any widgets for decades thanks to the drag-to-move and drag-to-resize features of Enlightenment. but in August 2024, I made a few changes to the "Eterm-borderless" script that is bound to ALT+F5:

Eterm --borderless 
      --font-fx none        # else it tries dropping a shadow 
      -f white              # foreground color
      --double-buffer 
      # -x                  # (alias for --borderless)
      --cmod "96 255 255"   # trick for tinting the background towards green
      -O                    # transparent
      -0                    # immotile transparency optimization
      --scrollbar=0 --buttonbar=0 
      --color8 rgb:60/60/60 # better dark-grey
      --color3 rgb:cc/aa/00 # orangeish dark yellow looks better
      $* &

• --viewport-mode is fundamentally what I do with my "restore-bg" trick
• the default color8 (dark grey) is rgb:33/33/33, which is really too dark for any purpose
• today's finding: an alternative to -f white could be --colorDB white -f rgb:dd/dd/dd --color7 rgb:bb/bb/bb. That gives you a default color that is bright-but-not-quite white while still having the true white when things are bold, without sacrifying any shade of gray. 

I must make some isocahedron gem!

This is a screenshot from @makeshifted, back in December 2022, that showed up in the last snapshot the Internet Archive could take of my twitter timeline. A repost with the annotation "3D was *that* awesome back in the Assembly 9x #demoscene days."

It showed up again a few times ago and I told to myself "you know, those stonekeys in Commander Keen ? Well, if I can make NDS 3D look that sleek, I won't need to pixelstudy them!

And it appeared again, posted by @benji__t this week-end while I'm doing my farewell tour on twitter.  

One possible system of Cartesian coordinate for the vertices of a regular icosahedron, giving the edge length 2, is: $${\displaystyle \left(0,\pm 1,\pm \phi \right),\left(\pm 1,\pm \phi ,0\right),\left(\pm \phi ,0,\pm 1\right),}$$ where ${\displaystyle \phi =(1+\sqrt{5})/2}$ denotes the golden ratio. -- https://en.wikipedia.org/wiki/Regular_icosahedron --

Oh! look at that ...  

Take a tetrahedron of psi, split summit so that it turns into a 2-edge, and voilà! isocahedron !

- - - 

those words above were written around the 19th of February, last year. I haven't written a single line of DSGL to make it appear in the infinite pyramid, and while I initially thought of using it as keygems, I realise that what they really be are the "magic stones" that you collect after defeating bosses.

Slides testing

I've been re-drawing the water slides directly on the "three rooms" test screen, because it feels easier to prototype there than within the reconstructed green zone level. Then I've been prototyping different things about it that I had in my notes ... only mostly ruling out some options so far. For instance, the idea of re-using the sprite of waterjets to avoid issues with waterfall-to-slide transition should be forgotten ... it helped me coding something to select the layer where Gobs should appear ... one of the things I'll need for the smashing fist.

Another such test was placing some special tiles along the slide, in an attempt to make them trigger some "fall and slide on slippery ground". 

That failed. Almost completely. I had to create an empty animation just to avoid the normal "special blocks handling" from deleting chunks of the slope as soon as Bilou touched them.

I also had to drop the idea of placing "jet" tiles in an attempt to push Bilou harder out of the slope at its bottom : they allowed (but only sometimes) Bilou to hover the whole slide upwards ! 

That fist goes SMASHing

It took me about 30 minutes to finally craft the script needed to bring in the smashing fist I had drawn back in February. I'm a bit sorry that it took me so many month to finally be ready to write that script. Part of it because I had not given it any priority over applemen or sliding water, but mostly because finding some time for doing homebrew is more and more complicated, unfortunately ^^".

(screenshot saturday on mastodon and bsky) 

Similarly to what happened with the rolling appleman, having the bare functionality is just unlocking many other things to do to get it satisfying, like having dust clouds when it hits the ground of having some screen shaking. 

Voià. J'ai enfin transféré les pixels du gros poing écrabouilleur et j'ai même trouvé 2x15 minutes pendant cette semaine de folie pour écrire le script qui le fait monter et descendre. En deux fois parce que le laptop ne tient plus 30 minutes d'affilée. Ça débloque une belle quantité de trucs à faire, mais si vous voulez bien, je vais déjà essayer de comprendre pourquoi je n'ai plus d'électricité depuis le 30 et essayer de faire réparer la chaudière qui n'a pas aimé ça.

• [done] adjust layer priority so that smashers hide in walls
• [todo] shake the screen when hitting the ground
• [todo] shoots clouds of dusts when hitting the ground
• [todo] get a green pillar following them. That could be a 3D item

and well, surprisingly enough I hadn't yet a way to change the layer order. That shall be bit $2000 of the flicker-control word (defined through GobExpression opcode F since bit $8000 already controls whether the given GOB should appear in front of every other GOBs of the same layer (used e.g. by "weapons" you throws)

Petite mise à jour parce que j'ai ajouté 2 autres smashers côte à côte pour voir un peu ce qu'ils donnent dans une configuration "défense de couloir".