#126393 - patroclus02 - Sun Apr 22, 2007 8:39 pm
I wrote programs for many systems (NES, SNES, SMS, Genesis/MD, Windows (Delphi+DirectX)). I find NDS to be a cool platform, with lots of posibilities.
Few problems with me.
Although I have almost 10 years of programming experience, I used C very little (I have basic knowledge though). And I see NDS documentation to be disperse... I wonder, if learning GBA first, would be usefull, and if the learning curve when moving to NDS is fast or not that fast.
Having a look at the examples in DeviKitPro, GBA's scroll demo uses a custom fonts, an prints manually to screen by writting to VRAM map table (however you call it), as it's been always used in classic platforms, but NDS examples use some embedded function like consoleInitDefault (which required including nds/arm9/console.h), which become rather estrange at first (not estrange really, but tedious to learn all of avaiable functions, and all the required libraries...)
Also, it seems that much more documentation is avaiable for GBA, and better emulators. No way to test NDS home brew roms with a minimun reliability at the moment, as emulators are far from perfect. you need to flash and try in a real system when doing any change. Debugging must be terrible then...
Any advices??
Thank you!
#126398 - tepples - Sun Apr 22, 2007 9:27 pm
| patroclus02 wrote: |
| Having a look at the examples in DeviKitPro, GBA's scroll demo uses a custom fonts, an prints manually to screen by writting to VRAM map table (however you call it), as it's been always used in classic platforms, but NDS examples use some embedded function like consoleInitDefault (which required including nds/arm9/console.h), which become rather estrange at first (not estrange really, but tedious to learn all of avaiable functions, and all the required libraries...) |
You can use the GBA method on the DS too, and that's how LOCKJAW for DS draws its text and playfield. The consoleInitDefault() is just an ANSI terminal emulator that does the writing to VRAM for you if you don't want to implement your own terminal.
One tip: Develop a GBA and DS version of your program in parallel, as Nintendo did with Mario & Luigi: Partners in Time. The game was designed to run on two linked GBAs and then ported to the DS. Another tip: Develop a PC and DS version of your program in parallel, where the two platforms share the same game logic source code files. I did this with LOCKJAW, but it appears to require a custom makefile without all the "automagic" of wintermute's template.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#126508 - ZeXr0 - Mon Apr 23, 2007 11:08 pm
You can take a look at www.palib.info
If you have experience with game programming, you might be able to understand the files, else you can always start with this, there's a lot of function to be able to start programming easily.
#126560 - patroclus02 - Tue Apr 24, 2007 2:07 pm
I do understand libnds, it is just that there're lots of defines, functions, inlines,... some addresses are defined as integer values, others as pointers,... it is just that it seems hard to learn all off it at first...
#126601 - tondopie - Wed Apr 25, 2007 2:37 am
I started with NDS coding and I looked back at some GBA source code and I think GBA is more complicated personaly... still there's no stylus, screen selecting... all that fun stuff
#126639 - qw3rty - Wed Apr 25, 2007 9:01 am
The Pern Project still has the best tutorials for text-backgrounds.
www.drunkencoders.com -> Tutorials -> GBA
VRAM, characters, tiles etc. is very well explained there.
On the NDS backgrounds and sprites work the same way, the only differences are higher screen resolution and more VRAM (and extended palettes)
#126669 - tondopie - Wed Apr 25, 2007 9:41 pm
| qw3rty wrote: |
The Pern Project still has the best tutorials for text-backgrounds.
www.drunkencoders.com -> Tutorials -> GBA
VRAM, characters, tiles etc. is very well explained there.
On the NDS backgrounds and sprites work the same way, the only differences are higher screen resolution and more VRAM (and extended palettes) |
and 3D ;)
#126678 - Dood77 - Wed Apr 25, 2007 10:53 pm
| tondopie wrote: |
| qw3rty wrote: | The Pern Project still has the best tutorials for text-backgrounds.
www.drunkencoders.com -> Tutorials -> GBA
VRAM, characters, tiles etc. is very well explained there.
On the NDS backgrounds and sprites work the same way, the only differences are higher screen resolution and more VRAM (and extended palettes) |
and 3D ;) |
3D text backgrounds? I wanna see...
#126694 - HyperHacker - Thu Apr 26, 2007 12:56 am
If you don't plan to actually develop for GBA, I'd say dive into NDS directly, so you don't have to learn and then un-learn the limitations of GBA that don't exist on NDS. For example, DS's nice fast CPUs and added VRAM give you the option of just using a 256x256 16-bit bitmap and software-rendering everything; from what I've heard, GBA was too slow to do this in any useful way and couldn't have any other layers or sprites while using this mode. 256x256x2 (bytes per pixel) = 128K, and there's 656K of VRAM, so you could have five 256x256 extended rotation backgrounds (up to 4 per screen) and still have 16K of VRAM left. Or you can use VRAM as work RAM (even execute from it) if you need to.
Of course you can try to work within the GBA's limitations even though they don't exist on NDS, if you want to get used to them anyway.
_________________
I'm a PSP hacker now, but I still <3 DS.
#126732 - Darkflame - Thu Apr 26, 2007 4:38 am
My advice; go straight to DS.
I only done a bit on the Ds, but didnt find it that hard.
I dont think learning the GBA will be easier then learning the DS.
| Quote: |
| One tip: Develop a GBA and DS version of your program in parallel, as Nintendo did with Mario & Luigi: Partners in Time. The game was designed to run on two linked GBAs and then ported to the DS. |
Interesting.
Not enough DS Dev kits around at the time then?
Guess the game could have been interesting like that as it could have been two player. (assumeing one person controlled each set)
Still, the development cycle resulted in a very dissapointing game.
The DS features tacked-on, and the whole expirence an order of maganitude worse then the stunningly good SuperStarSaga ;)
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#126740 - Ant6n - Thu Apr 26, 2007 6:17 am
well, it makes sort of sense to start with gba. But i noticed i totally got stuck with it, i dont really want to move to the DS.
#126764 - tepples - Thu Apr 26, 2007 12:58 pm
| Darkflame wrote: |
My advice; go straight to DS.
I only done a bit on the Ds, but didnt find it that hard. |
Not everybody has a PC wireless card suitable for DS Download Play. Without DS Download Play, you have to switch memory cards after almost each build. Otherwise, you can never be sure that your emulator's defects aren't canceling out your DS program's defects. This is much less of a problem on GBA because the emulators are more mature.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#126785 - Darkflame - Thu Apr 26, 2007 4:22 pm
| tepples wrote: |
| Darkflame wrote: | My advice; go straight to DS.
I only done a bit on the Ds, but didnt find it that hard. |
Not everybody has a PC wireless card suitable for DS Download Play. Without DS Download Play, you have to switch memory cards after almost each build. Otherwise, you can never be sure that your emulator's defects aren't canceling out your DS program's defects. This is much less of a problem on GBA because the emulators are more mature. |
I don't have a wireless card, I use a standard wireless router and the excellent ftp program.
Given the price of GBA development cards and such anyway, ?30 tops for a wireless router isn't much is it?
Especially not when the rest of the DSdevelopment can be very cheap if you choose too. (especially if you already have SD/CF cards anyway).
I would agree you can never trust emulation,but if your going too do DS coding, I don't see it being easier, or cheaper, to go into GBA coding first.
Oh, The other option,incidently, is too have two small cards and just keep swapping them over between builds :p
(sounds silly, but its a little quicker)
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.
#126788 - tepples - Thu Apr 26, 2007 5:18 pm
| patroclus02 wrote: |
| it is just that there're lots of defines, functions, inlines,... some addresses are defined as integer values, others as pointers |
This is probably my biggest complaint about libnds and even libgba headers: the lack of any semblance of type safety. A lot of addresses are defined as integers rather than pointers.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#126810 - dovoto - Thu Apr 26, 2007 11:44 pm
Registers defined as integers and not pointers?...i dont think there are many cases of this.
Most memory locations are defined as integers though and most bit defines are integer as apposed to enumerations...maybe this is what you refer to?
Suppose there might be a few registers hanging out not defined as pointers but I dont see any at a glance through the headers. Could you point a few out that are improperly defined?
As for learning GBA first there are a few things to consider. If you have no hardware then you may definitely want to consider GBA as the emulators are quite good...but then if you dont have hardware and dont plan on getting any whats the point really?
The DS is nearly hardware compatible with GBA. There is only the extra step of learning VRAM mapping on the DS to get the same feature set. And then you have lots of interesting things to play with (wifi, mic, touch etc..)
The DS scene is a bit more active so finding help and motivation is easier.
gbatek does a pretty good job with DS hardware documentation if you are looking for detail.
www.dev-scene.com has some good starting tutorials, and there is patater's document which is not bad.
DS emulators are comming to a point were you can dev against them with some confidence although you still need to run your code against the hardware on occasion.
My recomendation is that unless you are feeling financialy restricted to GBA and emulator development you should jump into DS. I personaly dont think it is any more difficult than picking up GBA; the state of the tools and libraries for the DS are much more advanced than when most of us started in GBA.
_________________
www.drunkencoders.com
#126830 - tepples - Fri Apr 27, 2007 3:58 am
| dovoto wrote: |
| Most memory locations are defined as integers though |
That's what I refer to. My custom GBA header file (which I abandoned around the time of gba_nds_fat because some of its names conflicted with those of libgba, which gba_nds_fat's header required) defined the memory locations as pointers, mostly (u16 *).
| Quote: |
| The DS is nearly hardware compatible with GBA. There is only the extra step of learning VRAM mapping on the DS to get the same feature set. |
And I had to do a lot of back-and-forth with the CF card when some of the values for mapping of bank B into main 2D sprites changed out from under me in the version of libnds distributed with devkitARM r20, causing all sprites to become invisible.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#126847 - DekuTree64 - Fri Apr 27, 2007 8:46 am
| tepples wrote: |
| My custom GBA header file (which I abandoned around the time of gba_nds_fat because some of its names conflicted with those of libgba, which gba_nds_fat's header required) defined the memory locations as pointers, mostly (u16 *). |
I use 2 sets of defines, for example
| Code: |
#define PAL_BG_ADDR 0x05000000
#define PAL_BG ((u16*)PAL_BG_ADDR) |
Mainly because I like to be able to use the same headers between C and assembly files. Also the typed version is handy for things like palette RAM, because it's naturally in 16-bit units. But for char VRAM I prefer the raw number, because generally I'm going to be doing calculations on the address, and it's annoying having to worry about the size of the data type it's defined to.
As for the topic of the post, I'd say don't bother with GBA if DS is what you really want to do. Always the major challenge in coding for any new system is getting something to run for the first time, and there are plenty of examples to get past that. Then it's just a matter of learning the specifics of each piece of hardware, which you can do at your own pace on either system.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#126867 - dovoto - Fri Apr 27, 2007 3:55 pm
| tepples wrote: |
| dovoto wrote: | | Most memory locations are defined as integers though |
That's what I refer to. My custom GBA header file (which I abandoned around the time of gba_nds_fat because some of its names conflicted with those of libgba, which gba_nds_fat's header required) defined the memory locations as pointers, mostly (u16 *).
|
Although i might tend to agree that the pointer notation for memory addresses are more convenient this would result in either 3 defines for each memory location (a byte pointer, a half word pointer, and a word pointer) with appropriate post fixing or we would have just one pointer definition (say u16* as that is most common) and the user could cast that pointer to something else.
We chose the route to provide just the address and let the user do what they will. In some cases we also provide convenience pointers (such as an OAM pointer to OAM). If there are other addresses which such pointers make sense then we can certainly add them, but what should be avoided is too many choices on how to access the same thing...that gets rather confusing.
These are just my thoughts (justifications really) and i am not sure how the other authors of the library feel about it.
_________________
www.drunkencoders.com
#126886 - Cearn - Fri Apr 27, 2007 9:27 pm
| dovoto wrote: |
| tepples wrote: | | dovoto wrote: | | Most memory locations are defined as integers though |
That's what I refer to. My custom GBA header file (which I abandoned around the time of gba_nds_fat because some of its names conflicted with those of libgba, which gba_nds_fat's header required) defined the memory locations as pointers, mostly (u16 *).
|
Although i might tend to agree that the pointer notation for memory addresses are more convenient this would result in either 3 defines for each memory location (a byte pointer, a half word pointer, and a word pointer) with appropriate post fixing or we would have just one pointer definition (say u16* as that is most common) and the user could cast that pointer to something else.
|
Not necessarily. In most cases there will be 'natural' types: if you're dealing with text or 16bpp backgrounds, using u16 makes sense. When dealing with tiles, using a tile-type makes sense. Even using u8 for affine or 8bpp backgrounds has its merits because often you're just using these things to pass along to copy or fill routines, which use pointers as their arguments.
If you're using raw addresses, you have to calculate the offsets manually. By using pointers instead, you can let the compiler do all the math for you. In my case, if I need the address of, say, tile 12 of charblock 3, I just do tile_mem[3][12], which is nice because the second index also corresponds to the tile index in OAM or the screen-entries. Something similar can be done with screenblocks and in some cases bitmaps as well. It just makes your work easier.
Even if you need something different than these natural pointers, you're still free to cast them, but by having them as raw addresses you're forcing the users to cast for even trivial matters. This generally leads to longer and less readable code ( ((u16*)VRAM)[i] vs just VRAM[i] ), and perhaps a bit of voodoo programming on the side.