NDS Sprite Handler

[dumbdrunkencoder]

Learning how to use sprites on the NDS was a daunting challenge. Even now I think I know just enough to be dangerous. There are many examples with little to no documentation. The libnds docs on the web are rather general and difficult to understand. No two examples, code snippets, or explanations use the same code or technique so I had a difficult time getting anything to work. Once I accidentally stumbled on something that I understood, I vowed to write my own NDS sprite handler to cover as many variations as I needed for my own game. I also gave it additional capabilities and configurabilities that I have not tested or used. I would like to share the results of my labors with the community. You can get the zipx file here http://home.earthlink.net/~jcocovich/si ... ndler.zipx and it contains the header and source file for my sprite handler class that can be compiled into your application. It also contains source for a demo that shows how to use the handler. Sprites are included. A Programmer's Notepad project is included and a Visual Studio 2008 solution is included. The code is heavily commented.

The implementation for the class spriteHandler is a result of many hours of research, experimentation, and verification of all documentation, examples, and vague source code I found on the internet and downloaded resources. It also includes descriptions of why everything is there, how it is used, and where it came from in the NDS documentation where appropriate. My goal is to never, ever make an ass out of u and me by ASSUMING you know how the hardware works and why configurations are seemingly set to arbitrary values with no reason. Therefore, please feel obligated to let me know where my goal has failed and I will fix it.

The Demo is created from the libnds sprite animation example with some modifications and improvements to work with my sprite handler class.

---dumbdrunkencoder

[WinterMute]

First problem - you used a commercial, proprietary archive format which it seems is not yet supported for those not using windows.

I've generally been trying to make sure that C++ is not a prerequisite for compiling example code. Yes, C++ may well be quite popular these days but many devkitARM users prefer the low footprint of pure C. That's not to say you shouldn't program the DS in C++, merely that many people don't.

Sadly good documentation is missing, mainly because a lot of the people who have been using devkitARM for DS development have migrated from GBA homebrew and the two machines are sufficiently similar for those people to be comfortable. The tools do seem to be becoming more popular and I'm starting to see a lot of people with little programming experience and/or pretty much zero experience with low spec game consoles.

Good resources for information are

http://www.coranac.com/tonc/text/toc.htm

http://nocash.emubase.de/gbatek.htm

The dev-scene tutorials are kind of ok but obviously unfinished, there were plans to merge what's there with devkitPro & drunkencoders but obviously time has been in short supply.

Most of the rest should be avoided and vary from not updated with devkitARM/libnds to utter nonsense.

[dumbdrunkencoder]

Excellent feedback albeit all negative. That is what I was hoping for.

As soon as I allowed my WinZip to create a .zipx file for me I wondered if that was a mistake. I will probably create .rar files in the future 'cuz that seems to be popular around these communities.

I am a C++ programmer professionally and you had to hit me on the head with a sledgehammer before I realized this community is made up of homebrew(duhhh...that's what I was searching for) programmers' who are not necessarily professional programmer's with expensive tools that their company buys for them. Unfortunately, my paradigm forced me to purchase those tools for my own and write C++ applications.

I now realize that even if your community were able to open my archive, they would find nothing of any value inside except perhaps for the documentation and comments and for those few who want to use C++, the code. I always like a good challenge and now see the value in rewriting my sprite handler without C++ classes but using structures and functions only.

My frustration with the docs is probably due to jumping into the game console arena in the middle with the NDS not having _any_ experience whatsoever on _any_ gaming console development. That will no doubt be apparent to those of you who take a look at my code. However, I was able to manage the code so that it worked with an emulator.

Again, thanks for the feedback and my goal is now to provide something useful.


---greybeard

[zeromus]

Yeah, professional c++ programming firms are all on an email list and a memo went out saying that they should buy expensive winzip for all their employees and immediately start internally using .xzip or whatever. The firms working on platforms other than windows were a little befuddled, but they complied anyway, as they are obligated to do.

It's got nothing to do with professional and everything to do with a massively heterogeneous environment, something which you probably don't have any experience with. Assuming that folks have anything other than zip or .tar.bz2 is sort of impolite, and may result in people ignoring what you post since they can't be bothered to dig up a dearchiver for your stuff.

Just use zip unless the discourtesy of posting a humongous file which could have been smaller begins to exceed the discourtesy of using something less than completely ubiquitous.

[StevenH]

I use WinZip on my PC, and I alway create .zip files as the big warning on the .zipx file format is a give away that it's not a backwards compliant type, and even then I've got to make sure that the zip file format is set to compatibility mode.

I've got your source extracted on my computer and I'll be having a proper look at it at some point over the next few days, I'll give you some feed back on the docs and code within.

But as WinterMute pointed out, the DS has a very limited amount of memory, IIRC 4Mbytes, and anything C++ does is always memory hungry, I've seen code that will kill the memory before you start coding your own stuff.

Some numbers for you to consider for future coding on the DS:

Main memory (program+heap) 4 MBytes
Stack: 16Kbyte

If my figures above are wrong WinterMute can correct me, but I'm pretty sure they are correct for DS phat and DSLite.

[zeromus]

if you search for strings in some games you can find uses of STL such as basic_string and deque::push_back. Here are some examples: splinter cell chaos theory, harry potter goblet of fire, scribblenauts, pokemon platinum.

I'm not saying any of these games are sterling examples of tight and cool game programming, and I'm not saying that anyone claimed that c++ was an insta-kill. It's just food for thought.

[WinterMute]

I certainly didn't mean to imply that you definitely shouldn't use C++ on the DS, merely that a lot of devkitARM users don't.

A couple of interesting links relating to C++ on the DS

http://www.coranac.com/2009/02/some-int ... code-size/

http://www.coranac.com/2009/11/sizeof-new/

Not everything about C++ is memory hungry but it's very easy for a novice to run out of memory in a 4meg system.

[vuurrobin]

another interesting link about c++ on the ds:
http://www.console-dev.de/2009/04/02/ge ... cplusplus/

although it would also be interresting in what the code would be with c structs.


also, I don't think that your example code will help much. The examples should be enough (and if they are not, tell us how we can improve them). what we really need is a good tutorial.

pataters tutorial may also be good to read, but some parts that it does are already taken care of by libnds:
http://patater.com/manual

[dumbdrunkencoder]

Thanks for all the comments. The new code is at http://home.earthlink.net/~jcocovich/si ... andler.zip as a legacy zip archive. The sprite handler class has been replaced with a struct and global functions.

also, I don't think that your example code will help much. The examples should be enough (and if they are not, tell us how we can improve them). what we really need is a good tutorial.

Sadly good documentation is missing, mainly because a lot of the people who have been using devkitARM for DS development have migrated from GBA homebrew and the two machines are sufficiently similar for those people to be comfortable.

I think my problem is that I had no prior experience with the GBA or any gaming platform. The examples I found were therefore difficult to understand and amost impossible to modify because of my lack of knowledge that everyone else making use of the examples had.

A good tutorial, I agree is what was really needed and I found a few here and there but none allowed me to understand enough to create my own example. I would be glad to work on a tutorial based on any feedback I can get about my sprite handler. It is useful for my application and heavily commented but not a step by step description on how to create and use sprites. I am still learning that process.

---greybeard

[relminator]

You can code c++ and still have speed to spare. Just use c++ constructs judiciously. No virtual tables or anything that could mess up your cache hits.

So instead of OOP you use DOD(Data Oriented Design) or a component based system. That way you always fetch memory consecutively.