smoove Nintendo DS Development

I will attend the Evoke 2007 where you can have hands on and ask me million questions on Smoove. For your convenience I also release here an very, very early release, that is in parts functional.

Controls are:
D-Pad Down - Change modes: Edit tiles or zoom picture

Zoom Picture mode
Stylus - Select region
A B X Y - Select size of zoomed tiles

Edit tiles mode
Stylus_On_Press - Get Pixel
Stylus_On_Release - Set Pixel
Hold D-Pad up and Stylus - Constantly draw pixels
(I decided for this usability due to low precision of the Stylus)

Hold D-Pad Right - Select color
Note that the transparent color 0 is shown with an X.

Download:
Smoove pre-alpha .nds .ds.gba

In the last weeks the smoove development struck a little bit. I was struggeling with libfat and DLDI to get the filesystem running on my beloved DS. This task has a lot of priority to this projects, because what is the use of the most beautiful tool if you can’t save your results?

What’s the use of tools without the ability to read and write?

Unfortunately I have big issues getting the reading and writing tasks done, there are jams with getting libfat run on my M3 SD lite card (together with PAlib). Please refer to the following threads on the forums to dig deeper into the problem. It seems that I’m the very only one who has this problem: PAlib Forum 1, GBADEV Forum 1, PAlib Forum 2.

I successfully compiled a DLDI read and write test (refer to the thread in the GBADEV-Forum above) but with some minor errors. I patched the original build files with DLDI m3 and m3alt. Both tests pass perfectly. When I compile it by myself I get two errors. First patching with m3alt DLDI did not work. Second the filed patched with DLDI m3 failes at the “backward reading test”. Writing of textfiles works, but when reading it, some strange foreign chars are added which are only visible when reading through the DS. Compiling the source after including PA_Init() does, but the fatDefaultInit() from libfat fails on the DS. More details on this here: PAlib Forum 3.

This make me guess that the error is at least somehow connected to the makefile. At the moment I spend the time thinking. Should I drop PAlib and build upon the working example? There is still this bad feeling, because on my own compiled version there are still minor errors. Building upon buggy versions is risky, you can run into troubles again suddenly.

I think it would be far more better to spend the time getting more into makefiles and NDS related hareware stuff. I attached the makefiles, maybe someone got a good idea. Feel free to comment. Btw: I use the latest devkitpro r20 with Notepad++ and the latest PAlib 070717.

The Makefiles
The Makefile that came with the test didn’t do anything right. It just gave me errors. The try to just compile the stuff in the arm9-folder resulted in a .elf file. What do I with such a file?

This version is derived from PAlib and compiles successfully, but executes the libfat (after patching) with some slight errors (read above). It is the same I use with compiling with the include and init of PAlib, which gives me an FAT Init error on the DS.

Useful, very useful. It’s a shame that I didn’t found this tutorials earlier. They explain very clear what the Nintendo DS 2D video hardware is all about.

http://liranuna.drunkencoders.com/nds-2d-tuts/

I did some work on the editor again. Some small fixtures and optimizing work. What I have now is a direct edit of the tilebuffers and an according tilemap that maps the 8×8 pixel on the screen. It is somehow an indirect way of getting tha data directly in the videoram. I use arrays as buffers and flip them into the VRAM using PA_LoadSimpleBg in the main-loop. This is straightforward, but not memory optimized. I could also write directly into the videomemory using DMAcopy. At least this approach works and the DS is at performance now.

I will first add more features before solving this issue, unless other performance problems occur. So far I made a personal list of requirement in a next steps-list.

__next steps:
debug editTile
undo-function
palette select, colorpicker and fill
menu
control 2 layers
add third layers with sprites that form the menu
PAFS
solve the problem of 8×8 vs. 16×16 editing of pixel
color editing
add style
add sounds
optimize: DMAcopy vs. buffer-based

__then:
tile editor
parallax scrolling
thinking of sprite editor and more different formats

Good old libnds wisdom. I looked up an old project and saw, that you can very easy use libnds for having a simple “console” in the upper screen. Simply use code like this:
consoleDemoInit();
printf("i: %i \n", i );


The other way around is something like that. It also works at 8- and 16bit drawing modes and are somehow highly customizable. Basically it converts a number into a string.


// first of all you must include the standart io from the c-lib
#include <stdio.h>
// init an char-array
char string[32];
// convert variable into string (the char array) using sprintf
sprintf(string, “%i”, i);
// finally draw text (8- and 16-bit mode)
PA_CenterSmartText (0, 200, 8, 256, 32, string, 2, 3, 1);
// (or other modes using i.e.)
PA_InitText (0, 1);
PA_OutputSimpleText (0, 1, 1, string);


Okay, first steos, first result, but I throw away this approach for different reason.

I will need much more both C and Nintendo DS skills (closer to the hardware) to finish this. I will get there, but I figured our something more important: I want something really different for Smoove DS, including the ability to edit and animate sprited, build maps and work on layers. To do so I will again dig deep into PAlib to get things done.

Oldschool colorsorting from top to bottom!

Maybe I on some day will again follow the approach of a “fullscreen” pixeleditor again, but right at the moment (it’s still at the beginning, eh?) I do the tile, map and spriteeditor.

Here you can have both the binaries and the source. Feel free to use this code for learning, enhancing skills, branch or build upon.

smoove_first_(but_uncontinued)_approach.zip

Use the stylus to draw or pick color. L and R keys toggel between zoom and draw or palette and draw/zoom. Up/down keys modify pixelsize and zoom level.

I am really stuggeling with the question of using 8-bit vs. 16-bit bitmaps. At least using 256 colors in 8-bit mode should be really enought to do inspirational artwork, since a complete gaming and grafic era was build on this technique. The advantage of this way of implementaion would be clear in haveing more free memory to implement fun features. At the moment I definitely tent to 8-bit.

Hola!

The zoom function works, but is slow as hell. The approach is very basic and unoptimized. The function gets the pixel from the top screen and renders it zoomed to the bottom screen. The “drawZoomPixel” function renders the “Pixel” in vertical lines in the height of the pixelsize. So for every frame the whole bitmap on the lower screen is written pixelwise. Indeed straightforward, but unoptimized. Time to throw away code. Essentially a good habit.

There are two other issues I am struggeling with:

- Dualis (not the lastest Version) crashes on loading an 8bit Bitmap. Maybe getting the hottest release will fix that. iDeaS did the work.

- I got annoying errors when tring to write for (int i=0; i <= whatever; i++), that’s why there is that strange 2 line workaround, look the screenshot above. Any comments upon that are appreciated. The error from the compiler for the above approach is: “declaration used outside C99 mode”

UPDATE: I did a test. The function is slow, but the DS Hardware got it smoovely running until you reach a zooming level near the original size.

Huh? PSP?

Big thanks to Jason. I am now hosted by Drunkencoders! This will be an ongoing development blog of my takeover into DS homebrew community. In other words: I did a pixel and animationeditor on the Sony PSP called Smoove. But since the DS is far more superior in style, technique and at least the community it’s time to port every thing on the DS and move on towards new things.

I will do the SmooveDS in the PA-Lib and right now figure out some Bitmap-Tasks. Console near programming is a very task of its own, since the SmoovePSP I did in Lua. More updates to come. I will also strap this WordPress theme a little… Have Fun.