Monday, January 28, 2008
[todo] map editor
Features and interface of the yet-to-come MEDS are getting their place in my mind. I took the time to figure out how i should setup levels of a game in the editor this week-end, and came up with a first mockup.
Detailed features list and code sketch should come in following days...
Petit à petit, l'interface et le fonctionnement du "map editor" à venir commencent à prendre forme dans ma tête... à suivre.
edit: idée: utiliser "R" pour basculer le focus du D-Pad entre la map et le tileset. En mode "map", le dpad nous déplace d'un tile (ou d'un-demi écran avec L+DPAD). en mode "tileset", le dpad choisit le nouveau tile à utiliser et L+DPAD permet de modifier la "taille" du bloc de tiles à copier (p.ex. pour dessiner toute une télé d'un coup).
Monday, January 21, 2008
dldi - chishm & stub
As most modern linkers perform that "driver patching" automatically when loading our homebrew, we tend to forget that they even exists (especially me, since i'm owning a pre-DLDI linker that works with built-in drivers of the libfat :P). Arialia first notified me of that i was missing something in the process... Then began the hide-and-seek game with (undocumented?) process of loading and patching code with DLDI drivers.
A bit of googling could not locate chishm's source for the NDS loader, but crawling the forum did. One of the nice things chishm does in his loader is to reuse the DLDI driver of the current binary to patch the loader (and the program to be loaded). Let's see how it works.
pDH = (data_t*)(((u32*)(&_io_dldi)) -24);
pAH = &(binData[patchOffset]);
The first entry in the IOinterfaces table is reserved for DLDI devices. Note that the DLDI patcher will *keep* this "placeholder" interface so that, once patched, the driver's description is still at _io_dldi ^_^. Moreover, right before the actual ioInterface structure, we can find a placeholder for the DLDI header, including code/data sizes, and location of the Global Offset Table required for patching.
if (*((u32*)(pDH + DO_ioType)) == DEVICE_TYPE_DLDI) {
// No DLDI patch
return false;
}
One of the tricks involved is that, if no DLDI driver is installed, the ioInterface's "type" is set at compile-time to the "DLDI" string. Once patched, it gets replaced with the vendor/product mini-id (e.g. SCSD for Supercard, securedigital or MPCF for "media player, compactflash", etc).
The rest is just going smoothly. I initially feared that the restriction of 16-bits access to the VRAM would doom the entire loading process, but obviously, it does not apply when VRAM is mapped as "LCD" (plain CPU access, offscreen). That's nice.
Tuesday, January 15, 2008
PPP Team
Le 'studio' PPP Team, c'était un noyau dur formé en 1994 par mon frère et moi (Piet et Pypein -- voire, tout simplement "Pype") et un collègue de classe de mon frère (Pierrick, légèrement notre ainé qui allait intégrer et alimenter notre monde d'adolescent avec un statut proche du mentor). Après quelques débuts balbutiants, c'est essentiellement autour du Game-Maker de Recreational Software Design que le "groupe" allait s'agrandir, accueillant T.Bob et son frère, Pascal Kameah et Nowan, tout en gardant Bilou comme fer de lance. Un peu plus tard (entrée à l'Unif), c'est Gino et Kris qui vont offrir au "groupe" un nouveau souffle lors d'une existence éphémère sur la DemoScene Belge.
"PPP Team Software", that was our name. Mainly my brother and I (Piet & Pype), plus our friend and class-mate Pierrick who fed our teenaging with pixels, square waves and katas. Our growing experience with the Recreational GameMaker attracted other friends in the adventure (mostly through our 'sub-licensing' policy : 'we only deliver copies of this shareware to people who join the team'): T-Bob and his brother "chipset", Paskal 'Kameah' and Nowan. In '97, I enter the University and subscribe to a geocities account (on the Haven of Silicon Valley ^_^). Then, one floppy at a time, using all my lunchtime watching FTP transfer progress, I uploaded some of our games, small tools, and my brother's music into a website which is - by today standards - the perfect opposite of what it should be. As we later meet Kris and Gino, and hit the "demoscene" world, report of our "success" at Inscene'99 and Inscene Y2K got included as well. Enjoy my personnal mirror of this now-definitely-gone page of web history.
Dans un style "encore ados, on va révolutionner le monde", à faire pleurer le plus coulant des webdesigners d'aujourd'hui, je vous propose une petite balade de santé dans
Au menu:
- la présentation des jeux 'publiés' de PPP Team (pour Tbob et Pascal)
- la toute première présentation du projet Clicker32 (pour Kris et Nowan ^_^)
- notre petit passage sur la Demoscène (pour Gédéon et Gino)
- des petits outils que j'avais fait ...
- la toute première page pour les musiques de mon frère (attention, le design est assez horrible).
Tuesday, January 08, 2008
[C64] Shoot'm'up Construction Kit
Seule une version assez rudimentaire a l'air d'avoir résisté au temps, pour ce qui est des exécutables, en tout cas (~10 minutes de chargement). J'ai bien les fichiers "données" de version a priori plus récentes, mais rien n'est sûr. Et comme je n'ai évidemment plus l'éditeur lui-même, l'histoire en reste-là pour l'instant. Je vous invite à passer faire un tour sur ma collection de vidéos pour voir ça en live, ou sur celle de frikilokooo, pour avoir une idée du fonctionnement de l'éditeur ...
Et pour ceux qui ont un player flash bien à jour, vous avez des vidéos de meilleure qualité dans la collection de mon frère.
It's been a long (and über-fun) LOAD "$" story, but we (my bross and I) finally retrieved the long lost "jewel": the Commodore 64 version of 'Bilou's Sky Quest'. It was a Shoot'm'up game i made up during the 1998 summer using Sensible Software's Shoot'm'up Construction Kit (SEUCK), about one month before we burnt out the C64. It seems that only an early release of the game has survived the 10-years time travel (or at least in an executable form), but i have good hope that some of the other files i've located on the disks might be sources of later versions (with better graphics and more interesting ennemies).
Now i'm investigating the options of connecting the C64 and its floppy drive to a PC system so that i can 1) retrieve the binary and data files and export them to the world and 2) import the SEUCK software back on the C64 to build playable disks of the later version... Of course, we shot video of the whole event, which you can watch on youtube by clickings links in the french text ^^"
edit: le cable PC-C64 s'appelle "X1541". Il passe du port parallèle au lecteur de diskette (5 petites pinoches à brancher) après quoi le programme "Star commander" sert à lire et écrire sur la diskette...
edit++ voir les conseils de TORX et la causette sur le blog "Commodore User Charleroi"
Sunday, January 06, 2008
Un bot, sur C64
Je connais un bot qui s'appelle ANA.
Et qui tourne sur C64 ^_^.
Tout ça pendant que j'essayais de vous uploader les vidéos de la session C64 avec CJ, mais ça, ce sera pour une autre fois, parce qu'on ne s'en va pas, monsieur, mais il se fait tard, il faut que je rentre ... chez moi.
Au fait, vous saviez que les .SID contiennent carrément du code exécutable pour le CPU du C64, vous ? eeh oui. Rien avoir avec les .MOD de l'amiga, donc. Et du coup, pas étonnant qu'on ne mette que difficilement la main sur un "tracker" pour C64.
Retour du Commodore 64
(il charge)
(il charge encore)
(il charge toujours)
Croute. Non. "LOAD ERROR" après 10 minutes de chargement...
Perdu. Bon, d'un autre côté les disquettes doivent avoir plus de 15 ans, maintenant.
Saturday, January 05, 2008
Le dernier temple.
L'occasion de faire le point sur ce jeu très sympa mais qui ne détrônera pas "Link's Awakening" au panthéon de mon jeu de Zelda préféré. Okay, il y a eu des éléments très sympas dans ces derniers donjons (il n'y a pas d'ordre particulier pour affronter les deux derniers, notez), en particulier les 1001 utilisations du grappin (enfin un grapin pratique à utiliser! notez bien ça), mais 'juste' 6 temples (contre 11 au moins dans Zelda 3 et 8 dans Link's Awakening), je trouve que ça reste un peu court. Enfin, il y a le temple du roi des mers qui est d'une profondeur (sic) à nulle autre pareille. Et finalement, le coup du temps limité est une trouvaille de génie. (Lors de mes deux dernières visites, j'ai trouvé ma carte marine à l'arrachée et à grand coup de potions magiques pour me redonner des coeurs).
Mais que manque-t-il donc à Phantom Hourglass ?
Probablement pas le "monde en terre ferme". L'océan est sympa, plein d'îles mystérieuses absentes des cartes, mais que vous pourrez rajouter en croisant au large, par hasard.
La chaîne de l'échange, peut-être ? Ca devenait un peu éculé, mais je trouve qu'elle nous impliquait plus émotionellement dans l'aventure et dans des relations avec les petits personnages de l'île.
Les miniboss ? sûrement. Le seul temple que j'ai du reprendre à plusieurs coup, c'est celui où un "lapin-glouton" devait être vaincu. Dommage, après l'avoir affronté une fois, j'avais déjà accès à un "raccourci" pour y être en 5 secondes depuis l'entrée du temple :-/ Dans Link's Awakening, chaque donjon possédait un "miniboss" et un "téléporteur qui ramène au milieu du chateau". A la place, les temples de Phantom Hourglass ont des téléporteurs juste avant le boss final (je ne pense pas m'en être souvent servi, mais c'est ridiculement trop simple, si vous me demandez) et un de ces "raccourcis" qui font qu'à mi-parcours, vous avez réouvert l'accès à l'entrée.
Et les dialogues avec les Boss ? où sont-ils passés ? Vous croyez que je vais me satisfaire de voir le monstre onduler la tête en hurlant avant le combat ? "Héhé ! tu ne m'auras pas tant que j'aurai ma jarre" ... "Quoi ? tu as cassé ma jarre ? Là, je suis Furax!".
Bon, ils n'étaient pas tous aussi inspirés, mais bizarrement, le fait d'avoir "causé" avec le monstre lui donne plus d'ampleur. Il n'est pas juste fait de muscles, il y a une intelligence démoniaque derrière qui dirrige toute ça haine contre votre petit bouclier dans chacune des attaques.
Je vous invite à jeter un coup d'oeil au donjon 5 de "Link's Awakening", en guise de comparaison. Un des plus énigmatiques par ce que parsemé de salles "vides" au premier passage dans lesquelles vous affronterez le même miniboss (le squelette à l'épée) dans un ordre subrepticement caché. Autre truc vicelard, les passages souterrains (en side-scrolling, à la Mario) qui vous transportent un peu n'importe où dans le donjon, de sorte que vous êtes obligé de mémoriser bien mieux par où vous passez. Dans PH, tout est quasiment 'transparent' et il "suffit" de retourner voir la carte du niveau au-dessus (ou en-dessous) pour savoir comment atteindre un point donné.
J'ai remarqué beaucoup moins de "respawning" des monstres dans les temples de PH, aussi.
Enfin. J'étais tout jeune, à l'époque de LA. Maintenant, j'ai des années de Zelda d'expérience, et je n'hésite plus sur ce qu'il convient de faire quand je vois un oeil dans un mur ...
Ah oui. Il y avait ces bêtes puzzles, aussi. Les petits chevaux à lancer jusqu'à ce qu'ils soient debout tous les deux, les pingouins-carte-à-jouer, etc.
note: les maps vers lesquelles je vous envoies font partie du projet vgmaps. Si vous tombez sur une image-fourre-tout au lieu de la map en question, essayez en passant par leur répertoire.
edit: note pour plus tard: dans le combat contre bellum, penser à donner des coups d'estoc plutôt que des coups de taille.
Tuesday, January 01, 2008
"Je vous présente les bordures!"
Je viens de retomber sur une lettre -- datée du 8 janvier 1900 -- que je n'ai jamais envoyée à son destinataire, Gédéon (qui signe de temps en temps un commentaire du nom de 'Ged' sur ce blog). Il faut dire qu'après la Inscene '99 et la collaboration de CJ à son jeu "insane bugs" (une sorte de remake de micromachines), on avait entamé une correspondance sur des sujets traitant de la réalisation de jeux vidéos, que j'illustrais assez abondamment de mes Bilous, évidemment.
edit 2021: finally translated.
A cette époque, en pleines études, je codais surtout pour les TP de l'université, mais je n'avais pas énormément le temps de mettre en oeuvre tout ce à quoi je réfléchissais pour mon "Ultimate Game Maker"
Voilà ce que celà disait:
Hello, Gédéon.
Je crois bien que j'ai trouvé un truc cool pour modéliser les niveaux dans Bilou! un truc plus smart que ces "tests de couleurs" puants que j'ai utilisé dans la version BASIC du jeu!... Je te présente les bordures.
L'idée est la suivante: tes sprites possèdent un certain nombre de "testpoints" et les déplacements ne sont possibles que pour certaines valeurs de ces test-points (pas question de faire marcher Bilou dans le vide, hein!)
D'autre part, tu plaques un peu partout dans ton niveau des bordures. Ces bordures sont des éléments logiques qui ne correspondent à aucun affichage. Elles sont liées logiquement de telle manière que l'on peut facilement savoir quelle bordure est située à gauche, droite, au-dessus ou en-dessous d'une bordure donnée. Les bordures sont également séparées en 4 classes: plancher, plafond, mur-gauche et mur droit.
Ca va, je ne vais pas trop vite ?
Bon. Voyons comment ça marche. Lorsqu'un sprite crèe ses test-points, il leur fournit à chacun une classe correspondant à la classe de bordure avec laquelle ils réagissent. Du coup, on s'empresse de lier chaque test-point à la bordure de même classe la plus proche (euh, ça ne devrait pas être trop sorcier).
Voilà un aperçu de la chose en cours ... tu peux facilement savoir si tu es "dans le mur" ou pas: il suffit de regarder de quel côté de la ligne le point se trouve. Dès que ton point sort du "champs d'action" de sa bordure, on cherche quelle est la nouvelle bordure et on y relie le testpoint (après quoi on effectue le test habituel).
C'est-y-pas merveilleux, tout ça ?
Allez, une dernière idée qui m'est venue comme ça, en écrivant cette lettre (pour être sûr que tu n'arrives pas à dormir cette nuit ;-)
Au lieu des testpoints, tu pourrais faire des "bordures" pour les sprites aussi (en fait, à partir de la bounding box), mais tu risquerais d'avoir plus de calculs à faire ...)
Enfin, ça m'éviterais d'avoir des bugs à la "Crazy BriX".
Allez,
Bion, depuis, l'eau a coulé sous les ponts. Le coup des "bordures" était bien alléchant, il permettait de passer à la 3D avec moins de prise de tête que si on doit procéder pixel par pixel (c'était le cas dans Bilou en Basic, comme je le mentionnais dans la lettre), mais par contre je n'ai jamais trouvé le véritable "truc pas trop sorcier" pour déterminer quel est la prochaine bordure du même type, en particulier lorsqu'il y a plusieurs plate-formes les unes au-dessus des autres (classique dans un jeu de plate-forme, évidemment).
Pour la version "DS", je me rabats principalement sur des tests "tile par tile" (et prout pour la 3D), et les "bordures" serviront principalement pour des plate-formes mobiles, nuages, et autres joyeusetés ... Une sorte de manière de passer outre les limitations typiques des jeux "game maker".
Voilà. Bonne année à tous.