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.
| SEDS | AnimEDS |
|---|---|
| * drop the dumb 'animation editor' * leftTable could be dropped between two "restore()" of the fileWindow | * make onion skin possible, but keep OAMs for the rightTable * solve the memory management bug. |
Jusqu'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_o
Je 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 ...)
- + 
Vote for your favourite post
2 comments:
Un élément de plus en faveur de la fusion: contrairement à LEDS, AnimEDS manipule lui aussi le fichier .spr
Conserver deux outils différents, c'est prendre le risque qu'ils n'aient pas tous les 2 été mis à jour simultanément, avec potentiellement des pertes de données à la clé.
Par contre, le "multi-palette" va sérieusement compliquer les choses, vu qu'il est désactivé dans SEDS et activé dans LEDS.
Post a Comment