Sur bsky, MagicalScope nous poste d'impressionnants designs d'objets magiques qui sont ensuite vendus à des internautes. Parmi eux, je suis tombé sur une potion-qui-marche particulièrement inspirante. J'ai d'abord eu le réflexe de voir comment je pourrais l'intégrer comme nouveau perso dans la pyramide jusqu' ce que je réalise que mon brave scorpeye pourrait simplement profiter du type de déplacement que suggère cette potion tout en restant lui-même.
Many of the tutorials I had encountered between SEDS and LEDS are now out of the web. Too bad, they were key material I sent readers towards when I did not feel like translating some lengthy explanation about tiled games in general. Since I'm editing some part of the blog as if it was going to be the Chapter 1: Tiled Games of a book, I found myself digging through archive.org to find the original material, print it and review it as much as possible.
The most influential of them all was certainly the MC Kids big post. Where we have Greggman discussing *really* how they made the game back on NES days. It details several clever tricks that help making a quite-sized game on limited resources, some of which make mostly sense if you're on #6502 CPU (like having a set of byte tables rather than structures), but also the key gamedev concept of a "hotspot", a single point that will be used to model the position of the character on slopes.
It is also the most official one, as the post was originally written in 1992 for the Journal of Computer Game Design while the game was from 1992 as well. And since there was an official body publishing it, I can't quite just bring in many pictures of it ... but I guess it's fair to study it, take notes and then post my own notes about what was being said.
The paper goes into significant details of how the levels are encoded (1 byte per 16x16 block, that is used to lookup the 4 tiles composing the block and its type among 100 possible types), how collision with terrain are handled (with direction-conditional testpoints and 5 collision functions per tile type). The author relates the fight to get that extra memory and how you could map the whole level into memory and thus make it easily explorable and transformable thanks to this, but how 8x8 granularity would have explosed the RAM space budget.
It is also completed with retrospective thought of the author about how they'd have inserted "beginning of hill" and "end of hill" types (helpful to save lookups in the slope management) and how they'd have made the "how do I move left[tiletype, xpos]" array providing absolute position rather than relative (+1, 0, -1) positions in a revised version of the engine.
Retrospectively, most of it did not end up in the GEDS engine. With a 66MHz CPU, if you realize that you need one extra memory lookup to get proper slope implementation, you go for that extra lookup. And if you may need more than one, you just write a loop. It's not about being lazy or not, it's about getting the most of what you have. And nowadays, you could "easily" add some "start-of-slope", "end-of-slope" meta tiles by means of auto-tiling rules.
The second note-worthy series are Tony PA tutorials about tiled games development. These were for flash games, with full-running examples at each step and detailed ActionScript code. Smartly enough, Tony starts his tutorials with top-down playfield in which the character can move freely, and then step by step introduces gravity, moving platforms, ladders and finally slopes.
I was enjoyed to start reading it as it featured a picture of Charlie the Duck (which may explain why I was researching about it in 2007 and certainly why I just posted about it, btw :P) and saying "Sure if our hero is a jumper-type of hreo, he could still [proceed forward in a stair-like, slopeless ground], but normal heroes are very happy if they can avoid jumping. It could have been a good resource, but I knew from the time I've spotted a drawing with "impossible slopes" that I couldn't derive from what was presented there.
During this 2026 retro-review, I noted that most of the slope logic seems to imply that only the display of the character is aligned with the slope. The logic entity made of testpoints and hitboxes simply moves along a stair. The two locations are only re-aligned if we jump from a slope. It also bypass the problem of solid-ground-tiles-and-slopes by disabling all horizontal checks while you're on a slope. That explains some of the "forbidden tile combinations", and implies that if you make a slope in a path that is high enough for certain characters in your game but not all, the engine will completely ignore the fact that the monster you're fleeing through that narrow passage should get hit in the face and not be able to follow you. And that has been a critical thing to address for my games even before I started working with the Nintendo DS.
So why would you put slopes in a Mario game ? so that your koopa shell keeps flowing forward and not bounce back in your face. Here's why. (Or simply to make your organic level feel organic and not just look organic).
A last one ? Hopefully, the video from Vblank Entertainment about the conversion of Retro City Rampage into ROM City Rampage is still online. It goes into details about what tiles are and how it allows a large world to run on a sub-MegaByte cartridge, what palettes are, why you need to care about not putting too many sprites per line and so on. If you ever need a primer to the "Retro Game Mechanics Explained" series and feel like sitting idle for 10 minutes, this is the best I can think of at the moment.
(The author ended up writing his own NES emulator full with debugging features and his own high-level assembly -- NESHLA hosted on sourceforge -- in the process)
Si ça ne vous impressionne pas, c'est parce que je n'ai pas encore précisé qu'il s'agit d'un shareware réalisé pour MS-DOS. Et par une seule personne s'il vous plaît: Charlie the Duck.
Il me semble bien que j'étais tombé dessus la première fois aux alentours de '97 ou '98, pendant que je cherchais des infos sur les DOS Extenders, les bibliothèques graphiques pour DJGPP du style de Allegro et ce genre de choses. Et il est fort probable que je sois d'abord tombé sur le clone de Mario World du même auteur avant de tomber sur Charlie... mais je n'ai pu trouver aucune infos corroborant cette impression. Mais j'avais été impressionné. Puis un peu déçu: Mike non plus n'avait pas encore trouvé de solution convaincante au problème de la musique de fond pendant que le jeu tourne.
Je sais que je suis retombé sur Charlie et Mike au début de ce blog, ou plus précisément sur le TFE de Mike que j'ai pris à l'époque pour une thèse de doctorat. L'équipe de recherche sur la programmation fonctionnelle du coin voyait d'un bon oeil la création d'une bibliothèque de création de jeux (de plate-forme) pour étoffer son palmarès d'applications et comme le langage s'appelait "Clean" (il est assez proche d'Haskell, au passage), on a eu droit à la Clean Game Library. Le document est sympa et utilise abondamment Charlie pour les illustrations. La bibliothèque est en théorie multi-plate-forme mais a été distribuée pour DirectX. Elle a aussi permis à Mike de faire une suite à son jeu, qui reçoit un accueil mitigé suite à des ajouts/suppressions de mécaniques de jeu.
Je n'ai jamais oublié Charlie, même si avec le temps, je l'ai confondu avec le jeu-référence d'un bouquin qui parlait du mode X (et de la bibliothèque FastGraph ?) Et en re-creusant un peu le sujet pour ce post, je tombe sur un morceau croustillant de Wikipedia:
Game-Maker seems also to have made an impression in the Benelux, with references in various academic papers,[26] coverage in the largest game magazine in the region,[27] and dissection by the local demoscene.[28]
Parce que si [26] est la présentation de Mike à la conférence IFL aux Pays-Bas en '99, si je n'ai jamais entendu parler du magazine [27], la démoscène locale, c'est bibi, et la dissection, ce sont mes posts ^_^Eh oui, les gars: vous êtes en train de lire un site web référencé sur Wikipédia!
While I was checking collisions/interactions were still working fine after introducing the G_FIGHT group, I noted something not so right about the dumblador. Something I don't think I've ever blogged although it was available since the anniversary level: throw a dumblador into pencil spikes and it will snap to the spike it lands on, turning itself into an additional safe platform.
I first tried to tune collision areas, but that did not seem to help. I checked some values in the DDD debugger, but it's a bit of a lottery: you can't really tell in advance whether you'll find yourself in an interesting case. Note to future self: there are save states in desmume! (In such a case, I should have saved the emulator state before throwing the blador, save again when the breakpoint triggers, fast-forward to see whether the condition will happen and only then go back in time to either review the step-by-step behaviour or change a little bit the initial conditions and try another throw).
And there I realised that when the blador ended up misaligned, it was colliding with a spike whose position was a mere multiple of 8 rather than a multiple of 16 ...
Back in SchoolRush times, it was mandatory to be a 16x16 pixels block if you wanted to have special behaviour such as hurting the player. But it changed with the tiled engine revision where each individual 8x8 tile can be of any 64 special type (or any of the other 192 "normal" types).
So the script for the dumblador now looks like
$THROWN :anim3 {
using gravity(24,1536)
testpoint off (8,18)
test 0 (0,0)-(8,12) ${F_BAD|G_FIGHT|F_WEAPON} //# weapon against other monsters.
test 1 (0,15)-(16,16) ${F_BAD|F_PLATFORM};
area 0 (0,0)-(16,12) ${F_ISINK} //# deleted-by-ink
area 1 (0,0)-(16,8) ${G_FIGHT|F_HURT} // # stand-on-spike
}
$THROWN->$STUNSTAND on hit1 (0 :1 0 :0 Lc $vPlatform(2));
$STUNFALL->$STUNSTAND on hit1 (0 :1 0 :0 Lc $vPlatform(2));
block 21 { is spike "0101030307070f0f" area (7,0)-(8,16) 10010010 # hurts on hit [0] (t) }
Together, they allow to get a functional blador-align-on-spike (aligning is performed by the Lc opcode), but there's still one thing to fix if I don't want to see dumblador waking up and start walking on pencils: duplicate the $STUNSTAND state into something like $SPIKED, while removing the "get feet" area. But well, a remaining glitch makes some more fun for ScreenshotSaturday ;-)
While reviewing the "tiled" chapter produced by my blogpress tools, I remembered that landing on a slope still produces odd effects from time to time. And then came an idea to reproduce these conditions in the unit-test environment.
Just as I was observing that the "dkp54" branch has been around from a long time and so has been the "cflags" branch and that "right, I promised myself I wouldn't merge things unless I've first checked they still pass automated tests."
And unfortunately, right then, the tests were not passing, they were crashing. First with an exception and then with a segmentation fault. The "offending" commit was something from 2025, a few lines that will report (rather than ignore) syntax errors within the GobState parsing.
It took some times to identify where the error was introduced, much less to fix it (hopefully) and so the 'dkp' branch (toolkit update) is now finally merged and the cflags can be just that: a branch propagating the new collision mechanism (and not a adventurous combination of features).
Alors c'était l'occasion de se demander "et si en fait on faisait un groupe pour toutes ces actions qui retirent des points de vie à un des objets ?". Petit à petit, hein, en vérifiant qu'on ne casse rien (et donc, forcément avec une vidéo Screenshot Saturday où tout d'un coup, on passe à travers les branches au lieu de rebondir et à travers les pommes sans qu'elles ne se doutent de rien...)
Un nouveau G_FIGHT donc (j'ai un peu chipoté pour trouver le nom du groupe puis le Fight Club s'est rappelé à mon bon souvenir, tel une évidence inévitable). Peu à peu, les différents scripts-personnages sont convertis en nettoyant les vieilleries comme les scripts avec des valeurs numériques plutôt que des combinaisons de symboles. Puis arrive le moment crucial de réactiver la branche-qui-rebondit, et là, je me rends compte que garder dans G_FIGHT l'action principale F_STOMP, celle que Bilou utilise jouer à Super Mario assommant un goomba, ça ne va pas marcher. ça va imposer aux zones de collision destinées à être de simples plate-formes de faire partie du Fight Club alors qu'elles n'ont même pas de "points de vie". D'autant plus problématiques qu'on a aussi des flags du type F_PLATFORM pour, par exemple, empiler des taille-crayons sans qu'ils n'infligent de dommages.
Heureusement, j'avais prévu de garder une portion des flags "neutres" (CFLAGS_LONE_FLAGS), valables qu'il y ait accord sur les groupes ou non. On pourra donc mettre la branche dans le groupe G_GROUND (qui n'existe pas encore) dont F_PLATFORM ferait partie et lui ajouter un "ah, oui, on prend F_STOMP aussi, même si ça ne fait pas vraiment partie du groupe". Certaines des zones de collisions ont dû être dédoublée (une avec G_FIGHT, l'autre sans), un petit défaut dans la réécriture quand ça arrive et on se retrouve avec des branches qui ne rebondissent plus aussi bien qu'avant ... un petit schéma, un peu de ddd et ça se remet en place. Le code pour tester deux zones de collisions ressemble donc maintenant à
cflags GobArea::test(const GobArea *o, GameObject *g, cflags mask, GobCollision* gc) const {
if (o==this) return 0;
cflags group = mask & CFLAGS_GROUP_MASK;
- if (group && (flags & CFLAGS_GROUP_MASK) != group) return 0;
+ if ((flags & CFLAGS_GROUP_MASK) != group) mask &= ~CFLAGS_IN_GROUP_FLAGS;
if ((mask & flags & CFLAGS_EXPR_MASK)==0) return 0;
// congratulations: you may compare coordinates, now.
I'm not considering to add some for these projects at this point, despite I now have a few things on codeberg and codeberg sure comes with some CI/CD option, maybe they'll look like the one of gitlab which I've had to deal with today.
Most of gitlab's CI options are tweaked through variables within the .gitlab-ci.yml file of your repository. Most of those variables are free to configure yourself but some directly affect the “Getting source from Git repository” step, especially GIT_SUBMODULE_STRATEGY, GIT_STRATEGY (where you can tell whether you want a full clone or a mere fetch of the branch you're using in your job).
And unfortunately, it's one of those case where git turns out to be complicated, with many trivial things (do you have a "main" branch here?) requiring long commands (git show-ref --quiet main ... you thought that would have been one of the 8+ modes of "git branch" command ? too bad :P) that you may have to post-process. For instance, you can pick only a few commits at the top of some branch, you need not to crawl back to that initial commit.
mkdir mere_window
cd mere_window
git init # a new place to toy with commits
git fetch ~/myFavoriteRepo --depth 10
git checkout FETCH_HEAD # so we're somewhere on the history
whereami 80
See ? 1) not all commits are there, although I asked 'whereami' (alias wh) to show me at least 20 of them, and 2) at the bottom of it, there's one tagged with (grafted). If you had branches merged lately, you might have more. Such grafts still have the same ID as the original commit, but they contain much more things if you show them: the whole content you're missing since repository started is condensed in such grafts. They'll delegate that extra weight to a deeper commit if you decide to fetch again with a higher depth, and turn back to their original size.
But back to gitlab. Its default setting seems to be to fetch with a depth of 20, performing what appears to be dubbed "a shallow fetch". You can spot that with "Fetching changes with git depth set to 20...". Mostly sufficient but if the CI/CD is introduced late in the life of the repository, and if you've been working on long branches for a while, it might not know about the main branch at all. That turned to be a problem for some packaging steps, but hopefully, we have GIT_DEPTH that can tweak things, and setting it to "0" is the way to tell gitlab to drop the --depth argument altogether. There at least, you should have some value of "main", even if it isn't the latest (just the latest known to your branch, I presume).
Gitlab may also play trick on you by keeping the things you already fetched when you start some old test again, just to find that the branch is now listed. You know it does when the job step will mention it "Reinitialized existing Git repository in your_path".
One more trap to avoid: git branch does not list *all* branches. Only those you created locally by checking something out. You'll need an extra -a to also show the remote branches (or -r to see only them).
- +
somewhere, on planet Earth, there's a weird guy named Sylvain (aka. PypeBros) who loves to write programs and draw comics with a blue ball named "bilou". That's me.
If you have a blog that talks about similar stuff, just leave me a comment.
3 packages available for download, deprecated CVS and mercurial
Vote for your favourite post