GamEditorDS

La video "Did you know gaming" au  sujet de Bubsy, est surprenante, et d'une certaine manière digne des meilleurs articles de Pix'n'Love. Le premier Bubsy - le seul réussi de la série - est l'oeuvre d'un employé d'Accolade qui voulait faire un jeu ... [More] à la Sonic dans une société où ce qu'on attendait de lui, c'étaient des jeux d'aventure (eh oui, on ne faisait apparemment pas que des jeux de course chez Accolade). Mais son analyse de "ce qui fait de Sonic un bon jeu " est d'une telle qualité que la direction s'incline et donne son feu vert .En résulte le très bon jeu que nous connaissons bien, sorti en '93. Drôle, captivant et plein de charme sans pour autant être parfait ni nécessairement un exemple en matière de gameplay.Mais vu le budget de la production et de la promotion du jeu, ils décident d'en rester là, et l'employé de quitter la compagnie. Sans la license de son succès. Quand l'heure viendra malgré tout de faire un Bubsy2, ce sera avec la consigne de limiter les frais mais surtout en contraignant de s'y atteler une équipe qui préfére les simulations sportives habituelles de la société et déteste devoir travailler sur Bubsy... [Less]

Je manque de temps pour re-blogger ici toutes les trouvailles de Sylvain "Tohad" en matière de graphisme -- d'ordinaire touchant plutôt aux décors de dessins animés (avec un penchant pour les ghibli, en ce qui me concerne) ou au concept art de futurs ... [More] jeux vidéo.Mais là, vu le temps considérable que j'ai passé moi-même à chercher des références pour dessiner les arbres, je peux difficilement passer à côté de ce tutoriel épattant de Mocha.'faudra que j'étudie ça d'un peu plus près.To Mocha (him/her)self: I hope you won't mind if I host a copy of your wonderful tutorial here until I'm done studying it and applying it to improve my own trees in my "green zone" game level. [Less]

A force de faire des brocantes, mon frère a fini par mettre la main sur une PSP et une petite collection de disques de jeux, parmi lesquels Loco Roco, le jeu que j'avais envie d'essayer depuis près de 10 ans. Un concept de jeu assez sympa, mais avec ... [More] un mode de contrôle que je trouve lassant au bout. de quelques niveaux. Le principe de base me fait penser à Soul Bubble : suivre un parcours, trouver des petites cachettes et faire gaffe à ses points de vie.Là où Soul Bubble semblait se battre contre le hardware de la NDS, Loco Roco offre un graphisme tout en finesse et fluide à souhait. Les structures mobiles sont particulièrement réussies, mais malheureusement trop souvent utilisées comme des mini-cinématiques.Même impression pour le mécanisme "fracturer Loco Roco en plein de petites boules": il est presque toujours équivalent à un "démarrer la cinématique"... Et là où Soul Bubble offrait une mini-map du niveau et un indice sonore à proximité des zones secrètes, on navigue beaucoup plus en aveugle sur ce titre. Et trop souvent sans possibilité de faire marche arrière.Bon, venous-en an coeur du problème: on ne contrôle pas son personnage. On peut seulement incliner le niveau dans un sens ou l'autre. Et pour sauter, maintenir les deux gâchettes pour "charger" le saut puis relâcher. Le résultat est imprécis, il y aura beaucoup d'erreurs. Il faudra réessayer encore et encore. C'est le genre de chose qui devrait pouvoir se travailler, mais j'avoue ne pas avoir l'impression de m'en sortir mieux après une dizaine de niveaux. Je crois que je vais en rester là. [Less]

A force de faire des brocantes, mon frère a fini par mettre la main sur une PSP et une petite collection de disques de jeux, parmi lesquels Loco Roco, le jeu que j'avais envie d'essayer depuis près de 10 ans. Un concept de jeu assez sympa, mais avec ... [More] un mode de contrôle que je trouve lassant au bout. de quelques niveaux. Le principe de base me fait penser à Soul Bubble : suivre un parcours, trouver des petites cachettes et faire gaffe à ses points de vie.Là où Soul Bubble semblait se battre contre le hardware de la NDS, Loco Roco offre un graphisme tout en finesse et fluide à souhait. Les structures mobiles sont particulièrement réussies, mais malheureusement trop souvent utilisées comme des mini-cinématiques.Même impression pour le mécanisme "fracturer Loco Roco en plein de petites boules": il est presque toujours équivalent à un "démarrer la cinématique"... Et là où Soul Bubble offrait une mini-map du niveau et un indice sonore à proximité des zones secrètes, on navigue beaucoup plus en aveugle sur ce titre. Et trop souvent sans possibilité de faire marche arrière.Bon, venous-en an coeur du problème: on ne contrôle pas son personnage. On peut seulement incliner le niveau dans un sens ou l'autre. Et pour sauter, maintenir les deux gâchettes pour "charger" le saut puis relâcher. Le résultat est imprécis, il y aura beaucoup d'erreurs. Il faudra réessayer encore et encore. C'est le genre de chose qui devrait pouvoir se travailler, mais j'avoue ne pas avoir l'impression de m'en sortir mieux après une dizaine de niveaux. Je crois que je vais en rester là. [Less]

Bon, je dois avoir quelque-chose de foireux dans la configuration de mon système de build avec le dernier devkitarm que j'ai installé: la plupart des outils prennent soudain une taille de 4MiB... avec plein de vide au milieu du fichier ...Première ... [More] question, est-ce que ce problème est déjà présent dans le fichier .elf, ou est-ce quelque-chose que j'ai introduit au moment des conversion vers le format .nds ?J'utilise pour ça l'outil objdump, et il y a déjà quelque-chose de louche: vous voyez ces vaddr et paddr ? l'une est une adresse virtuelle, que les données doivent avoir pour que le programme tourne bien. l'autre... bin c'est la première fois que je vois des valeurs différentes pour ces "adresses physiques" Et en particulier, une de ces commandes de chargement va utiliser une adresse "physique" 4MiB plus loin que le début de la RAM de la NDS.Si je croise ces information avec la liste des sections, disponible un peu plus bas, j'ai une correspondance (grâce aux offsets à l'intérieur du fichier ELF) avec une section baptisée ".twl" -- là aussi, c'est une première pour moi. C'est en tout cas bien les bytes qui correspondent à ce qu'on trouve au bout du gouffre du fichier .nds, aux alentours de 4MiB.Renseignements pris, cette section contient des instructions spécifiques au démarrage pour DSi (et son TW Loader). Une petite mise à jour de mes makefiles pour éviter le passage par un fichier .arm9 (version pré-applatie du contenu du fichier .elf) et c'est réglé: l'outil ndstool qui construit les .nds est maintenant suffisamment évolué pour manipuler lui-même les .elf, comme dit WinterMute.Et au passage, une simple utilisation de stringstream pour des manipulations de chaînes me coutait 250K dans runMe (qui autrement ne prend "que" 500K).Voilà qui cloture (enfin) la branche "latest-devkitpro" [Less]

Bon, j'ai une grosse révision de mon moteur de jeu en cours. Jusqu'ici, les propriétés du niveau étaient conservées dans les bits "palette" du niveau, soit 4 bits par mini-bloc de 8x8 pixels (les tiles, pour les intimes. Prononcez avec de l'aï ... [More] comme dans light). Pour "School Rush" et ses niveaux de 16 écrans de large pour 1 écran de haut, on parle de 8KiB de données. Un niveau de Commander Keen (mettons la machine infernale des Shikadis) avec ses 1200x1200 pixels nécessite 22500 de ces tiles.Pourquoi tous ces chiffres ? parce qu'au coeur de la révision, il y a le besoin de faire sortir ça des bits de palette pour pouvoir utiliser librement les changements de couleurs si utiles dans School Rush tout en permettant de nouvelles mécaniques de jeu. Jusqu'ici, j'ai pu m'en sortir avec des blocs spéciaux (bonus, pics) qui utilisaient les "codes couleurs" des 4 tiles qu'ils couvraient pour encoder un numéro suffisamment large. Mais quand on commence à réfléchir à faire de l'eau, des ventilateurs ou des tapis roulant, ce système devient bancal.En particulier, il était basé sur le fait qu'un groupe de 4 tiles sont liées par les numéros de tile (en mémoire vidéo) utilisé parce que l'éditeur de sprites fonctionne comme ça. Impossible donc de définir un bloc-bumper sur un graphisme qui serait fait d'une moitié de gomme et d'une moitié de lettre. ça, c'est plutôt un avantage. Impossible aussi de rendre une pointe de crayon blessante si elle est sur 'l'arrière-plan'.Faut-il donc que je continue avec ce système (données 4-bit) sachant que je travaillerai maintenant sur un tableau séparé ? Puis-je me permettre une extension à 8-bit par tile ? et si oui, comment organiser au mieux les données ? Est-ce que ça m'impose d'intégrer de la compression ?A mon avis, avec 22Ko pour une map type "Commander Keen" et sur une bécane qui dispose de 4Mo de mémoire principale, ça reste parfaitement jouable. Oui, c'est loin des techniques de trapéziste de l'époque des consoles 16-bit, mais c'est justement une des raison de choisir la DS à mes yeux: elle permet de se concentrer sur le jeu lui-même, avec des contraintes, certes, mais des contraintes simples à apprivoiser. [Less]

Okay, I'm using PERL when I can, because it makes the job. I like how it is not distracting my train of thoughts when tackling a problem and how it makes scripts that are easy to hack later on. I love how it integrated regular expressions, but so ... [More] far, I wasn't fond of how I had to test input patterns one after another with stripped down versions of the regular expression to find why it was failing.And today I discover use re 'debug'.With a simple line, I can get an overview of what the regular expression evaluator is trying to do when parsing a string (coloring added manually).In yellow, we can track the position within the string: how much has been accepted so far. In green, a quick overview of what was just behind that position and what is just ahead. The blue code seems to identify the next operation that the regexp will do -- its program counter, sort of, and in white the detail of what is tried/done. [Less]

Pretty impressive new feature of gcc/g++ available in the latest devkitarm.Look at that. MapWindow.cxx:377:23: warning: %i directive output may be truncated writing  between 1 and 2 bytes into a region of size between 0 and 9 ... [More] [-Wformat-truncation]snprintf(msg, 32, "@%i,%i : %s [%ix%i]",xpos, ypos, why,                   ^~~~~~~~~~~~~~~~~~~~~MapWindow.cxx:689:12: report("editing meta-layer");                       ~~~~~~~~~~~~~~~~~~~~MapWindow.cxx:377:23: note: directive argument in the range [8, 16] MapWindow.cxx:377:23: note: directive argument in the range [8, 16] note: 'snprintf' output between 32 and 42 bytes into a destination of size 32- gcc detected that I'm calling that snprintf function with a value of 'why' that is actually the "editing meta-layer" string, which is 18 bytes long- it understood that this and some numbers had to fit within 32-bytes output- the format characters only take 9 bytes- xpos and ypos are 16-bit values, needing at most 5 characters to be rendered on-screen- 18 + 9 + 4 = 31. that's the case where all the numbers take only 1 byte. We have barely enough room to display the message (and its terminating zero character)- 18 + 9 + 5 + 5 + 2 + 2 = 41. That's the case where we have all numbers using their maximum size. Note that GCC/G++ could guess that we'll only use numbers between 8 and 16 by looking at  blockop?16:8 argument!Having such thing can be super precious when you know what's going on and want to harden your software. Hopefully, there is no overflow expected here. Only truncation. And since the purpose is to put a message on a 32-bytes wide line, I'm fine with truncation here. I'll have to tell that to the compiler the best possible way. [Less]

Pretty impressive new feature of gcc/g++ available in the latest devkitarm.Look at that. MapWindow.cxx:377:23: warning: %i directive output may be truncated writing  between 1 and 2 bytes into a region of size between 0 and 9 ... [More] [-Wformat-truncation]snprintf(msg, 32, "@%i,%i : %s [%ix%i]",xpos, ypos, why,                   ^~~~~~~~~~~~~~~~~~~~~MapWindow.cxx:689:12: report("editing meta-layer");                       ~~~~~~~~~~~~~~~~~~~~MapWindow.cxx:377:23: note: directive argument in the range [8, 16] MapWindow.cxx:377:23: note: directive argument in the range [8, 16] note: 'snprintf' output between 32 and 42 bytes into a destination of size 32- gcc detected that I'm calling that snprintf function with a value of 'why' that is actually the "editing meta-layer" string, which is 18 bytes long- it understood that this and some numbers had to fit within 32-bytes output- the format characters only take 9 bytes- xpos and ypos are 16-bit values, needing at most 5 characters to be rendered on-screen- 18 + 9 + 4 = 31. that's the case where all the numbers take only 1 byte. We have barely enough room to display the message (and its terminating zero character)- 18 + 9 + 5 + 5 + 2 + 2 = 41. That's the case where we have all numbers using their maximum size. Note that GCC/G++ could guess that we'll only use numbers between 8 and 16 by looking at  blockop?16:8 argument!Having such thing can be super precious when you know what's going on and want to harden your software. Hopefully, there is no overflow expected here. Only truncation. And since the purpose is to put a message on a 32-bytes wide line, I'm fine with truncation here. I'll have to tell that to the compiler the best possible way with some #pragma. [Less]

There is a post on Winter Mute's blog that really feels like it's been written for me. It is about people who build up their own solutions to problems that are researched to death and will stick to them even when being told that better solutions ... [More] exist, whatever the drawbacks of their current solution. Somehow, it is not that far from the "not invented here" syndrom, explained from the point of view of someone who's been working hard to promote a unified way of doing things.If I think about it, the very fact that I'm using a Nintendo DS to make games in 2018 feels like using a cat to clean up windows. I've been asked why not doing it with construct 2 quite a number of times, and people who know me would likely tell you that "oh, but he likes doing it for DS so much..." . I did have a look at a few construct 2 tutos, but they never made me feel like I'd love to do that instead of what I'm doing.I've been asked too why I wouldn't buy a wacom tablet and save my assets as .png files. Granted, I could follow some online tutorials and grow some knowledge about some tools really used in the gaming industry. Yet, I insist on updating my sprite editor and yes, if someone insist that l should really try ASEsprite or something alike, I'm gonna be quite sceptical and likely argue that it's gonna be complicated. (like having to install Windows or Steam first, having to ensure I have a good mouse or be next to my PC to do pixel art, etc.)And apparently, yes, I could be using MaxMod -- the cross-platform sound library shipped by devkit pro -- instead of the unpopular libNTXM with all those odd extensions I've been adding over the years. Possibly wintermute could have put something like "oh, but you know, I'm no professional window cleaner. I'm mostly doing this on my spare time" in his rant, and it would look even more like myself. I don't really have any excuse for this one. It's just that I've been investing time to master the code in libNTXM. It feels a bit like it's mine now. I feel home with it and I'm reluctant to leave that home and move to somewhat uncharted territories.I know there is one thing for which I do not want to make compromises, and that's the quality of the end result. Be it a hobby or not, I do not want the game to feel half-baked. But when it comes to picking either library, using design patterns or learning new tools... well, I don't want anybody to feel offended or sad. But yeah, I'm doing that after my work hours. After my clean-the-mess hours, because aside all the amazing things I do at work, I still wonder if the game ideas I have would work great. Because there was something about C64 programming I loved.None of this make Wintermute any less right that buckets and mops are better tool to clean windows, of course. [Less]