spr.load+

The next big step for my game engine to be capable of running project “Bilou  Dreamland” is overlay loading. In all my previous games, there was one main tileset and sprite set that contained all we needed. Monster, hero, Pick-ups. Anything that had to be animated sat together in that file…

Bon, prochaine étape significative pour le développement sur DS: faire en sorte que le game engine puisse charger les graphismes "en deux temps", en particulier pour les sprites. J'aimerais bien éviter de devoir répliquer le graphisme de Bilou sur plusieurs spritesets, tout simplement.

Et ouaip, j'étais prêt à lancer ça en début de congé de Noël, puis je suis laissé distraire par un 'to branch or not to branch', *deline m'a chipé la tablette pour lire du Ewilan, et moi je me suis mis à faire du déterrage de brouillons :-/

C'est ça, la quarantaine: ou bien tu code, ou bien tu blogges. Les deux, c'est niet.

In order to come up with a “world 2” that features new creatures, this has to change. Especially, I want to have a single “Bilou.spr” containing character animations for all moves. The engine will then complete this with world-specific monsters and NPC data. When you think about it, the very reason why there’s never been a level 2-1 in my BASIC games was because  I couldn’t find the proper solution to this design challenge.

Mais, allons. Ne soyons pas défaitistes: c'est pas que je n'aie rien fait sur DS pendant les vacances. Juste que je n'ai pas fait ce que j'avais prévu, et que j'ai complètement perdu de vue depuis ce que j'ai fait depuis ce moment.

Plutôt que de me lancer dans une nouvelle branche, j'ai stabilisé et consolidé les différents outils.

edit: j'ai déjà quelques p'tites modifications qui donnent pas mal.

Par contre, il faudra que je réfléchisse à un moyen de valider que tout ça fonctionne bien comme prévu.

Well, I was about to start this at the start of xmas holidays, and then *deline picked up my boox to do some e-book reading while I was wondering whether a new branch would be required or not and then I ended up spending the holidays posting some very old drafts. Welcome to being 40: blog xor code.

well, nor the whole holidays, actually . I’ve still been able to do some ndsdev, just not the kind of things I expected. Tools are now stronger and more reliable. I’ve finally started to code something for it, but I need to figure out how I am going to test that.

edit 30/1: j'attaque...
edit 2/2: sprdo could help testing it.

Sandopolis Zone and Mega-tiles.

Ok, au départ je cherchais des références pour les couleurs et le style de la "desert/pyramid zone" de mon prochain jeu. Et je venais de découvrir l'existence de Sandopolis, région d'un jeu Sonic jusqu'à laquelle je ne suis probablement jamais allé.

At first, I was just trying to find colour references for the pyramid/desert level of my next game, and I just had discovered the Sandopolis zone in some Sonic game (where I never managed to have my red shoes around). The tileset was a big .zip where I should have found all the backgrounds, but instead of the expected 'tilesheet', I stumble upon a set of 128x128 pixels pictures.

Un beau gros .zip dans lequel était supposés se trouver tous les décors, mais au lieu d'une "tilesheet" habituelle, je tombe sur une collections d'images de 128x128 pixels. J'étais resté un peu intrigué mais sans plus. Puis en revoyant la vidéo "making of Sonic 2" de splashwave, le doute n'est plus possible: il y a un niveau intermédiaire de map, et ces blocs de 128x128 pixels sont bels et biens des morceaux de puzzle construit à la main pour servir ensuite de de bloc de construction dans un niveau. On va les appeler des "mega-tiles".

I then shifted from "puzzled" to "enlightened" while watching the Sonic 2 making of video by Splashwave. There was no more doubt to have: there is truly an intermediate level of design -- 128x128 pixels areas hand-crafted by the graphics people out of brainstorming proposals, and making best reuse of the 8x8 tiles. Level design people then use them as jigsaw pieces to get the desired chains of jumps, boosts and loops. Note how the in and out ground height is standardised over the mega-tiles, btw. The core idea of this technique is of course to improve space efficiency: levels in Sonic may get as large as 10000x2000 pixels and the machine only has 64K of RAM. A 100:1 compression ratio is more than welcome in this context.

Avec les mega-tiles, on peut atteindre ainsi un taux de compression proche de 100 pour 1. Les niveaux de Sonic avec leur taille surréaliste de 10,000 x 2,000 pixels tiennent en réalité dans moins de 64K de mémoire.
Et si on regarde un niveau construit avec suffisamment de recul, on peut commencer à trouver des correspondances. Commencer seulement, parce que c'est loin d'être complètement évident ... et j'aurai eu recours au mode "soustraction" de Gimp pour les mettre en évidence.

Yet, when you have a look at a sonic map, it isn't obvious that it is made of such mega-tiles. To see them,  I had to use the same trick I used to locate tiles in SuperFrog: duplicate the layer and turn it in "substraction" mode, so that tiled area suddenly turn as all-black squares when they overlay.

Et si on ne s'en rend pas compte en jouant, c'est grâce aux différents éléments qui eux ne font pas partie de ces blocs : les télévisions, les anneaux, les ennemis ... Et parce que contrairement à un jeu "type Mario", la disposition des blocs de taille 16x16 au sein du jeu a nettement moins d'importance. J'entends par là que Mario interagit avec un bloc de brique ou un bloc-question individuellement. Et le fait qu'un saut soit possible ou non se décide à un bloc près.

I see two possible reasons explaining why those mega-tiles remain hidden to the player. First, the level designers have an additional layer of diversity with rings, screenchests, spikes, bumpers and baddies. Second, unlike a Mario-styled game, 16x16 blocks layout within the level makes little practical sense: Mario interacts with individual blocks frequently, and a mere block may define whether you an clear a jump or not. This isn't the case in Sonic: the speed, not the layout, defines whether you make it through -- or whether you find the appropriate bumper to gain extra height/speed. And even when you aren't high enough, you can still make it through a less-impressive backup route.

Pas dans Sonic. Selon qu'on va plus ou moins vite, on passe ou non. Selon qu'on trouve le bon bumper ou non, on va assez haut. Et quand on n'est pas assez haut, il y a de toutes façons une route inférieure à suivre. 

edit: a nice document entitled 'a level map is assembled with 64 parts' shows up in interview. Note that the width of a meta-tile allowed one loop to fit one meta-tile (and that the loop is actually made of one background tile and one foreground tile)

Habillage ...

Il est temps de passer du 'test fonctionnel' à quelque chose de plus "habillé" pour le dernier niveau vertical. Jusqu'ici, je m'étais contenté d'un minimum de graphisme (les blocs-sol) pour vérifier si les sauts étaient possibles. Il est temps de dessiner le reste des objets.

Ouais, sauf que pour avoir des dessus-de-fardes-sur-lesquels-on-marche un peu partout dans le niveau, c'est pas forcément simple. J'avais pensé à des "couches" suggérées par différentes couleurs (il y a déjà une convention dans l'ensemble du jeu du genre farde verte = mur, farde brune/mauve/vert-foncée = plate-forme semi-solide), et faire des structures un peu imbriquées comme avec mes bons-vieux-buissons.

Since April, I've been extending the "vertical, last level" of School Rush with some more platforming challenges. I intentionally kept the look of the level ultra-minimalist for monthes, as it is much easier to tweak the location of the platforms and adjust difficulty that way. I haven't touched the layout of the level in weeks, so I guess it is ready to receive more complete look.

I had plans to fake depth between level elements such as books or binders to justify the presence of so many platforms without having significantly more "ground", although there is some from time to time. And I was also planning to reuse the color conventions present in earlier levels of School Rush, such as "green book = wall, purple book = jump-through platform".

But that was missing the annoying fact that I can change the colors only on the background layer of tiles, while I typically need both background and foreground together to combine small objects into larger structures as I did with the green zone's bushes.

Sauf que pour faire facilement ce genre de choses avec un tileset réduit, je jouais sur les deux plans de tiles, toujours le même pour ce qui est par-devant, l'autre pour tout le reste. Mais mon moteur de jeu ne permet pour l'instant de changer la palette de couleurs que pour les tiles d'arrière plan: les tiles d'avant-plan sont systématiquement "verouillés" sur la palette #0 et les bits correspondants sont utilisés pour encoder le type de bloc.

This is thus one more motivation to change things in the game engine and take the "tiles properties" array out of foreground palette information, but hopefully, I have enough room (~20% left) in my blocks tileset to accommodate for some "combined" tiles, be it at the cost of manual palette retro-fitting.

But I know this cannot be labeled as "the solution" for this problem: It killed the Badman III effort by making the art impossible to manage. Later on, I'll have to address the issue for real.

Bref, pour cette fois-ci, je vais me débrouiller en créant "à la main" des tiles supplémentaires qui "combinent" les deux couches, avec des imports de palette, mais ce ne sera pas beau à regarder dans l'éditeur (parce que le joueur ne devrait pas voir la différence, lui). Décidément, tout cet été pousse vers un déplacement des propriétés du niveau hors des couches de "rendu".

Vieux vieux pixels ...

Quand je vous disais qu'au début de l'aventure de Bilou, je réalisais mes décors sur des feuilles millimétrées. Je vous ai retrouvé le tout premier "tileset" de la green zone...

Here come some oldies ... tiles on a millimeter-grain sheet of paper, waiting to be converted into list of numbers. 

That's how you develop video games when you're allowed to use the computer at most 1 hour a day... and don't have a colour screen. 
Monsters were designed in the same way, but it wasn't easy to make sure animations would work well. That's why I shifted to modular animation instead for the BASIC version.

Et en bonus, le tout premier appleman, le boss de la green zone et SpongeBop du temps où elle trainait par terre.

LEDS & OpenGameArt ...

Si vous en connaissez pas encore opengameart, c'est bien dommage. Des dizaines de graphismes pour des jeux vidéos offerts à la réutilisation par leurs créateurs, voilà qui devrait éviter de passer par la case "voler les sprites de Mario" à bien des game-makers amateurs.

Comme je recommence à bosser sur mon éditeur de niveaux, la question se pose à nouveau "quels graphismes pour une version démo", histoire que vous puissiez essayer le soft même si le pixel art est totalement obscur pour vous. Eh bien, pourquoi pas ces anciens graphismes du jeu frogatto, justement ?

It looks like you won't get biokid-inspired tiles for the demo first release of LEDS. Neither will you get that 8-bit-restricted tileset for Apple Assault. Why would I push poor/old game art of mine where there's some ready-for-use tilesets on OpenGameArt, hmm ? These old frogatto tiles, for instance, dropped into public domain, would be perfectly fine. With some luck, annoying bugs should be gone by end of the week, and I'll be (at last) able to offer you a level-editor release 0.1 to toy with ^_^.

La question étant réglée, il me reste quand même

1. à m'arranger pour que la partie du niveau à l'écran ne soit pas perdue quand on quitte le mode "édition des monstres" -> done
   
2. à permettre de nommer la map au moment de la sauvegarde -> done
   
3. à vider le lave-vaisselle.
4. à permettre le "flipping" des graphismes dans l'éditeur de map. -> test
   
5. à garantir la cohérence du "curseur" sur le tileset. -> done
6. à empêcher le passage en mode "draw" depuis le "meta-layer" -> done.
   

edit: fichier converti avec les mêmes options que la "spritesheet" de Badman, l'automne dernier (déjà!).

ramno^1

En août 2008, poussé par un manque de mémoire vidéo,j'avais modifié SEDS pour qu'il puisse stocker les blocs séparément des sprites tout en gardant un seul fichier ".spr". Il aura fallu attendre février 2009 pour que cette modification soit pleinement supportée par le game engine et plus encore pour que l'éditeur de niveau en tienne compte.

The code snippet above is the handler for the "!extra!" button you can see below the Bilou sprites on the picture below. So far, it allows me to place whatever is drawn with SEDS either in the "blocks" tileset or in the "sprites" sheet. Since the Nintendo DS has separate VRAM banks for both, it's clearly worth the effort (the tale of this feature is now collected under the tag "ramno"). Last year, as I was sketching vines for the "nuts&bolts" project, I started using the "sprite" ram both for sprites and sketches. Soon or later, that's gonna catch me in the back. Since I'll have to update the sprite editor for r32, I'd like to add a separate "blockanim" and "draft" set. That could be helpful for the (yet to come) animation editor as well.

L'an dernier, alors que je fais un tour d'horizon des modifications à apporter pour Nuts&Bolts/AppleAssault, je dessine un paquet de lianes dans l'espace réservé au sprites (le tileset pour les blocs étant proche de la saturation), ne copiant que les blocs qui sont satisfaisants dans la zone de mémoire "blocs" utilisée par l'éditeur de niveau. Le texte "!extra!" sous les Bilous est donc le bouton permettant d'indiquer si la page fait partie du tileset par défaut (blocs) ou supplémentaire (sprites). Clairement, si j'avais eu plus de sprites, je me serais de nouveau retrouvé bloqué. Il faudra donc prochainement que je passe à un mécanisme à 4 positions: "blocs, sprites, blocanim, draft", la dernière position étant de fait réservée à des scribouillages internes au Sprite Editor. Je dis "prochainement", parce que l'éditeur d'animations, lui, n'aura que faire de ces scribouillage :P

Il y aura donc du rt^1 qui va devenir du (rt+1)%4 dans l'air prochainement.

Way of the Pixel ...

Quelques tiles sur le thème "forêt" et "temple déchu dans la jungle" chipé sur Pixelation que je voudrais bien étudier ...

a couple of tiles from various artists that i have grouped together for study and tests using SEDS. Note the relatively low number of colours per tile : pixel artists tends to work with 16 (sometimes 32) - colour palettes.

Sources: vierbit's jungle (old link), opacus' floating(?) rocks and jericho's rpg tree

Vous courriez ? J'en suis fort aise! Eh bien, Sautez, maintenant...

Je discutais DS et bilous avec Dider, mon beau-frère informaticien, et je me rends compte que des techniques que j'ai apprises "sur le tas" avec mon Bilou's Adventure en QuickBasic peuvent parfois être pas si évidentes que ça pour des personnes qui ne baignent pas dedans depuis 15 ans ^_^

Outre les aspects techniques qui font que les images du jeu s'affichent convenablement, une question-clé était "mais comment programmes-tu les murs, les sauts, etc." Rappelons-nous tout d'abord que sur une console de jeu, l'écran (en tout cas pour les modes 2D) ressemble plus au carrelage d'une salle de bain qu'à n'importe quoi d'autre. Vous avez de jolis pavés (parfois appelés "tiles" ou "blocs" selon les cas) sur lesquels vous avez amoureusement dessiné des bouts de livre, d'encrier, de crayon, etc. Chacun porte un numéro et il suffit d'inscrire son numéro dans une grande grille pour construire l'image voulue.



Bion. Maintenant qu'on sait ça, on voudrait pouvoir détecter s'il y a ou non un sol en-dessous de Bilou, histoire de s'avoir s'il doit tomber ou rester sur place. Rien de plus simple: on va calculer les coordonnées d'un "point-test" situé juste en-dessous de Bilou et regarder le numéro du pavé au-dessus duquel il se trouve. S'il s'agit d'un crayon, d'une latte, etc. on ne bouge plus! Sur PC, j'avais traduit ça en une division des couleurs du jeu en deux sous-ensembles: les couleurs "solides" (pour dessiner les livres, etc) et les couleurs "de fond" (pour dessiner le fond. warf.), mais sur une console comme la DS, on a généralement plusieurs plans de décor, et pour commencer, on peut tout à fait décider que tout ce qui n'est pas "solide" set sur un autre plan: lors du calcul du "point-test", on verra soit le pavé #0 (du vide), soit un autre pavé, qui indique qu'on a affaire à du sol.





Bien sûr, ce que je fais avec Bilou et ses points-test peut être généralisé à tout le reste du jeu: les éponges, les crayons, les gommes, les gouttes d'encre et tout le tintouin. Il suffira de programmer les routines de déplacement de chaque élément du jeu pour qu'il fasse ses propres tests et réagisse en conséquence (passage de l'état 'sur le sol' à l'état "dans le vide", par exemple). Avec ça, vous ne devriez pas avoir trop de mal à vous construire un petit perso qui tombe quand il n'y a pas de sol et qui avance quand il est au sol.
Maintenant, quid des sauts et compagnie ? Bon, si vous avez déjà suivi un petit cours de physique, vous savez qu'un objet qui bouge a un vecteur-vitesse. En clair, si Bilou avance vers la droite, son vecteur-vitesse vaut p.ex. (5,0), c'est à dire qu'à chaque "tranche de jeu" (ou 'tic'), il sera 5 pixels plus loin sur la droite mais qu'il ne monte pas et qu'il ne descend pas. A l'inverse avec un vecteur-vitesse (0,5) Bilou descend comme s'il était sur un ascenseur. Pour donner l'impression qu'il tombe, il suffit d'augmenter la vitesse verticale à chaque tic. Mieux, même, si je démarre avec (0,-5) et que je garde la politique "augmente la vitesse verticale à chaque tic tant qu'il n'y a pas du sol en-dessous de Bilou", il va faire un gentil saut sur place.

Avec un petit calcul niveau secondaire-sup, vous pouvez même calculer la vitesse initiale à donner à Bilou lorsque le joueur appuie sur le bouton de saut pour qu'il puisse (par exemple) faire un saut suffisant pour grimper par-dessus un obstacle de 64 pixels de haut. Facile: il faudra au moins une vitesse initiale de 11. Et c'est là que le bas blesse: on vient de dire que 8 était un maximum :-/ Résultat,

• on pourrait diminuer la gravité (se dire que tomber d'un pixel tous les 1/60 secondes, c'est un peu beaucoup: vous avez traversé 1/3 de la hauteur de l'écran en seulement une seconde)
• on pourrait ajuster nos routines de tests pour qu'une vitesse de plus de 8 pixels sur 1/60 secondes ne pose pas de problème technique
• on pourrait revoir le modèle du saut et "tricher" un peu avec les lois de la physique...

En pratique, si vous regardez sauter Mario, vous vous rendrez compte qu'on a pas vraiment respecté les bonnes vieilles lois de Newton dans les sauts, et pour cause: le joueur doit pouvoir doser son saut, et la manière la plus naturelle de le faire, c'est de relâcher plus ou moins tard le bouton de saut. Dans la réalité, bien sur, ça ne correspond à rien: une fois que vous êtes lancés, vous ne pouvez plus décider que "oups, non, finalement, il faudrait que je saute un peu moins loin si je ne veux pas me tordre la cheville en retombant".

On pourrait faire comme dans ninji & zarbi et demander au joueur de laisser le bouton enfoncé d'autant plus longtemps qu'il veut sauter loin (mimant alors une "accumulation d'énergie" avant le saut) et ne faire le saut que lorsque le joueur relâche le bouton, mais je vous laisse imaginer sauter de passerelle en passerelle sur ce principe.
Non, ce que l'on va faire, c'est considérer que l'énergie dont notre Bilou dispose pour le saut n'est pas consommée complètement en un instant pour lui donner la vitesse (0,-11), mais plutôt que pendant une première phase du saut, Bilou conserve une vitesse verticale plus basse, mais n'est plus soumis à la pesanteur (en gros, il monte à vitesse constante) aussi longtemps que le joueur garde le doigt sur le bouton de saut. Avec un bon dosage de la durée max de cette "phase ascenseur", on pourra atteindre la hauteur souhaitée sans dépasser la vitesse qu'on s'est fixée.

Reste le coup du saut pendant la course. Le premier jeu bilou était assez déroutant dans ce sens. J'avais voulu obtenir un effet "à la Sonic" ou le personnage saute d'autant plus haut et loin qu'il avait pu prendre de la vitesse. L'ennui, c'est que je passais simplement de (v,0) à (v,-v) au moment du saut. Si vous faites le calcul, ça veut dire que au moment où le jouer appuie sur le bouton, c'est comme si l'énergie de Bilou était subitement doublée ... d'où un saut qui n'a rien à voir avec la vitesse de Bilou à ce moment-là. Idéalement, j'aurais plutôt du prendre quelque-chose comme (sqrt(v),sqrt(v)) pour conserver sa quantité d'énergie ...

On testera tout ça...

Sorry non-frenchy folks, this one is a big too large for inline translation. i might come with a dedicated post with translation when i'll have a bit more free time... and implemented the stuff ^_^ Meanwhile, i suggest that you read Gregg Iz-Tavares and Dan Chang's article on M.C. Kids for the NES, which basically covers the same kind of topic.

Tileset [t.a.g.]

Before I can show you how to load graphics with the GEDS engine, I must ensure you all know about how the NintendoDS builds the image we see on screen. I'm using the tiled mode here, where pictures are made of elementary 8x8 pixels elements called "tiles".

You have likely seen level editors where people drop little blocks to create their level rather than using larger "assets". The tiled mode pushes that one step further by structuring the video memory so that it natively works with little, 8x8 blocks. That is, one part of the memory will store such block and the other a 'map' telling which block to use at which place. Some can be used multiple times, some will not be used on this image. The technique is as old as the 8-bit era and was also used in almost every 16-bit machine.

What has changed over the generations is the number of individual colors that can be used in a tile (from 3 to 255) and the number of layers of such tiled maps that you can compose to get your final image (from 1 to 4).

A large part of the .spr files created by the Sprite Editor for DS is a dump of the "tileset" part of the video ram, so that you can easily load it and start rendering scenes with them.

Code:

  SpriteRam myRam(WIDGETS_CHARSET(512));
  SpriteSet mySet(&myRam, BG_PALETTE);

  mySet.Load("efs:/bg.spr");

There is not much the application program needs to do about it: the SpriteSet object of libgeds will exchange data between video memory and SD card storage (or here, filesystem embedded within the .nds ROM). All we need to do is tell it where to store the color map (the palette, the NDS has a specific slice of video memory for that purpose) and where to store the tiles (as we may want to keep some room for a text font and screen maps themselves). Starting at 'character 512' is an easy way to avoid conflicts with things set up by the engine, but you could very well create myRam(BG_GFX) and claim that all the (upper screen) video memory are belong to you.

• see complete tutorial code on github
• see corresponding post (#2) in gbatemp tutorial thread.