Sprite Editor on the DS: the SEDS approach.

Let's advertised it a bit: i've started a sourceforge project for the game development tools for the DS.
To many aspects, SEDS philosophy is quite different from the other sprite editors i've shown you in my previous post.

First of all, it is not using bitmap rendering. I oriented most of the rendering techniques towards tiles-oriented rendering that is so specific to console hardware. This is mostly possible thanks to the huge amount of individual tiles available on the DS.

As an example, the grid where you draw your pixels is actually made of tiles, that is, each individual pixel you paint is a 8x8 character that is programmed to be a 8x8 square of a single color. Same goes for the grid lines and the palette on the left. I also integrated various test of DS features in the editor, such as the ability of modifying the grid lines' opacitiy (through up and down arrow), thanks to the fact that widgets are rendered on a separate layer than background and your colored artwork.

Another great feature it enables is fast rendering at any zoom level. So far, the grid is rendered 1:1, but i have already tested a 32x32 grid with smaller pixels (which wasn't working as expected probably due to DMA problems). I could even potentially use 24x24 grid (scaling 8x8 tiles to 6x6 to keep the same area occupied) by just reprogramming two registers. Welcome to 2D hardware acceleration goodness ^_^.

J'ai enfin uploadé mes démos et sources sur mon projet "dsgametools" sur sourceforge. Entre-autres, SEDS, l'éditeur de sprites pas comme les autres, qui s'appuie principalement sur le hardware 2D de la console pour accélérer le rendu de la grille, etc. Le niveau de transparence de la grille, le zoom plus ou moins fort sur la zone de travail, autant de petits tests des possibilités de la bête... Ca demande un peu plus de boulot et de debugging que d'utiliser une bibliothèque de widgets sur un framebuffer, mais le projet gagne en intérêt ^_^

Bon, les sources ne sont pas encore génialement belles (je débute en C++, quoi qu'on puisse en penser), mais c'est assez fun d'utiliser pour ce genre de projet les techniques de développement OO, l'UML et tout ...

/* reprogramming the background layer 3 (colored artwork)
* so that it is 50% zoomed and still appear at (xbase,ybase)
*/
SUB_BG3_CX = (-xbase*2) <<8;
SUB_BG3_CY = (-ybase*2) <<8;
SUB_BG3_XDX = 2 << 8;
SUB_BG3_XDY = 0; /** XDY and YDX useless in that case. **/
SUB_BG3_YDX = 0; /** see TONC tutorial if they puzzle you **/
SUB_BG3_YDY = 2 << 8;

Feel free to download the demo or browse CVS sources.

Well, I'm not very proud of the sources. I'm still learning C++ and certainly haven't a good style atm. Plus, most of the code depends of libraries i've hacked for proper interoperations (such as the libnds that integrates anti-stylush-jumping code from PadrinatoR)
In other words, expect hard time if you try to compile the projects from its sources right now. I'll publish the modified libraries in the project too ... when i'll find time for this :P

And yes, the development of the editor is somehow freezing these last days, because i have met a point where data storage and organisation need to be refactored. And my thesis do not let me allocate sufficiently large time slices to do things like that ... so i'm just writing small perl scripts for converting old .SPR files to the new (anticipated) format -- which gets highly IFF-inspired if you ask :P