GamEditorDS

Good thing: I at least have "real" pixel art for the inkjet. Something that I could use in-game without blushing. Too bad: it's oversized.Inkjets are larger than Bilou in both comic and concept art, but not twice as large. I could live with it if ... [More] only Bilou was not using them as a transportation system. To achieve that, I need the "hole" of the inkjet to be just too narrow so that Bilou can't "fall" into the ink. That's clearly not the case with the middle inkjet. I'll have to resize it around 24x24 rather than 32x32 if I want it to work... and no: I don't really feel like scaling up Bilou :Pedit: Inkjet is like DuckTales (GB): once you've found how to beat it once, it's easy to do it again. Small inkjet is now in the sprite file. Too bad, I did that *before* I merged back SEDS update, and saved the file with an old version ... which dropped my nice ink animation for the spriteset >_< I'll have to find back the trick I used previously to migrate some art between two sprite files. [Less]

(Flickr photo by amaky)A blog is suppose to bring in updates, and yet after 6 years, I keep updating some posts again and again as the situation evolves. It happened again, I'm afraid.So to keep you updated, I managed to fix the school spriteset ... [More] using an upgraded version of SEDS. Spongebop now moves along and chase Bilou like a berrybat because I merely renamed "berrybat.cmd" into "spons.cmd" and then adjusted the animation statements :PIt turned out that most of the things I initially planned as "regression tests" for the editor trivially worked because they didn't care which SpriteRam they were working with... Yet many other things have been identified as broken/misbehaving, and will be fixed in the near future, but only after the revised SEDS is merged back on the trunk... and that will be after I'm back from my next conference. I'll allow myself the right to make SpongeBop behave as it should first, build up a proper animation for Bilou's walk and even to revise the pixel art for inkjet so that it indeed deserves the word "art" :P Oh, mais oui, chers lecteurs francophones, merci à vous de rester là malgré mon emploi du temps surchargé qui me pousse à faire des posts monolingue pour l'instant. [Less]

Here I stand, guilty of doing low-level debugging where the situation wasn't calling it. Now that I have a "test level" for the school zone, it's very tempting to start writing more monster code. I thought I could easily hack a Sponge Bop test while ... [More] *deline was asleep this afternoon, but for some reason, only the first frame of the animation did show up. The rest was just rubbish: Bilou feets and similar stuff.Was my data corrupt ? Was there some nasty bug related to 32x32 sprites in the revised game engine (there shouldn't have been?) I scanned virtually everything, but the data I was (painfully) reading in DDD made little sense.I finally decided to hack some debugging output in my .spr to .png converter to see what "pages" were containing, and I turned suspicious over the following entry:4x4=1020,1036,1052,1068,1116,1132,1148,1164,1180,11961036 ? 1052 ? that's a bit surprising for a sprite number ... when I looked at the shape of the spritesheet, the obvious (finally) hit me: the DS can only enumerate 1024 tiles for sprites. No more, no less. Everything on the fifth column of the spritesheet can be nicely viewed in the SpriteEditor, but cannot be used in games. It's not even the first time I encounter the problem >_<. I think I'll need something in the Sprite Editor that warns the user about this when saving a tileset. And I'll have to figure out how I solved the problem last time...Oh, and it's been over one year that I'm longing for a "draft" tileset and a "animation" tileset in .spr files ... I think it's now time to add this to Sprite Editor ...developments:[done] enable up to 4 SpriteRam;[wish] show how much tiles are used in each SpriteRam (other than pressing L+START to enable debugging, I mean), and which spritepage should be moved to compress the tileset.[done] shrink spritea.spr so that it can be fully used by the engine;[next] enable 16x16 <-> 32x32 sheet conversion;[next] find a way to use the ink animation in the level;[done] produce a warning when saving a file where sprites or blocks set has too much tiles;[done] allow hint on which tile is used when producing tilesets with spr2png.plregression tests after the edit:[ok] change the spriteram used for a page[ok] save and load file with more than 2 spriterams[---] use the "scan colors" and "color remap function" (actually, nevermind: it operates on the working sheet, not on the SpriteRam itself).[ok] use the "compact tileset" feature (doesn't it just reduce the 'watermark' when last tiles are no longer used ? couldn't that be automated with load/save ?)[fair] use the "color zap" (dirty bit and warning message "file your sheet first" ?)[fixed] copying page only works for "blocks" pages.[fixed] cursor-assisted deletion of objects doesn't behave as expected with 32x32 sheets.I'm a bit surprised to see the "SpriteRam*" pointer so scattered all over the code... I might have to change them into "spriteram_no" here and there so that only some core component deal with sprdata[i] directly. [Less]

I've seen the use of multiple palettes on DS first in the Tetris Attack source code.The game used to use multiple palette to handle "shading" of the game when you're K.O. It involves using one of the VRAM slot (usually VRAM_E) as a extra-palette ... [More] place, but you need to map it back as LCD to enable modifications ... so it's not convenient if you're planning to do palette animations.it's completely OK to switch the VRAM bank you're using for ext palette to LCD mode -when in vblanking- to access it, the DS doesn't care when it's not drawing the screen. Just remember to set it back to ext palette mode as soon as you updated its contents. Using multiple palettes, for instance for sprites, could be useful if you want to have enemies with different colors but just store their frames in memory once (/Sverx :)That's good to know. I won't have to drop palette animation altogether if I start using multiple palettes for "painting" books in the school. If I'd be checking gbadev more often, I'd know for quite a while. [Less]

wow. Loading a level with monsters in LEDS is far from being a simple story, right now. LevelModel is the internal representation of your level content, and it can extract the "gob% = state% (%,%)" statements, but it has no idea how to render GOBs. ... [More] That's the job of the MonstersManager ... and to some extent, it makes sense.Once this is laid out, it comes more naturally that LevelModel should also be responsible of storing gob% := (<expression>) statements in Monster instances it creates, so that MonstersManager no longer has to worry about that... And I'm glad I took the time to map the situation, because my previous (jump-to-code) "design" would have been a highway to hell. [Less]

Here it comes. Some final tweaks on dumblador's "walk to the right" animation last night and I now have a CompoundGob that turns back when it encounters a wall (how sweet ^_^)Please bear some GobScript since it's still a pretty simple and ... [More] straightforward monster:anim1 = spr:0anim2 = spr:3statL0 :anim1 {using walkerselfmovetest 0 (2,4)-(8,14) 0001area 0 (0,0)-(8,4) 000A}statR1 :anim2 {using walkerselfmovetest 0 (2,4)-(8,14) 0001area 0 (0,0)-(8,4) 000A}statL0->statR1 on fail (100 :0)statR1->statL0 on fail (100 ~ :0)statL0->statR1 on hit0 (100 :0)statR1->statL0 on hit0 (100 ~ :0)endThe only thing you have to remember about your spritesheet is now the position in the animation slots where your things are. That's slots #0 (walk left) and #3 (walk right) for me. You give them animation identifiers for your monster (1 and 2, resp.)From that, you can define states walk left and walk right. Each state defines an animation being played and a behaviour. The combination of using walker and selfmove means that DumBlador will move forward at constant speed, according to what's defined in the animation, but not faster than the value defined in its internal variable v0 (x speed)"walker" is what's called a controller for the GOB. It can also report events and indicate when it failed to perform the desired movement. The two on fail statements indicate transitions from "walk left" to "walk right" and back when it's no longer possible to move forward. That could be due to a wall or the end of a platform. With this simple script, dumblador "has no way to figure out". Another part of the current behaviour is that dumblador turns back when Bilou jumps on his "head". This is achieved by the two on hit statements. It's still necessary to provide the (relative) coordinates of the hitboxes manually. Here the "hit" statement corresponds to a passive area in the state definition, which is seen in dark cyan in the Inspector widget. "000A" is the bit mask that corresponds to Bilou's stomping action or AppleAssault's attacks. I could have used "0002" to make DumBlador impervious to punch attacks and reacts only to stomps.Finally, the curious (100 ~ :0) are GobExpressions. It's a minimalist encoding of "set var[0] to -100". It works as those RPN calculators, where you type "2 40 +" to compute "40 + 2". Only simple parts are used here: push the constant 100, negate it (I don't have negative constants so far ^^") and assign it to variable 0 (mnemonic: Pascal uses := for assignments). Reusing a constant here is required as the walker controller is allowed to alter the speed in the final steps towards the wall.Would you like to give it a try yourself ? [Less]

Okay, let's keep tools-fusion for later on and focus on the impending walk of Dumbladors. I had them stepping blindly yesterday, and now, I'm trying to use the "walker" controllers (the one that can follow slopes and so on) to control them, so that ... [More] they can be placed like Applemen rather than suffering woodworm-like bugs.I had some more "FLITS" bugs, with dumbladors disappearing into the void of the toroïdal space (?) as soon as they hit a wall 0_oThe good news is that InspectorWidget was already much more capable than I thought, despite its cryptic user interface:(1) touch here to set a "breakpoint on bounding-box intersection(2) once a monster appears, click its "name" (2 first letters of BLador.cmd plus current state number) to give it the inspector focus.(3) click the coordinates of one monster to "disable" it from execution (or resume its execution).(4) click the focused gob's "name" bar to switch between iGobControllers display or cdata (GOB's private variable used in GobScript) display.(5) touch "p*" or "a*" to enable the rendering of collision areas.press L to step to the next frame (slow-motion) or L+START to resume normal play (with breakpoints active).After fixing the "silly sunday bug" (giving a positive v0 speed for a state that moves to the left :P), I think I identified the reason why blador disappears: the "deficit" for step-based walk increases by v0 at every frame, but I also have "delay xxx" instructions in my animation, which makes the GOB to accumulate deficit move over time. When it comes to turn around, it is first "wrapped" to the place it's supposed to be (not very ideal)... and that happened to be off-screen this time ^^" [Less]

The more I use AnimEDS for the Bilou project, the more it becomes obvious: I will have to merge SEDS and AnimEDS into a single program, so that one can easily touch up or re-center sprites used in animations, or easily preview the new sprites on the ... [More] defined animation. Easing the switching between the two tools will not do it. Integration is really what's needed.This post will collect thoughts and battle plan for this huge refactoring attempt ... I won't get into it before I have a first school zone demo running.SEDSAnimEDS* drop the dumb 'animation editor'* leftTable could be dropped between two "restore()" of the fileWindow* make onion skin possible, but keep OAMs for the rightTableJusqu'ici, avoir AnimEDS et Sprite Editor dans 2 exécutables séparés était plutôt bénéfique. Je pouvais complètement foirer une "release" AnimEDS sans pour autant perdre la possibilité d'éditer des p'tits sprites sur ma DS (ou pire, de corrompre les fichiers .spr). Mais à l'usage, il est clair que devoir basculer d'un programme à l'autre est fréquent pour avoir une animation correcte. Rien que sur Dumblador (pourtant élémentarissime), j'ai du faire des va-et-vients pour re-centrer les pieds, histoire que l'animation passe sans heurts. Alors commencer une animation avec des boules en guise de pieds et mains puis "affiner" en redessinant quelque-chose de plus rayman-esque ... je n'ose même pas imaginer 0_oJe vais donc devoir fusionner les deux ensembles de "fenêtres" dans un seul et même programme, ce qui va nécessiter un fameux effort de mise à plat du code (UML? ô UML, pourquoi es-tu UML?) histoire de garder un état cohérent entre les "feuilles de travail" pour les sprites.Je pense que ce sera pour les grandes vacances, dès que j'ai une démo du niveau "school zone" qui est partie sur dev-fr.org.(PS: ce post est en "brouillon" sur le blog depuis septembre 2011 ...) [Less]

Wow. I had no idea it would go so fast! Less than 24 hours after the proper alignment of dumblador on screen, I can now have it walking around in a level. Many things remain, such as making it detect edges and turn around, just like applemen and ... [More] woodworms. That will be a next level. Here's the updated AnimEDS for download, although I'm pretty sure it needs more feedback hints before it becomes user-friendly.Eh bin !? ça n'aura pas trainé. Je sentais bien que je n'étais pas loin de "dumblador qui avance", mais de là à deviner qu'en une soirée, ce serait réglé dans AnimEDS et qu'avec juste 2 heures de plus dessus ce matin (dont un peu d'ajustement de sprites), je pourrai le faire avancer aussi dans le moteur de jeu ... C'est pourtant le cas. Chouette. Je vais pouvoir commencer à ajouter la définition des zones de collisions entre sprites ... ou alors je garde ça pour un programme annexe encore un moment ? [Less]

Bon, on récapète.3 mars: fusion du code expérimental pour les nouveaux sprites composites dans le moteur de jeu. Il faudra quand-même pas mal chipoter pour pouvoir éditer la school zone dans LEDS18 mars, le fichier de commande pour dumblador est ... [More] écrit. C'est lui qui servira de démonstration des nouvelles capacités du moteur de jeu, mais rien à l'écran ne trahit encore la présence de dumblador :P24 mars, release source du moteur de jeu et de ses outils.26 mars, "reality check": pour pouvoir positionner Dumblador dans un niveau, he dois faire une révision d'AnimEDS pour qu'il enregistre la miniature à afficher;25 avril, je peux ajouter des dumbladors qui font quelques pas (sur-place) mais il me manque des outils pour définir quelle portion de l'espace ils occupent dans le jeu.7 mai, comme d'habitude, j'ai zappé la case 'feedback à l'utilisateur' et mes outils sont à la limite de l'utilisable.15 mai; ok. Je peux enfin positionner de manière fiable un dumblador dans mon niveauLà, j'ai AnimEDS, LEDS et le moteur de jeu qui sont d'accord sur la manière d'interpréter la position d'un personnage composite dans un niveau. Ça n'aura pas été sans mal.Well, it's a milestone: I can precisely place compound GOBs in a level. Neat. Now, if you don't mind, I won't translate all the tracking and focus on the impeding future: defining moves of the compound GOB in AnimEDS as well ... and then have them walking :) A few weird things occured with this dumblador development, which should sound "normal" to any game developer: a monster that cannot be seen but hurts you nonetheless, or that can be seen at position A while it hurts and can be bop'ed on at position B ... and also a monster that "walks" without leaving position A and suddenly appears at position C when his "step" movement is done (distance between A and C being totally impossible to predict from the observation of the movement).No need to say that in some parallel universe, dumbladors seems to have super-natural powers that make Bilou's job quite more complex. According to Bouli, that'd be because they're following elliptic curves, but on a toroïdal and discrete space...J'ai même le début de la définition des déplacement, quoi que ce soit encore très "courbes elliptiques en espace discret toroïdal", si vous voyez ce que Bouli veut dire ... non ? bon, bin Dumblador reste sur place pendant presque toute l'animation, puis arrive d'un coup à une position improbable qui n'a pas grand-chose en commun avec le déplacement qui était prévu, donc:faire en sorte d'avoir en mode émulateur (sur toutes mes machines) une animation de déplacement, histoire d'éviter de re-faire l'animation à chaque test;éliminer les effets du type "la position de la tête n'est remise à jour que si la tête est déplacée (relativement) dans l'animation.garantir que l'info du type "verouillé sur le membre #3" est maintenue à jour quand on se déplace le long de la timeline.trouver le bug.Faire en sorte que les repères de positions dans LEDS restent corrects quand on se déplace dans le niveau ^^" [Less]