Sunday, February 23, 2025

le nouvel arbre

Avec les tests effectués pour les-racines-auxquelles-on-s'accroche, j'en ai profité pour faire une petite capture d'écran de l'arbre tel que je suis enfin en mesure de le faire apparaître dans le jeu ... Je pense que vous ne l'aviez pas encore vu. Pas parfait, mais honnête, je dirais. (et oui, j'ai vu: il reste des caractères foireux tout autour... C'est une map de récup, si vous vous souvenez ;)

edit: ces caractères (étoiles) sont invisibles dans l'éditeur de niveaux: il s'agit d'une portion de la mémoire utilisée pour les animations qui se retrouve visible parce que la map fait toujours référence à des numéro de tiles qui ne sont plus dans mes pages.

There are tests ongoing on my devstation with Bilou hanging to a root in the greenzone. They've been behaving rather weirdly lately, but they're taking place in that recovered-vertical-level once drew to test load-level-two feature.

And that means at some point, I was bored of seeing non-sense flashy tiles at the start of every attempt, especially since I've drawn some more leaves tiles last year. But you had never seen them, because I had never used them. Well, now it's done. they're not perfect, but here they are.

Saturday, February 22, 2025

Crappy Debbie WiFi

Bad luck, I've got unreliable WiFi with the new distro: every now and then a web page will get stuck while loading. When they're not, they're taking age to complete. If I ping, I don't see "network unreachable", but I see the pings struggling, the resovled name changing, sometimes even switching from IPv6 to IPv4. So I went for a monitoring of dmesg -w and I spot events like

[13390.293505] wlp2s0: disconnect from AP e4:bf:xx:xx:xx:50 for new auth to e4:bf:xx:xx:xx:48
[13390.332410] wlp2s0: authenticate with e4:bf:xx:xx:xx:48
[13390.332455] wlp2s0: 80 MHz not supported, disabling VHT
[13390.379300] wlp2s0: send auth to e4:bf:xx:xx:xx:48 (try 1/3)
[13390.382294] wlp2s0: authenticated
[13390.385211] wlp2s0: associate with e4:bf:xx:xx:xx:48 (try 1/3)
[13390.396102] wlp2s0: RX ReassocResp from e4:bf:xx:xx:xx:48 (capab=0x1411 status=0 aid=3)
[13390.400601] wlp2s0: associated
[13390.414136] wlp2s0: Limiting TX power to 20 (20 - 0) dBm as advertised by e4:bf:xx:xx:xx:48
[13411.113702] wlp2s0: disconnect from AP e4:bf:xx:xx:xx:48 for new auth to e4:bf:xx:xx:xx:50
Every 20-30 seconds. They match the struggles of ping.

Now, there are posts about how to handle frequent disconnections, and I wish they weren't so often behind cookie walls, so I could scan through them more easily. The link mentioned would offer little to no help. "Have you tried switching to networkd+resolved instead of NetworkManager ?" ... eh ... I'd rather leave that untouched if I can. See, it's not a whole new system: a decade-old ubuntu was able to use that same WiFi chip reliably.

if I watch iwconfig, I can see Bit Rate ramping up after a disconnect, then reach a certain point (around 100Mb/s) and then we disconnect and are back to a few Mb/s again. Yet, sudo iw dev wlp2s0 set bitrates legacy-2.4 48 36 24 18 12 9 6 does not seem to help ... Of course: ramping up bit rate is not the cause of the issue, it's a consequence of network being disconnected: it has to slowly re-establish connection every 30 seconds.

I'd like to say that I've found a blog post that proposed me to check nm-connection-editor and change "band auto" into "band B/G (2.4GHz). I'd like to say I've got a colleague explaining that pointed out it would have no effect until I manually systemctl restart NetworkManager.service, no matter whether I clicked "save" button on that settings window. Truth is this has been suggested (among many other useless things) by the rubber duck, again.

Now that it's fixed and that I read those dmesg lines again, I spot how there were *2* MAC addresses competing, and my computer would hop from one to another. Likely I could have saved myself trouble by disabling either band on the access point settings, but that may have affected phones of my relatives.

Monday, February 17, 2025

pixels, at last.

Une petite heure de week-end où j'ai pris le temps de me faire des petits pixels ... enfin. Après une autre petite heure plus tôt dans le week-end pour faire quelques essais de croquis.

L'écrabouilleur, d'abord, qui est la résultante de mes esquisses basées sur Ristar, des techniques proposées par Helm que j'avais utilisées pour les livres de l'école et de la réalisation que  finalement, des gants façon Mickey donneraient sans doute mieux dans l'univers de Bilou que ma propre main.

Il se trouve que j'avais déjà tenté de dessiner ma main, et j'avais la S-Team en entier et le verdict est sans appel: le nouveu design, plus anguleux, s'intègre mieux.

Finally, I managed to find 2 hours to work on the missing pixels I need for Bilou's demo. First the smasher punch, using all the observations I made while posting about my Ristar pixel study. It's more squarish (and the S-Team girls like it), it has cartoony-4-fingers look and is modeled after a cartoony glove rather than my own hand. Quite close to the sketch I made the day before. I'm still undecided about the thumb position ...

Second, the top-of-waterjet sprite. I won't try to make a tutorial of how-to-animate it: there is very likely room for improvement, but it does a fair enough job (imho) and nicely fits the style of the jet (see below for the in-game montage ;). I'll still have to make it wave up and down and make it so that the jet pushes Bilou upstream on contact.

Deuxième morceau: le haut du geyser inspiré de GoodboyGalaxy. Il faut dire que les derniers tests se déroulaient sur une map où j'ai ajouté l'animation pour la partie verticale du jet ... et bon, voir le jet se terminer par une ligne nette comme ça, ... ça picotte aux yeux.

Je ne suis pas franchement au niveau de hot_pengu, mais je crois que ça devrait faire l'affaire malgré tout (NB, c'est plus fluide en vrai sur la DS).

Saturday, February 15, 2025

The Tomboy Quest

  • Tomboy.exe is truly a PE32 executable holding .Net assembly ... my bare kernel doesn't want to run that
  • what with mono-runtime ? it starts, but is missing Mono.Posix ...
  • it is in my /ubuntu/usr/lib/mono/4.5, as a dll, but there are also some .../lib/mono/gac/Mono.Posix and a /usr/lib/libMonoPosixHelper.so ... so I'd better install libmono-posix4.0-cil from debian repos ...
  • okay, but now it complains about a missing gtk-shark ... I see references for that in /ubuntu/usr/share/cli-common/packages.d ... let's try and make some symlink ...
  • still not ... time to install strace and see what it fails to find... mhmm ... seems to be the Facades/gtk-sharp.dll and friends. But ubuntu did not have any Facades either ... so I guess that must be the files in .../lib/mono/gac/*-sharp instead. (strace did look for them, at least). Without gac contents, none of packages.d or policies.d is taken into account ...
  • trying again ... more sophisticated exception this time, about libglibsharpglue-2.so not found, if I'm not mistaken. It insist on it to be in /usr/lib/cli (fair enough), which only contains binfmt-detector-cli so far (part of mono-runtime)
  • more progress again, now missing libappindicator.so.1 ? would debian pacakge libayatana-appindicator1 do the trick ?
  • libgconf-2.so.4 you say ? okay, there's a .deb too ... now it says "Initializing Mono.Addins" ... it say "no GUI 'su' tool found" ... nothing ... What if I have mate-session running ? Ah! There you are ! Okay, your icon in the tray is a broken file ... your icon in the enlightenment dock is a question mark, but you ... are ... there. (I guess using --new-note or --search on the command line would have done the trick as well).

Time for some context, I guess ? Well, you know I've been installing a debian lately. It turns out it did not have the tomboy tool available in the repository... This is no surprise to me: the latest ubuntu I installed at work did not have it either, but my colleagues had started to deploy phabricator and it's been a good amount of years that I've switched all my dev-musing into that (mostly because it has instant upload of pictures despite a more sluggish overall interface ... and I can easily share contents with colleagues).

I'm done with PhD research and all, so my old collection of notes about a better Internet aren't very useful either ... but I started using tomboy a few years before it turned obsolete to hold some of my fairy's collection and automate the production of monthly curated list of that collection. So the last weeks have been a reboot-dance between the new debbie and the old ubuntu depending on whether I needed USB support or she needed her collection. That must come to an end because firefox certificates are about to expire in that old ubuntu, with no more packages to replace it.

The process above will sure turn into a maintenance nightmare sooner or later, but guess what, it's not the first time I resort on such process. Last time was to keep using an old Adobe Acrobat for Linux because the new one was a usability nightmare ... and it did a fair job for years and years, even hopping from SuSE to Ubuntu. Sure, I tried alternatives, like Folio, or rebuilding from sources, or the tomboy-ng package readily available for my debian (but that turned out to have several critical bugs and lacked key features for my curation technique, despite having a very welcome convert-old-notes tool) ... I hadn't tried NobleNote, thought ... maybe I should have ...

Thursday, February 13, 2025

Hang on!

It's one of the key mechanics I'd like to bring into my new game: being able to catch hanging things and hanging as well. It was a fun move in Commander Keen, it was amazingly expanded in Fury of the Furries and Mickey Magical quest ... And last week-end, I went on to try and get it prototyped.

I started with a summary of how Bilou can hang below spongebops in School Rush ... something we don't see a lot in the blog, mostly because Bilou is supposed to *ride* the sponges, not hang under them. Hanging was added as an "else" branch of another "else" branch:

when you hit the "HANDS" button mid-air, Bilou does a roll move trying to grab what's nearby. that is AIRGRAB state. The original idea was to test what was *below* him and either pick-up a dumblador or ride a spongebop... but the move shows the hand grabbing in front and rear directions as well ... so it would feel natural that Bilou could grab a sponge even if he's on the same horizontal line, like in the sketch on the left. Yet, snapping Bilou on top of the sponge from this location felt glitchy.

Bon, j'ai un p'tit Bilou suspendu sur une page de mon cahier-agenda depuis le début 2024 ... j'en ai un autre sur la bannière du blog ... je crois que l'appel du pied est assez clair: il serait temps de prototyper un peu ça, d'autant que cette fois ci, ce ne sont pas les coins de niveau où s'accrocher qui manquent dans le livre-secret-du-level-design.

Et pour "commencer simple", l'idée était de faire subir à Bilou le comportement des éponges. tout en réutilisant un des états codés pour l'interaction avec les éponges: rester suspendu (la feinte). Chose qui m'a tout de même demandé de me replonger dans pas mal de gobscript, parce qu'à la base, il est prévu que Bilou s'accroche *par-dessus* les éponges, et pas qu'il pende en-dessous. Le côté "pendu" n'a été rajouté que dans les derniers 20% du projet, entre deux séances de playtesting parce "bin, oui, c'est vrai au fait: pourquoi Bilou ne pourrait-il pas rester suspendu s'il était trop bas pour escalader l'éponge au moment ou la joueuse a appuyé sur (B) ?"

So instead, Bilou will enter AIRHOP move, getting an automatic double jump and automatically tracking the sponge's position. That feels fairly naturally when playing, that gives you a sort of "fair second chance" but it might fail anyway: you may fall below sponge's position again without having reached the "riding spot", with no hope of catching up. and *that* is the time when we finally switch to HANGING. 

There will be other objects to hang to in the game, especially bookmarks, vines, and the like. Some of them could be entities like spongebop (maybe moving a bit less), but sometimes it might also be nice to have tiles you can hook to. I have code to make some tiles react to collisions with the player, but that was not enough: the hitboxes used to detect spongebop explicitly search for baddies. And because I'm testing 3 areas over the course of the animation, I'm out of options to also test for friendly areas (which has been the case for all pick-ups so far ^^"). But hitting a tile can trigger an animation, and it can spawn an entity with proper hitboxes so that Bilou could hook to *that*. You couldn't really hook to a tile, anyway, because the BlockArea created during the collision test is immediately recycled, so you could not attach to it

Mon idée était ensuite d'utiliser un type de bloc spécial pour servir de point d'accroche, et d'aller "poker" quelques blocs de ce genre à des endroits bien sentis de la map "green" de la démo. ça non plus, ça n'a pas fonctionné comme j'espérais. Entre autres parce que quand Bilou cherche à s'accrocher à quelque-chose pendant sa pirouette-en-l'air, il cherche parmi la liste "EVIL" ... et les blocs interactifs, eux se présente automatiquement comme des "HERO".

Bon, ce n'est pas bien grave: puisque je voulais que Bilou s'attache au point d'ancrage, il fallait de toutes façons que j'introduise un GOB (game object) généré à partir du bloc spécial, un peu comme les scintillements qui suivent Bilou quand on ramasse un smiley bleu. Ce gob pourra être dans la liste que l'on veut. Pour éviter qu'on ne génère des quantités ridicules de gob-points-d'ancrage, on va (enfin) utiliser une animation de la map elle-même pour désactiver puis réactiver les propriétés du bloc pendant que le gob est présent. Exactement le comportement des blocs-question de SuperMario quand on les coup-de-boulise.

So the plan was the following: a new special block that would react to GRAB action. When that happens, it trigger the animation that actually leaves graphics untouched (with "spr0 ffff") but turns the physical tile into "plain fall-through" for 5 frames, and then restore the tile as "block 07" (thus interactive) again. Quite the kind of thing that SuperMario question blocks do on a daily basis, actually.

(It turned out meanwhile that using sprite 'ffff' did not work as intended, so I ended up adding a bbox statement to that animation -- effectively making it a special 8x8 tile rather than a 16x16 special block -- and fixed the code that plays mapanim so that "props" instruction is executed immediately rather than cached until the next "spr0" instruction)

anim9 spr:2 {
   spr0 7      # visuals for the "tile replacement",
   delay 5     # here just a Bilou hand ...
   done
}

state63 :anim9 {           # behaviour for that hand :
   using freemove          # just stay there, 
   area 0 (0,0)-(8,8) 1010 # accept GRAB hits.
}

state62 :anim9 {   # should have been the persistent state when Bilou hooked...
   using freemove
}

state63->state62 on found 0 [wc $1010 ?] (t) # detecting the actual hook-up hit
state63->nil on done                         # and disappear otherwise

using shgob(state63 is e:=1:6) as 6          # a special action to spawn the hooked hand
                                             # oh ... and it's an evil hooked hand.
block 06 {
    is gndhook "ff3c7cfebe2a2a00"  # the special tile 
    area (0,0)-(7,7) 1010          # will also detect GRAB hits
    on hit [t] (x6) :anim6         # and the 'x6' will invoke shgob registered 'as 6'
    props fc0
 }

That should have done it. I could see the hand showing up, and getting away, but I couldn't ever hook to it. I couldn't get an evidence of why it failed, but I believe it is rooted to the fact that bilou's own bbox must overlap the tile in order to trigger the "on hit" transition. but since all the hitboxes with the GRAB flag tend to be off-center, the second collision (with state63 entity) doesn't occur because there's no overlap.

Alors oui, je vous balance le script directement dans le browser. Parce que ça ne fonctionne pas. Enfin, après avoir corrigé la gestion de l'animation pour ne pas dépendre des changements d'affichage (qui expliquent le bout de terre manquant dans le screenshot là-haut), ajouté une "bbox" à l'animation (pour que le code sache qu'il ne doit manipuler que 8x8 et pas 16x16), je finis par avoir un objet qui est créé tandis que le bloc devient inactif puis se réactive ... le hic, c'est que il faut pour ça que le "corps" de Bilou soit en contact avec le bloc interactif alors que ce sont ses *mains* qui vont essayer de l'attraper. Et la zone à attraper est réduite à 8x8, de toutes façons mal positionnée... bref, je n'y arrive que 1 fois sur 5-6, donc le joueur n'y arrivera pas.

Il vaut bien mieux que je me décide à dessiner un graphisme dédié (une racine ?) et que je fasse juste un GOB dédié... il y aura des import/exports mercurial à faire ... 

At some point I thought "hmm. I'll just have the little tile be a 8x8 hitbox in the middle of a 24x24 special box, that will do the trick", but it wouldn't work either: that 24x24 region around the corner of a pillar (for instance) would have "jump-through ground" on one tile, and "air" everywhere else... how could a single "props" instruction fix that ? okay, I could introduce "props(-1,0) fc4" to change one specific tile of the block but that sounds like the coding equivalent of "just stab me now" ... 

So, likely, I should forget about that "hook to tile" thing, accept that there's very little hookspots in the Dreamland levels anyway and kickstart my NDS to draw some root sprite in green.spr ... 

MessageBox(NULL, ..., MB_OK| MB_ICONERROR)

L'an dernier, j'étais superviseur d'un stagiaire... Après avoir passé des années à essayer de donner de bonnes consignes aux étudiants, cette fois, il était à côté de mon bureau pendant qu'il codait ... un petit panneau de configuration à ajouter dans une procédure d'installation. Le premier jet de ce panneau s'est fait en Win32, pour essayer de mieux l'intégrer avec un "bon vieux programme" utilisé dans la même procédure d'installation...

On ne va pas se mentir, Win32 et ses callback, ce n'est pas franchement la partie qui m'avait tenté le plus dans la Bible du PC, mais en même temps, le fait que chaque "widget" soit adressable séparément et qu'on puisse par un petit script python retrouver sa fenêtre, cocher la case qui dit "jumbo" et cliquer sur "OK", ça a un côté séduisant ... Là où c'est beaucoup moins séduisant, c'est quand on voit qu'il va falloir appeler CreateFont() à gauche et à droite, passer des coordonnées et des tailles à tout bout de champ, appeler SendMessage() aux objets qu'on vient de construire pour appliquer le changement de police ... Puis ça devient vraiment pénible avec WS_TABSTOP qu'il va falloir ajouter partout pour pouvoir naviguer entre les contrôles de la fenêtre tout au clavier.

Puis est venu le coup de grâce: si on veut éviter que le titre ne déborde de sa barre, si on veut que les contrôles tiennent dans la fenêtre, on doit surveiller les tailles des différents objets créés ... GetTextExtentPoint32(hdc, text.c_str(), text.length(), &size);, ce n'est déjà pas très sexy, mais il faudra l'emballer avec 4 lignes de code supplémentaires rien que pour connaître la longueur d'une chaine en pixels ... oh, pas que ç'ait été plus simple avec freetype, celà dit. Mais quand on pense qu'on y est, on essaie d'ajouter un SetWindowsPos(..., SWP_NOOWNERZORDER|SWP_NOZORDER) pour pouvoir faire défiler la fenêtre dans le cas où il y aurait plus de cases à cocher que prévu ... et on voit qu'il va falloir se renseigner à la main avec GetScrollInfo(), gérer à la main les SB_LINEUP, SB_LINEDOWN et même SB_THUMBTRACK (pour le cas où l'utilisateur aurait déplacé l'ascenseur directement ^^"), s'envoyer soi-même les up/down en cas de WM_MOUSEWHEEL... déplacer chacun des objets contenus dans la fenêtre à coup de h2 = GetDlgItem(h,i); GetWindowRect(h2); MoveWindow(h2) sans oublier de convertir entre coordonnée-client et coordonnée-écran ... et tout ça pour quelque-chose qui clignotte affreusement. Autant dire que quand le frère de Jigé a proposé "de faire ça plutôt en C#", la bataille n'a pas été bien longue pour défendre le proto actuel ... on était plus proche du Turbo Pascal que de l'HTML, en fait

(tout de même, c'est perturbant de re-croiser du code qui fait un CreateWindow(..., BS_PUSHBUTTON, ...) plutôt que d'avoir CreateButton ...)

Wednesday, February 12, 2025

$VSWHERE

Okay, that's truly worth another "rongtudju" entry. I have to build with Visual Studio from times to times at the office, but I also work remotely from times to times. Of course, it's been ages since I installed sshd from mingw packages, and I'd rather call the build system from a ssh console when I'm remote than having GPUs trying to squeeze console activity into H.264 and show it on my screen. And it has been working happily for a good amount of years.

Then something bad happened, and as soon as the build system will try to invoke any of visual studio core programs, I would get error messages about

'cl' is not recognized as an internal or external command, operable program or batch file.

One key element of our build system is SCons, which I'm not fan of, but at least I can enter that and hack around now. Especially, I can see that no matter whether I set the $PATH environrment variable on the command line to include c:\program files\microsoft visual studio\...\bin\Hostx64\x64, the env['ENV']['PATH'] that scons will use to invoke the compiler will be empty.

If I decide to hack the 'CC' variable directly in Tools/msvc.py, I can make it compile stuff, eventually. But I had to dir /s stddef.h and others to get all those include path right. And it will stab me in the back as soon as I'll try to build a driver instead. Not to mention that of course, it doesn't help for other tools like lib.exe or link.exe ... 

A bit more rubber-duck-talking led me to VSINSTALLDIR hunting (and VS_VERSION hunting) in more python files, trying to find what is the normal way for SCons to decide which visual studio to use.

I know about the vcvarsall.bat script that "native developer console", but I doubt it would be used in a mingw-bash-scons-whatever-cl.exe setup, or at least not directly. And then, only then, I noticed the warning that the build tools had been trying to show me from the very beginning:

scons: warning: MSVC version '14.3' was not found.
  Visual Studio C/C++ compilers may not be set correctly.
  Installed versions are: ['14.0']

That was coming from Tool/MSCommon/vc.py, in a file that is mentioning $VSWHERE every now and then. Some more rubber-ducking and more dir /s revealed c:\program files x86\Microsoft Visual Studio\Installer\vswhere.exe ... and if I somehow force it into env['VSWHERE'], I no longer need to hack env['CC'] and env['AR'] to get a working build. Higgs! I even get the whole sub-project built just fine ^_^

Of course, the VPN dropped all my connections again a few minutes afterwards ... just enough to see whether I can get that running two times in a row, I guess...

Thursday, February 06, 2025

smasher pixel study

Fin janvier, je suis tombé sur un élément intéressant dans une vidéo de Ristar que je n'avais encore jamais rencontré: un gros poing sculpté dans un bloc. Intéressant parce que je n'ai pas encore de rendu convainquant pour le gros-bloc-écrabouilleur pour ma pyramide. 

J'ai commencé par le redessiner plus ou moins tel quel avant d'en déduire une version tournée vers le bas (et donc avec un autre genre d'éclairage.

You know, I'm still trying to get something convincing as big smasher for my pyramid level. And after a good deal of not-so-convincing too-realistic designs, I stumbled upon an interesting reference while watching a playthrough of Ristar. A big, closed fist, that looks cut out of a concrete block... Interesting geometry to say the least.

So after first trying to reproduce the design, I tried doing it flipped-down, with adjusted lightning to match it ... I also tried make a sort of perspective shift, observing that the lateral view is also iconic of a closed fist ... None of that has been converted to pixels yet. 

After those, (way after. This is almost necro-blogging) I eventually went into that Super Mario Wonders level with big Bowsers fists all over the place... clearly Mario Wii / WiiU fists had been an inspiration for the original design, and clearly too, the weird look of cast-hot iron won't help me giving my own art a fit-a-pyramid look ... But it shows me right now that 5-fingers fist will never look fit in Bilou's world, where things have at most 4 fingers -- Mickey-style -- when they have fingers.



Bref, c'est joli, mais même avec une permutation isométrique reprojetée, il reste un truc qui cloche ... et peut-être que malgré leurs couleurs inexploitables, les poings de Bowser viennent de me donner la réponse: dans l'univers de Bilou, un poing à 5 doigts, c'est un doigt de trop.

On va donc reprendre le cours de Helm (maintenant qu'il est en ligne ^^), une série de gants de Mickey Mouse et essayer de se construire un gros poing bien lourd et bien bilouteux pour faire du jus d'intrus dans cette fameuse pyramide ...

Et non, ce n'est absolument pas un point prioritaire sur aucun des non-plannings ... donc ... on le fait en moins de 15 jours ^^"

Tuesday, February 04, 2025

back then ... geometry first.

Dumblador revisit post from October 2011 featured not-so-great book covers and "colour balance" post 20 days later featured them almost identical. Then 10 more days and they suddenly look like in School Rush. What happened in between ? pixel art Comment and Critique. "I think you're focusing way too much on using techniques right rather than the objects itself" said Elk, but I couldn't figure out what that meant. "The biggest problem with your art is bad texturing, at this point, I'll return with specific edit and critique." So Helm Returns is what happened. 

En triant un peu, je suis retombé sur un post du forum pixelation qui répond à une question que personne ne se posait. C'est qu'entre le relookage de Dumblador (Oct. 2011) et la recherche des couleurs idéales pour la School Zone (Nov. 2011), on est passé d'un livre pas très convaincant au design actuel utilisé dans School Rush (et qui restera certainement inchangé pour Dreamland). Dans ce post, Helm me donnait une série de conseils en retouchant lui-même le livre que j'avais dessiné.

1. is your book.
2. is the form broken down to its block shape.
3. is geometry, lit from above more or less. If a thing doesn't look good and identifiable on this stage, it won't look much better if you overrender it.
4. here I apply more detailed geometry, I still don't need more colors or fancy tricks, I don't need to fake texture, it's just stuff that the book can support. I also looked at reference here which you should always do, no matter how cartoony what you're trying to draw is. You can spot many differences from 3 to 4 that are related to the reference.
5.After the shapes are good, identifiable and the object has volume, you can go nuts with your new school colors and tints and whatever else, it's all embellishment from here and on.

Le jeu, dans ce cas-là, c'est d'essayer de réappliquer soi-même les conseils qu'on a reçu. A savoir ici "commence par la forme brute, puis fais en sorte que la géométrie soit compréhensible". Ne pas aller au-delà de l'étape 3 si quelque-chose va de travers. Ensuite, rafiner la géométrie mais ne pas texturer, ne pas partir dans des grands effets de couleur. Une excellente leçon, et je vais en avoir bien besoin pour m'attaquer au gros poing pour la pyramide ...

So I went on and try to apply the master's suggestions to get closer to what I wanted:

My attempt at having the right geometry with flat shading and minimal details, my step of putting more detailed geometry and shading before adding any texture, and the final take. The page lines have become too horizontal and dull, retrospectively, but the binding has been used almost as-is in the game.

It was a pleasure to read the master's comment:

Much, much better. Wouldn't surprise me to see this piece in any professional good looking mega drive game of the era.

Approach all real-life related items you render in a similar way, avoid 'noisy textures' for their own sakes and you will level up in your craft."

A lesson to remember as I'll have to work on more pixels for the upcoming game...