r4volu7ion

Bon. Si je veux convaincre mes potes de tester mes p'tits Bilous sur leur DS, il serait temps que je m'assure de la compatibilité avec les linkers autres que mon "supercard". Mon frère est sur le point de se marier, donc il n'a pas vraiment besoin de sa DS pour les semaines qui viennent. Je la lui chipe donc, histoire de voir ce qui coince...

• 26 juin : selon Smealum, ma p'tite démo ne passe pas sur le R4
• 29 juin : premier test sur la R4 de mon frère, visiblement c'est l'initialisation ARM7/ARM9 qui coince
• 30 juin: ouf. la R4 est quand-même capable de charger un .nds avec du code 'custom' sur le processeur ARM7. C'est donc juste que mon code est foireux.
• 13:37 petit debugging à coup de "changement de couleur de fond". l'ARM7 compilé sans NTXM entre bien dans la routine "setupWifi()", mais reste bloqué en attente d'un fifo_temp==IPC_WIFI_INIT. Normal : j'ai retiré toute référence au wifi du côté ARM9 :P ... A noter malgré tout que celà n'empêche plus le traitement des autres évènements ...
• 17:00 "si tu veux, je teste ça ce soir sur mon M3" dixit Oli ... wait'n'see
• 20:00 je re-teste entre deux copies ... apparemment, c'est l'activation de la bibliothèque NTXM qui pose des problèmes ... je reprends mes habitudes de développeur de bootsector: on change la couleur de l'écran en fonction des étapes franchies dans le code, avec une légère variation pour prouver que le CPU est toujours bien actif ;)
• 22:30 ok. c'est l'interruption timer qui douille. je la désactive, ça me fait toujours un runme fonctionnel sur R4 (auto-update et téléchargement compris. fini le card-swapping) mais pas de son :'(
• 22:55 YES! on rajoute Song=0 dans le constructeur de Player et hop! ça marche "revolution ... r4volu7ion ... mem0ry ... m0re mem0ry" comme disais JMJ ;)

I'm doing tests with my brother's R4 this week and trying to find out what's going wrong with that latest demo. After a couple of hacks, it turned out that the ARM7 is apparently halting at some point when the NTXM player is enabled ... weirdo.

I already found a couple of uninitialized pointers, but unfortunately, the problem can only be reproduced when launching the software from R4 menu (launching from runme works like a charm, but then you need a no-sound version of runme to get bootstrapped :P) I've been somehow cheated in my attempts, though, by the fact that i kept the SuperCard in slot 2 while doing tests from the R4 on slot 1 ... Somehow, the FAT library "prefers" the supercard and i ended up running program out of the R4 that was doing I/O (and WiFi upgrades) through the SCSD :P 

(PS: je ferai une nouvelle release demain, après m'être assuré que j'ai bien un binaire qui marche, l'EFS lib et le DLDI fonctionnel, etc)

edit: éviter le mélange SCSD dans le slot 2 et R4DS dans le slot 1 pour le dev. on est jamais trop sûr duquel est utilisé par la libfat :P du coup, je m'interroge ... est-ce que j'ai vraiment réussi à avoir le son et le wifi sur la R4 ?

1036 tiles is far too much.

J'ai foiré. Vendredi soir, j'ai voulu pour rire animer une petite touffe d'herbe en plus de mes pommes et après avoir sauvé, vlan, plus rien. Je ne panique pas et je démarre le moteur de jeu qui refuse de charger le niveau avec le message "1036 tiles is far too much". Argh! J'avais oublié ... A force de dupliquer des pages de sprites pour faire des essais, etc. J'étais arrivé *tout juste* à 64K de graphismes, ce qui correspond à la limite que j'avais imposée pour rester dans une gestion toute simple de la mémoire.

Bon, le problème sera vite résolu dans l'éditeur de niveau (qui était de toute façons prêt à gérer 256K de graphismes, c'est juste un oubli), mais pas en ce qui concerne le moteur de jeu. Il va donc falloir que je fasse le ménage mais pour l'instant, SEDS est complètement dépourvu de toute fonction "effacer". On peut dupliquer, ajouter, remplacer par un bloc complètement transparent, mais effacer, ça, non.

Oops. Trying to animate the grass in Bilou's woods turned out in no fun at all when the game engine refused to launch the game with "1036 tiles is far too much" error message. It seems like i forgot that i just reached the 64K of pixels the day before (well, out of which only roughly 1/4th of the tiles need to be kept :P) ... Patching the Sprite Editor to let it edit the spritesheet again was trivially easy, but it won't help as there is so far nothing that *deletes* data in my sprite editor ...

Du coup, je me suis fait un nouveau petit "plan de bataille" pour y remédier:

• [done] remise en route des "fichiers backup" en cas de sauvegarde
• [done] construction d'un "fichier archive" lorsqu'on remplace un des fichiers de travail par un nouveau tileset (p.ex. importé par WiFi)
• [done] une petite mémoire "undo" et un bouton pour rappeler sur la grille d'édition le dernier bloc "écrasé" lors d'un enregistrement dans la "SpriteTable"
• [done] ajouter la possibilité d'avoir un "bloc manquant" dans la SpriteTable, pour effacer des blocs tout en conservant l'alignement général -- et réorganisation des tiles contenus en conséquence.
• [done] effacer toute une page

Ceci fait, je devrais pouvoir 'réparer' ma p'tite forêt. Ensuite, eh bien, il sera temps de penser à la possibilité de séparer les tiles à charger directement en VRAM de ceux qui restent "dormants" en mémoire centrale (p.ex. pour les animations)

Une nouvelle démo

Bon, une petite anim' enregistrée et un nouveau petit .nds autonome pour que vous puissiez tester les amélioration de mon moteur de jeu sur votre DS à vous. Au programme, le nouveau scrolling , la gestion des collisions , les test-points conditionnels (avec moins de bugs dans la gestion des déplacements de Bilou).

Bref, faites-vous plaisir: téléchargez la "ROM" ;)
le programme va démarrer et afficher "Ready." sur la console, sur l'écran du haut. A ce moment, appuyez plusieurs fois sur Y pour exécuter le niveau pas à pas jusqu'à ce que Bilou tombe. Vous pouvez alors le diriger avec le pad. Vous pouvez aussi changer de méthode de scrolling en appuyant sur START.

Here comes a new demonstrator of my game engine, so that you can test the latest improvements on *your* DS : collision management, conditional test-points, new scrolling ... So stop hesitating and start downloading. Once launched, the program will display "ready" and then wait for you to press 'Y' button half a dozen of times to perform step-by-step initialization of the level. As soon as Bilou starts falling, you can control him with the D-pad. You can also toggle the scrolling algorithm by pressing "START".
Les bugs connus:

• lorsqu'il retombe sur le sol, il arrive que Bilou se mette à glisser sans s'arrêter
• si Bilou heurte un mur en saut, il y reste "scotché" tant que vous gardez le bouton "gauche" ou "droite" enfoncé
• quand Bilou n'est qu'à moitié sur une plate-forme, il "tremble" et l'écran du haut défile à toute vitesse. (ce n'est pas vraiment un bug: je n'ai pas encore d'animation pour le montrer en déséquilibre)

PS: il va falloir que je chipe le R4 de mon frère par contre. J'ai régulièrement des testeurs sur dev-fr qui m'indiquent que mes roms ne marchent pas chez eux, et là, en principe, c'est tellement simple que je ne vois pas ce qui peut ne pas marcher. Le DLDI, peut-être ?

edit: j'ai retiré le lien vers la version "efs2.0", qui ne résout apparemment rien pour les utilisateurs de R4. J'ai visiblement un problème avec le code ARM7 qui ne fonctionne pas comme prévu. Investigation en cours ...

Let's >> scroll >> baby ...

edit: screentoaster, video.google.com ... all these are no longer operating and not covered by the wayback machine. Link replacement in progress

Hop. Un p'tit temps de midi et je rattaque le scrolling, maintenant capable de "suivre" véritablement Bilou (plutôt que de se contenter de mimer ces déplacements au risque de finir par le faire sortir de l'écran :P) Le plus délicat, c'est d'éviter un scrolling "par à-coups" comme on avait tendance à le voir dans les jeux Titus, ou (pire) dans le Game Maker de mon enfance :P

It's about time I focus on scrolling again, so that we can actually "track" Bilou's position. So far all it did was mimmic'ing Bilou's moves but as you hit ceilings and floors, it slowly gets off. I realise when playing games of my childhood that a smooth and smart scrolling is the key to a great platformer experience. 

I want to avoid "quantum leaps" that was typicall from Titus games and that sloppy "I'm following you at my speed don't move soo fast" scrolling coded in the Recreative Game Maker my Brother and I used for Badman series.

J'ai eu droit à quelques effets marrant en débuggant (ou déboguant?), comme l'écran qui fait le point-fixe autour d'un moustique invisible tournant autour de Bilou (ça, ça fait mal aux yeux), d'où les dernières lignes) ... ou alors le scrolling qui fait des sauts de puces en arrière après avoir fait un pas de géant en avant ... Bref. Le dernier truc qui reste douteux, c'est le fait que l'écran scrolle presqu'immédiatement vers le haut dès que Bilou saute ... je suis pas fan (ça donne un peu le mal de mer), mais je ne vois pas trop comment l'éviter proprement.

As usual, there has been some odd-and-funny bugs while working on it, such as the camera suddenly tracking "a bee that fly around Bilou" rather than tracking Bilou himself. The last 4 rows of code shown above are designed to avoid that : they prevent counter-centering moves from happening. Yet, it turns out that perfectly keeping Bilou in the center of the screen isn't so sexy. You quickly get sick when you jump often ...

I dug for Commander Keen videos, where you can observe a surprising but efficient approach. The camera only keeps Keen in the center of the screen (vertically) when he's on the ground (not quite at the center, but almost. I'd say some 32 pixels lower than the centre). However, when Keen jumps, the camera remains at its current height, giving a better view of where you're going to land. The only exception is when Keen gets really close to the edges of the screen (some 8 pixels close from the top or 32 pixels close from the bottom). Only when Keen *lands* does the camera quickly bring him back at the center of the screen.

Si on compare, la politique dans Commander Keen est assez particulière. Tant que Keen est au sol, il est maintenu dans une zone proche du centre (pas exactement au centre, mais presque; je dirais à 32 pixels du centre au maximum), mais lorsqu'il saute, on ne scrollera verticalement que si Keen approche le bord haut (ou bas) de l'écran (je dirais de 8 pixels au moins, probablement plutôt 32 pour le bas), et ce n'est qu'au moment ou Keen "atterit" sur une plateforme que le scrolling vertical se recentre. Je trouve que c'est un assez bon choix en somme : celà permet de conserver le point de vue que le joueur avait au moment de prendre la décision de faire un saut, et donc de mieux gérer l'endroit où le personnage retombe, tout en ayant un bonne vue d'ensemble du niveau pendant que le personnage "marche", tout simplement.

Bang!

Alors ? Quoi de neuf dans ce code, me demanderez-vous ? Eh bien, la gestion des collisions. Oui, je sais, c'est assez élémentaire et il y a tellement longtemps que ç'aurait dû être fait qu'il n'y avait vraiment pas de quoi en faire un fromage ... En plus, on en est encore qu'au balbutiements puisque ni Bilou ni les petits vers ne se "rendent compte" que la collision a eu lieu (entendez par là que leur comportement n'est pas affecté d'un iota). Seul le fond de l'écran virant au rouge me permet de m'assurer que la collision a bel et bien été détectée...

Alors pourquoi avoir attendu aussi longtemps ?

Bin parce que je voulais faire ça proprement, tout simplement. En donnant à chaque composant du système son rôle et pas plus. Je veux aussi pouvoir me restreindres à certains types de détections (par exemple, aucune des collisions ver-ver ne m'intéresse), permettre à un sprite d'avoir différentes régions qui réagissent différemment (des "points faibles" et des armes, par exemple) et changer tout ça en fonction de l'état du personnage ... Le taille-crayon "furieux", par exemple, n'aura plus de point faible et même lui sauter dessus blessera Bilou, alors que le taille-crayon assomé n'aura plus aucune zone dangereuse mais au contraire sera "transportable".
L'astuce, c'est donc de garder une liste séparée par "type" de collision, et de définir, pour chaque collision, quel personnage provoque la collision et quel personnage la subit. Bref, vous l'aurez compris : je n'ai pas fini de vous en parler ;)

Edit: oh, oui, j'ai essayé d'améliorer le scrolling (et surtout le tracking de Bilou) ... C'est mieux, mais pas encore vraiment ultra au point.

Woods In Progress

Thanks to some awesome guys at pixelation, my little woods are progressing rather nicely. It's not always very easy as i cannot manage to come with decent pixels with PC tools only, so i need PC-to-DS and DS-to-PC conversions quite often.

After Zeid and tehWexxlorz convinced me (and helped me) to re-think the look of Bilou himself, after Zeid (again) bringing me to give those trunks another try with a "more interesting palette", after Ichigo pointed out how to get a coherent contrast/lightness/saturation over the whole forest, i'm now trying to follow Lackey's advices (and a bit of AdamAtomic's too) to get a fresh new look for my treetops. The picture above, for instance, was a print out of Lackey's edit (bottom) and my first attempt to re-produce it with a simple "bunch of leaves" shape (top).

Les conseils glanés sur Pixelation commencent à devenir porteurs ... Après la révision du look et des couleurs de Bilou (grâce à Zeid et theWexxl0rz), les nouveaux troncs d'abres et l'ajustement du contraste du décor (grâce à Ichigo), c'est au tour des feuilles d'en prendre pour leur grade. Je me suis d'ailleurs imprimé les commentaires de Lackey (image d'en-bas sur la photo d'en haut ;) et ma première tentative avant de ré-importer mon gros feuillage tout plat pour le remanier avec SEDS.

This is a definite departure from the "minishcap style" that i wished to follow initially, and imho, it's not really a bad thing. Unfortunately, i don't have anything like a "level map exporter" so far, so all i can offer you is a screenshot of the level editor showing you a new tree i've been working on yesterday.

Comme vous le voyez, on est bien loin du style "minish cap" imaginé au début ... Ceci a un look ... plus commodoresque, je dirais. Et je vous prie de me croire que j'utilise à 200% mes deux plans de décor sur ce coup-là! Il me faudra d'ailleurs un "copier/coller" sur des zones entières dans l'éditeur de niveau si je veux pouvoir continuer dans ce sens-là.

Pretty nice, but pretty hard to do, and fully using my two layers of background tiles. I will really need an "area cut&paste" tool in the editor if i'm to live with trees like that.

I don't know how you like it. Personally, i think it has some kind of C64 look, and that i still lack some alternate tiles to avoid getting something that shows collection of leaf balls next to each other ;)
Oh, et côté code, j'ai une autre bonne nouvelle à annoncer, mais vous attendrez que ma petite illustration soit faite ... na.

ça grimpote ...

Petit aperçu de ce que m'ont permis mes derniers bricolages sur SEDS et LEDS. Le champignon, tout d'abord, qui a bénéficié du curseur défini dans le post précédent.
Puis les blocs d'herbe qui utilisent la pleine puissance de la construction de niveaux sur deux plans séparés (il n'y a que de l'ombre sous l'herbe, la terre, bin c'est juste des blocs de terre ordinaire qui sont sur le calque d'en-dessous). Et enfin les petites pentes, construites avec seulement 5 tiles supplémentaires, à grand coups de "mode rafistolage" dans LEDS (comprenez: édition tile par tile plutôt que bloc par bloc). Allez, je rajoute les boutons "retourner horizontalement" et "retourner verticalement" dans l'éditeur de niveaux et je pourrai vous faire des "descentotes" aussi ;)