SirPoonga
Shared on Thu, 12/07/2006 - 17:07You guys aren't going to see too many new screens. Right now since I have the hardware to run the stuff (finally) I noticed we are in a new era for DS homebrew. Also, I need to get graphics from my friend yet.
Here's what I am noticing. Slot 1 devices are new to the scene. Slot 1 is the nds slot. Slot 0 is the gba slot. up until a couple of months ago the only way to play homebrew on the DS was to use a gba device and patching your nds software to trick the nds so it didn't think it was a gba game. So most examples, libraries, extra assume you are using a slot 0 device. GBA had 64k of sram that most games used to store settings, game saves, etc. Many homebrew use that for the same reason. Since that is only available through the the gba slot I can't use that with my ds-x.
Slot 1 devices are starting to take off. the reason is they provide more compatibility with the nds since the software doesn't need to be patched. This will mean current homebrew will have to change to take advantage of this.
So that is what I am doing now. I am making several C and C++ classes that abstract saving small amounts of data. The other popular way of saving data in homebrew is to use fat (yep, fat, what your jump drive format is). The problem with this is the fat library that is available to homebrew only works with a couple of devices (mainly the ones the developer could get his hands on). So, to make the save code that works with the most amount of people you have to do both. instead of maintaining two versions of code I am going to make a class that abstracts saving. You call this save function and it will use fat or sram depending on how you compile the program. Then it is a matter of changing the batch file to compile two versions of the program using different commandline arguments.
So I will be doing alot of behind the scenes stuff and no new screens for awhile. I am also making a support class that allows you to display large animated images on the ds. The ds is limited to a max of a 64x64 sprite. Most people if they need a larger image manually manage multiple sprites to look like one image. I am going to make a class that handles most of the tedious stuff to make it easier for other developers.
Here's what I am noticing. Slot 1 devices are new to the scene. Slot 1 is the nds slot. Slot 0 is the gba slot. up until a couple of months ago the only way to play homebrew on the DS was to use a gba device and patching your nds software to trick the nds so it didn't think it was a gba game. So most examples, libraries, extra assume you are using a slot 0 device. GBA had 64k of sram that most games used to store settings, game saves, etc. Many homebrew use that for the same reason. Since that is only available through the the gba slot I can't use that with my ds-x.
Slot 1 devices are starting to take off. the reason is they provide more compatibility with the nds since the software doesn't need to be patched. This will mean current homebrew will have to change to take advantage of this.
So that is what I am doing now. I am making several C and C++ classes that abstract saving small amounts of data. The other popular way of saving data in homebrew is to use fat (yep, fat, what your jump drive format is). The problem with this is the fat library that is available to homebrew only works with a couple of devices (mainly the ones the developer could get his hands on). So, to make the save code that works with the most amount of people you have to do both. instead of maintaining two versions of code I am going to make a class that abstracts saving. You call this save function and it will use fat or sram depending on how you compile the program. Then it is a matter of changing the batch file to compile two versions of the program using different commandline arguments.
So I will be doing alot of behind the scenes stuff and no new screens for awhile. I am also making a support class that allows you to display large animated images on the ds. The ds is limited to a max of a 64x64 sprite. Most people if they need a larger image manually manage multiple sprites to look like one image. I am going to make a class that handles most of the tedious stuff to make it easier for other developers.
- SirPoonga's blog
- Log in or register to post comments
Comments