I've been trying to write my own sprite management code as a sort of exercise in C++ as well as the DS. I was having trouble getting things displayed correctly and thrashed back and forth changing one thing and then another, writing directly to memory rather than using DMA, etc. etc. etc. trying to figure out what was wrong. I'm a pretty careless programmer, so I assumed that it was either my mistake or the result of developing on an only partially documented system. Not having figured out a good way to do debugging obviously doesn't help either.
And, I finally figured it out. It was in code I wasn't even looking at; apparently I was trying to do something the system hadn't been initialized to do.
You can pass a number of flags to videoSetMode() when you are initializing the display, and apparently DISPLAY_SPR_1D_BMP is necessary in order to display 16-bit, non-palettized sprites. It seems obvious given that the ATTR0_BMP flag must be set in the sprite's OAM entry, but I didn't even know I should be looking for it.
Further, apparently you can't mix ATTR0_BMP and non-BMP sprites. At least, I can't get both to display at the same time. Perhaps I need another flag....
Showing posts with label nds. Show all posts
Showing posts with label nds. Show all posts
2006/10/05
2006/09/27
Sprites, Tiles and Their Unholy Union in Sprite Memory
There are several demos both packaged with devkitpro and in various tutorials that use sprites, but they almost all involve drawing one sprite (possibly multiple times) on screen. As I started trying to add to the demos, I found that I was having trouble drawing more than two sprites.
Several examples setup sprite OAM (Object Attribute Memory) as follows:
ATTR0_COLOR_16 specifies 16 color mode, ATTR0_SQUARE says the sprite is square (heigth = width), ATTR1_SIZE_16 makes the sprite 16x16.
And then sprite data is written like:
This just fills the entire sprite area with whatever color is defined at index 2 of the palette.
What was confusing me was the representation of sprites as tiles, how they are stored in sprite memory, the allocation of sprite IDs, and the way that sprite OAM uses sprite memory. If you are unclear on the meaning of tiles, check out Patater's tutorial.
Basically, tiles are 8 pixel by 8 pixel images, and all sprites are made up of them. What's important to understand here is that the sprite IDs reference the location of tiles in memory. If a sprite is larger than 8x8 then it uses more than one tile and covers a range of tile/sprite IDs. This means that two 16x16 sprites (each 4 tiles) stored in adjacent memory can't be allocated ID 0 and ID 1. The two images will overlap since the 16x16 sprite at ID 0 is defined as tiles 0 to 3, and the 16x16 sprite at ID 1 is defined as tiles 1 to 4.
You have to keep in mind the size of one pixel in memory and the dimensions of the sprite both when storing pixel data in sprite memory, and when allocating sprite IDs in sprite OAM.
In the example above (two 16-color 16x16 sprites):
NOTE: In the code above I offset by 64 rather than 128 because we are using word-aligned (16 bit) rather than byte-aligned (8 bit) addressing since SPRITE_GFX is an array of 16-bit values.
Several examples setup sprite OAM (Object Attribute Memory) as follows:
int spriteID = 0; // the sprite id
int spriteX = 0; // X position
int spriteY = 0; // Y position
sprites[0].attribute[0] = ATTR0_COLOR_16 | ATTR0_SQUARE | spriteX;
sprites[0].attribute[1] = ATTR1_SIZE_16 | spriteY;
sprites[0].attribute[2] = spriteID;
ATTR0_COLOR_16 specifies 16 color mode, ATTR0_SQUARE says the sprite is square (heigth = width), ATTR1_SIZE_16 makes the sprite 16x16.
And then sprite data is written like:
/* size of sprite in words (word is 16 bits) = 16 * 16 / 4
* 16-color mode = 4 bits per pixel (2 pixels per byte, or 4 per word)
* 16 pixel by 16 pixel sprite, 4 pixels per word = 16 * 16 / 4 bytes
*/
int size = 64;
int pali = 2; // Palette index
for( int i = 0; i < size; i++ ){
SPRITE_GFX[ spriteID * size + i] = (pali << 12) | (pali << 8) | (pali << 4) | pali;
}
This just fills the entire sprite area with whatever color is defined at index 2 of the palette.
What was confusing me was the representation of sprites as tiles, how they are stored in sprite memory, the allocation of sprite IDs, and the way that sprite OAM uses sprite memory. If you are unclear on the meaning of tiles, check out Patater's tutorial.
Basically, tiles are 8 pixel by 8 pixel images, and all sprites are made up of them. What's important to understand here is that the sprite IDs reference the location of tiles in memory. If a sprite is larger than 8x8 then it uses more than one tile and covers a range of tile/sprite IDs. This means that two 16x16 sprites (each 4 tiles) stored in adjacent memory can't be allocated ID 0 and ID 1. The two images will overlap since the 16x16 sprite at ID 0 is defined as tiles 0 to 3, and the 16x16 sprite at ID 1 is defined as tiles 1 to 4.
You have to keep in mind the size of one pixel in memory and the dimensions of the sprite both when storing pixel data in sprite memory, and when allocating sprite IDs in sprite OAM.
In the example above (two 16-color 16x16 sprites):
- The first sprite is assigned ID 0 (8x8 tiles 0 to 3) and is stored in 128 bytes (16pix * 16pix / 2 pixels-per-byte) of sprite memory starting at index 0.
- The second sprite should be assigned ID 4 (8x8 tiles 4 to 7) and is stored in 128 bytes of sprite memory starting at index 128 + 1 (right after the first sprite).
NOTE: In the code above I offset by 64 rather than 128 because we are using word-aligned (16 bit) rather than byte-aligned (8 bit) addressing since SPRITE_GFX is an array of 16-bit values.
2006/09/15
PassMes, M3s, and GBAMPs, oh my!
Odds are, if you've been interested in running homebrew code on the Nintendo DS, you were probably more than a little lost/confused initially (if you ever got it figured out). There *is* an active community out there, but most of the information is spread out across different bulletin boards, in different threads, often containing more than a little incorrect and/or outdated information, and using terminology/abbreviations you're probably not yet familiar with. Maybe I'm just the kind of person that really likes to have a good grasp of what I'm doing and what all my options are rather than running with "just do X" as posted by some_random_guy023.
Far and away the best write up I've come across is the Running Homebrew wiki entry at DSLinux. It does a nice job of presenting the various requirements and what your options are, the between them such as in which circumstances you can use them and what the pros/cons are, as well as providing links (via Pocketheaven) to specific products/manufacturers.
Check it out and save yourself a lot of headache/irritation.
Far and away the best write up I've come across is the Running Homebrew wiki entry at DSLinux. It does a nice job of presenting the various requirements and what your options are, the between them such as in which circumstances you can use them and what the pros/cons are, as well as providing links (via Pocketheaven) to specific products/manufacturers.
Check it out and save yourself a lot of headache/irritation.
2006/09/04
DevKitPro Templated Build Directories
One thing worth mentioning that's part of the DevKitPro is the "templated" build directories for Nintendo DS projects. I figured I'd give them a brief explanation since they're kind of unique to DKP.
You'll find them in [DevKitPro root dir]/examples/nds/templates/.
There should be two sub-directories:
arm9/ is the simpler of the two, but is for projects that only require an arm9 executable. combined/ is a bit more complicated but allows for easily creating programs that use both the arm7 and arm9.
I'll only talk about the combined/ directory because you can limit yourself to the arm9/ sub-directory if all you want to do is mess around with the arm9, AND you can continue using the same template you've gotten used to as you move on to more complex projects and actually need both processors. In any case, most things apply to both templates in one way or another, it's just that in the case of combined/ it may be found in a subdirectory.
First, what I did was copy the combined/ directory to a location where I can easily find it when doing DS programming. I then renamed it "template", but you can call it whatever you want. The basic idea is to be able to just make a copy and rename it for each project you want to start, and you'll have a nice build environment ready to go.
Next, I made some changes to the default template because there's some unnecessary junk there (afaic):
If you don't use Programmer's Notepad you can safely delete template.pnproj, template.pnps, and template.prj.
I honestly have no idea why this is included with DKP. Maybe they own stock in it or something.
Next, you're going to want to do a "make clean". At the time of this writing the template directories are being distributed already built. This can cause problems for you during the linking phase of your project if your directory structure isn't setup just like the developers:
Edit arm9/'s Makefile from this:
To this:
Your template build directory is ready to go!
Creating new projects is as simple as:
Change to the [root] directory, run "make" to build everything, and you should have a nice *.nds file waiting for you to debug. =)
You'll find them in [DevKitPro root dir]/examples/nds/templates/.
There should be two sub-directories:
- arm9/
- combined/
arm9/ is the simpler of the two, but is for projects that only require an arm9 executable. combined/ is a bit more complicated but allows for easily creating programs that use both the arm7 and arm9.
I'll only talk about the combined/ directory because you can limit yourself to the arm9/ sub-directory if all you want to do is mess around with the arm9, AND you can continue using the same template you've gotten used to as you move on to more complex projects and actually need both processors. In any case, most things apply to both templates in one way or another, it's just that in the case of combined/ it may be found in a subdirectory.
Template Prep
First, what I did was copy the combined/ directory to a location where I can easily find it when doing DS programming. I then renamed it "template", but you can call it whatever you want. The basic idea is to be able to just make a copy and rename it for each project you want to start, and you'll have a nice build environment ready to go.
Next, I made some changes to the default template because there's some unnecessary junk there (afaic):
If you don't use Programmer's Notepad you can safely delete template.pnproj, template.pnps, and template.prj.
cd [template directory]
rm template.*
I honestly have no idea why this is included with DKP. Maybe they own stock in it or something.
Next, you're going to want to do a "make clean". At the time of this writing the template directories are being distributed already built. This can cause problems for you during the linking phase of your project if your directory structure isn't setup just like the developers:
make cleanNow create a "data" subdirectory in the arm7/ and/or arm9/ subdirectories and add them to the relevant Makefile's list of subdirectories:
# For arm9/
cd arm9
mkdir data
Edit arm9/'s Makefile from this:
BUILD := build
SOURCES := source
INCLUDES := include
DATA :=
To this:
BUILD := build
SOURCES := source
INCLUDES := include
DATA := data # Or whatever you called the subdirectory you created
Your template build directory is ready to go!
Template Usage
Creating new projects is as simple as:
- Copying your template directory
- Renaming it something that fits your project
- Adding files as shown below
[root]/
+- arm9/
+- source/ ; Put all source files (*.c, *.cpp, etc.) here
+- data/ ; Binary files (*.bin) go here
+- build/ ; Project will be built here. Also, *_bin.h files generated
; for your *.bin files will end up here.
+- arm7/ ; Basically same as arm9/ directory
Change to the [root] directory, run "make" to build everything, and you should have a nice *.nds file waiting for you to debug. =)
2006/09/03
Mapping touch-screen input to pixel values on the DS
Finally got some school stuff out of the way so I can get back to the important things in life.... like the Nintendo DS.
Been messing around with touch-screen input a bit. It was fairly easy to get a demo running, but when I started trying to drag something around I found out that the touch screen uses a different coordinate system from the display. Dug around a little bit and came up with:
at NDSTech Wiki. The needed calibration values don't seem to be in ndslib so I think you need to define them yourself. Took around a minute of messing around to get a nice demo working where you could drag something around on screen just like you'd expect.
Something I did in my code that's worth pointing out is changing the calculations a bit to get rid of any extra operations (especially the division). Granted, I'm not sure how much the compiler can take care of, but it probably doesn't hurt.
First, if you separate the
Second, you can trade out the arbitrary divide for a shift by preforming the divide ahead of time and shifting the result to avoid using floating point. Then undoing the shift whenever you use the value. The numbers are small enough that you shouldn't have to worry about overflow when multiplying with a larger number... I think. i.e.
Gotta look into compiler optimizations and figure out whether the above is worth the trouble if you specify -O2, etc.
Been messing around with touch-screen input a bit. It was fairly easy to get a demo running, but when I started trying to drag something around I found out that the touch screen uses a different coordinate system from the display. Dug around a little bit and came up with:
#define SCREEN_WIDTH 256
#define SCREEN_HEIGHT 192
// those are pixel positions of the two points you click
// when calibrating
#define TOUCH_CNTRL_X1 (*(vu8*)0x027FFCDC)
#define TOUCH_CNTRL_Y1 (*(vu8*)0x027FFCDD)
#define TOUCH_CNTRL_X2 (*(vu8*)0x027FFCE2)
#define TOUCH_CNTRL_Y2 (*(vu8*)0x027FFCE3)
// those are the corresponding touchscreen values:
#define TOUCH_CAL_X1 (*(vu16*)0x027FFCD8)
#define TOUCH_CAL_Y1 (*(vu16*)0x027FFCDA)
#define TOUCH_CAL_X2 (*(vu16*)0x027FFCDE)
#define TOUCH_CAL_Y2 (*(vu16*)0x027FFCE0)
// linear mapping can be used to go from touchscreen position to
// pixel position
// precalculate some values
static int16 TOUCH_WIDTH = TOUCH_CAL_X2 - TOUCH_CAL_X1;
static int16 TOUCH_HEIGHT = TOUCH_CAL_Y2 - TOUCH_CAL_Y1;
static int16 CNTRL_WIDTH = TOUCH_CNTRL_X2 - TOUCH_CNTRL_X1;
static int16 CNTRL_HEIGHT = TOUCH_CNTRL_Y2 - TOUCH_CNTRL_Y1;
// reading pixel position:
int16 x = (IPC->touchX - (int16) TOUCH_CAL_X1)
* CNTRL_WIDTH / TOUCH_WIDTH + (int16) TOUCH_CNTRL_X1;
int16 y = (IPC->touchY - (int16) TOUCH_CAL_Y1)
* CNTRL_HEIGHT / TOUCH_HEIGHT + (int16) TOUCH_CNTRL_Y1;
at NDSTech Wiki. The needed calibration values don't seem to be in ndslib so I think you need to define them yourself. Took around a minute of messing around to get a nice demo working where you could drag something around on screen just like you'd expect.
Something I did in my code that's worth pointing out is changing the calculations a bit to get rid of any extra operations (especially the division). Granted, I'm not sure how much the compiler can take care of, but it probably doesn't hurt.
First, if you separate the
IPC->touchX - (int16) TOUCH_CAL_X1terms, the entire TOUCH_CAL_X1 component only needs to be calculated once.
Second, you can trade out the arbitrary divide for a shift by preforming the divide ahead of time and shifting the result to avoid using floating point. Then undoing the shift whenever you use the value. The numbers are small enough that you shouldn't have to worry about overflow when multiplying with a larger number... I think. i.e.
#define SHIFT 4
static u16 scale_value = (CNTRL_WIDTH << SHIFT) / TOUCH_WIDTH;
...
(IPC->touchX * scale_value) >> SHIFT ...
Gotta look into compiler optimizations and figure out whether the above is worth the trouble if you specify -O2, etc.
2006/08/25
Linking DS Code to Binary Image Data
Having to deal with sprite/texture/background data is a pretty common task in DS programming. The best way to do it is to strip any sort of header information and undo compression that is part of many graphics formats so you can just link the binary data along with your code. The problem is you have to know how to do this.
It looks like a lot of people convert the image to a header file and then #include it in their code. For small demos this really isn't a big deal, but it's kind of bad once you go beyond loading a single image. Why? Since the data is included by the pre-processor you have to recompile it along with your code EVERY time you make a change.
I figured out the tools well enough to get around this so I thought I'd share two different ways of doing this. Anyway, the two methods are:
The end result is essentially the same, the process is just a little different.
Both require a program call gfx2gba from gbadev.org (NOTE: There are two versions of gfx2gba around, but you want v0.13. v1.03 is a similar but different program from a different author. I'm pretty sure you could use it I just won't talk about it here). This program can read various graphics file formats and extract the image data from them in various ways and seems to be an indespensible part of both GBA and DS development (yes, despite its name it is also useful in DS development because the two platforms have several similarities).
Now when you run "make" it will compile the image data source files once and then you won't have to compile them again. The compiled image data will be linked into the executatable (don't forget to tell the linker about them if necessary).
Personally, I don't really like this method because it requires some manual work. I like things to be as automated as possible so I don't screw something up when I forget to do some manual step. For this reason I prefer the second method.
I've shown you 2 different approaches to getting away from header file #include'd data and moving to more professional linking of binary files. I prefer the latter method as it can be pretty much completely automated, but which method you use will largely depend on your needs.
This is not to say these are the only two methods, mind you. While trying to figure this all out I saw references to some program named "katie" and another called "bin2c" ("binary to C" I would assume) that sounded like they could likewise be used. I'll leave that to you. Also, I'm willing to bet that there's a plugin for The Gimp or some other graphics program that will do all of this.
It looks like a lot of people convert the image to a header file and then #include it in their code. For small demos this really isn't a big deal, but it's kind of bad once you go beyond loading a single image. Why? Since the data is included by the pre-processor you have to recompile it along with your code EVERY time you make a change.
I figured out the tools well enough to get around this so I thought I'd share two different ways of doing this. Anyway, the two methods are:
The end result is essentially the same, the process is just a little different.
Both require a program call gfx2gba from gbadev.org (NOTE: There are two versions of gfx2gba around, but you want v0.13. v1.03 is a similar but different program from a different author. I'm pretty sure you could use it I just won't talk about it here). This program can read various graphics file formats and extract the image data from them in various ways and seems to be an indespensible part of both GBA and DS development (yes, despite its name it is also useful in DS development because the two platforms have several similarities).
Image->Source->Binary
- Use gfx2gba to convert your image (bmp/pcx/tga/...) to a C source file. I will assume your image file is called image.bmp.
gfx2gba -t8 -f src -o arm9/source image.bmp
This converts image.bmp into a master.pal.c file containing the palette information and a image.raw.c file containing the image data arranged as 8x8 tiles. This would be used for sprites. For backgrounds you don't want tiling so you leave off "-t8".
"-f src" specifies that the output type will be source (C) files.
"-o arm9/source" specifies the output directory that the *.c files will be placed it. Set this to your source directory.
gfx2gba has several other options so be sure to try running it without arguments or looking at the readme.txt file. - Next, you want to make sure that this image data will be compiled as part of your build process (when you type "make"). You will either have to add it if you are using a custom Makefile, or place it in a directory that is searched for *.c files.
- Finally, you have to make the data accessible from your program. This is done by adding a declaration to your code so the compiler will let you use the arrays in the external object files. You will have a palette array called master_Palette in master.pal.c and an image array called image_Bitmap in image.raw.c. Putting the following code somewhere in your program source code will allow you to use them:
extern const unsigned char image_Bitmap[];
extern const unsigned short master_Palette[];
Unfortunately, there doesn't seem to be a way to determine the size of the arrays at compile-time when you use this method. sizeof() gave me an error since they are arrays of unspecified size. You either have to include the dimension of the arrays from the generated source files:
extern const unsigned char image_Bitmap[4096]; // Or whatever the size is
extern const unsigned short master_Palette[256];
OR, declare additional variables that hold them:
unsigned int image_Bitmap_size = 4096; // Or whatever
unsigned int master_Palette_size = 256;
OR, add two other variables to the generated source files to store the size and then declare them as well:
/* Add to the end of image.raw.c */
const unsigned int image_Bitmap_size = sizeof( image_Bitmap );
/* Add to the end of master.pal.c */
const unsigned int master_Palette_size = sizeof( master_Palette );
/* In your program source code */
extern const unsigned int image_Bitmap_size;
extern const unsigned int master_Palette_size;
/* Don't forget the data array externs as well */
I prefer the latter method because it is the most automatic of the three. If you ever change the image files you will have to regenerate the source and re-add the lines, but they're quite short and you probably won't be changing the images often.
Now when you run "make" it will compile the image data source files once and then you won't have to compile them again. The compiled image data will be linked into the executatable (don't forget to tell the linker about them if necessary).
Personally, I don't really like this method because it requires some manual work. I like things to be as automated as possible so I don't screw something up when I forget to do some manual step. For this reason I prefer the second method.
Image->Binary
- First, extract the image data from the image file with gfx2gba (assuming an image file called image.bmp):
gfx2gba -f raw -t8 -St.bin -pmaster.bin image.bmp
Again, leave off "-t8" if you are working with a background rather than a sprite.
"-f raw" for binary output is the default.
"-St.bin" sets the extension of the image data to ".bin" instead of the default ".raw".
"-pmaster.bin" sets the palette filename to "master.bin" instead of the default ("master.pal"). There is a "-Sp" option to set the palette extension similar to "-St", but it doesn't seem to work.
This will generate two binary files: image.bin containing the image data, and master.bin containing the palette. - Next, you need to make these files linkable. This requires a bit of "magic" as it's hard to see how the example programs do this.
If you look at a Makefile for one of the example programs you will find the following rule way down at the bottom:
%.bin.o : %.bin
@echo $(notdir $<) @$(bin2o)
Basically, it takes *.bin files and trys to make them *.bin.o files by calling "bin2o". Now, if you look in devKitPro/devKitARM/base_rules (a file that gets included in all the Makefiles) you will find:
define bin2o
bin2s $< | $(AS) $(ARCH) -o $(@) echo "extern const u8" `(echo $(
What this basically does is convert a binary file to assembly language, assemble it so it can be linked to your program, then generates master_bin.h and image_bin.h files to be #include'd in your program source. They contain:
/* In master_bin.h */
extern const u8 master_bin_end[];
extern const u8 master_bin[];
extern const u32 master_bin_size;
/* In image_bin.h */
extern const u8 image_bin_end[];
extern const u8 image_bin[];
extern const u32 image_bin_size;
The extern's from the first method all nice and automagically declared for you.
I've shown you 2 different approaches to getting away from header file #include'd data and moving to more professional linking of binary files. I prefer the latter method as it can be pretty much completely automated, but which method you use will largely depend on your needs.
This is not to say these are the only two methods, mind you. While trying to figure this all out I saw references to some program named "katie" and another called "bin2c" ("binary to C" I would assume) that sounded like they could likewise be used. I'll leave that to you. Also, I'm willing to bet that there's a plugin for The Gimp or some other graphics program that will do all of this.
2006/08/24
My bad, DevKitPro devs! orz
It looks like I jumped the gun a bit in yesterday's post when I complained about the ease of learning to use DevKitPro (DKP).
Got some sleep and woke up a lot less grumpy today so I thought I'd give it another shot. This time with a clear head.
I came across the PataterSoft tutorial and in the process of messing around with it I ended up going back through the "examples" directory of DKP. And, I must say.... they're really well commented, fully explained, easily understood examples. Maybe that's why all the tutorials have fallen into states of disrepair; they're unneeded. You just pick the directory you want and learn about what's in there- it's kind of like "Choose Your Own Adventure".
Really didn't take much to get a few easy examples going. I retract all the nasty things I said earlier and instead tip my hat in their general direction.
Got some sleep and woke up a lot less grumpy today so I thought I'd give it another shot. This time with a clear head.
I came across the PataterSoft tutorial and in the process of messing around with it I ended up going back through the "examples" directory of DKP. And, I must say.... they're really well commented, fully explained, easily understood examples. Maybe that's why all the tutorials have fallen into states of disrepair; they're unneeded. You just pick the directory you want and learn about what's in there- it's kind of like "Choose Your Own Adventure".
Really didn't take much to get a few easy examples going. I retract all the nasty things I said earlier and instead tip my hat in their general direction.
Hmmm.... the API has changed, eh?
In general, DevKitPro is a pretty nice software package. GBA, PSP, and (most importantly) DS development libraries all in one place. They even have a fancy updating tool that will keep your libraries up to date and add new ones (they recently added dswifi).
Biggest problem? Documentation... of course. Unless there's some guys that are really dedicated to working on it, the documentation for every project generally seems to limp along coughing and wheezing behind the coders. And, DevKitPro is no exception.
Don't they have a Wiki? Well... kinda. But its out of order.
Doxygen? Well... kinda. But its pretty obviously not complete.
In case you're wondering, there doesn't seem to be any documentation in the software directory- save for the PSP.
For this reason, tutorials are nice just to avoid the frustration of figuring things out. If you check out any other DS dev-related sites: NDS Homebrew, Drunken Coders, PataterSoft, etc. They all tend to link to the same tutortials- all of which are either quite outdated or incomplete.
Far and away the best is PALib. This is assuming you want to use PALib, that is.
I was using the highly regarded double.co.nz tutorials. But, they no longer work. I haven't looked into it very deeply yet, but when I tried to compile the very short programs there were several errors. devKitARM (part of devKitPro) seems to have changed since the tutorials were last updated.
Most notably:
The first isn't really a bit deal. But it illustrates the a problem that may be more difficult to solve for a real beginner. I didn't really bother with it after than. I'll give it another go tonight when I get home.
Perhaps writing an up to date tutorial is something I should undertake. We'll see.
Biggest problem? Documentation... of course. Unless there's some guys that are really dedicated to working on it, the documentation for every project generally seems to limp along coughing and wheezing behind the coders. And, DevKitPro is no exception.
Don't they have a Wiki? Well... kinda. But its out of order.
Doxygen? Well... kinda. But its pretty obviously not complete.
In case you're wondering, there doesn't seem to be any documentation in the software directory- save for the PSP.
For this reason, tutorials are nice just to avoid the frustration of figuring things out. If you check out any other DS dev-related sites: NDS Homebrew, Drunken Coders, PataterSoft, etc. They all tend to link to the same tutortials- all of which are either quite outdated or incomplete.
Far and away the best is PALib. This is assuming you want to use PALib, that is.
I was using the highly regarded double.co.nz tutorials. But, they no longer work. I haven't looked into it very deeply yet, but when I tried to compile the very short programs there were several errors. devKitARM (part of devKitPro) seems to have changed since the tutorials were last updated.
Most notably:
- The development tools all changed from arm-elf-* to arm-eabi-*
- The DISP_SR symbol seems to have completely disappeared.
The first isn't really a bit deal. But it illustrates the a problem that may be more difficult to solve for a real beginner. I didn't really bother with it after than. I'll give it another go tonight when I get home.
Perhaps writing an up to date tutorial is something I should undertake. We'll see.
Subscribe to:
Posts (Atom)