Dragon Quest IX (ドラゴンクエストIX 星空の守り人)
Developed by Level 5, published by Squenix. This video was taken at this year's Tokyo Game Show:
Coming March 2009 for Nintendo DS (in Japan. No official date for US).
Ni no Kuni (ニノ国 - The Another World)
Developed by Level 5 with Studio Ghibli.
Coming 2009 for Nintendo DS (No official dates for Japan/US release).
Have I mentioned how much I love Level 5?
Showing posts with label NDS. Show all posts
Showing posts with label NDS. Show all posts
18 October 2008
11 October 2008
Nintendo DSi and homebrew
The most interesting aspect of Nintendo's recently announced DSi is the addition of SD slot. According to reports, this card is intended to store photos, video, music and games from the DSi Shop. So, wow! it sounds like Nintendo is actually allowing users to play games from a re-writeable memory card. This sounds perfect for homebrew.
It also sounds perfect for game piracy, which is why I'm doubtful that Nintendo would make this slot anywhere near as useful as it sounds. Aside from maximizing their market share, Nintendo's greatest desire is to eliminate game piracy for their systems.
Nintendo vs. the Aarrr! 4
Earlier this year Nintendo sued a group of companies in Japan for importing "game copying devices" like the R4DS. Because that's how they view them - simply as "game copying devices" with the implication that all game copying is illegal.
Of course, that's how they have to present their case. If they drew attention to the various uses for these cartridges which are clearly non-infringing like Moonshell, DS Organize, and the numerous homebrew titles, then they would be presenting a weaker (but more truthful) case.
Granted, it's likely (although I have no figures) that a significant number of R4 carts have at least one pirated game on them. And the "game backup" defense that is often used is weak because Nintendo made it impossible for normal users to create their own backups. This is important because the courts view a file you made yourself differently from a file you downloaded from the web. One is a backup and the other is not - even if the 2 files are identical and you own a legitimate copy.
Regardless, the legality of these carts (in the U.S. at least) will likely be determined by the precedent established in the Betamax case. This is where the "significant/substantial non-infringing use" defense comes into play. That is, the legality of these devices will depend on whether or not they support a non-infringing use like homebrew. Since all of these devices effectively enable homebrew, it probably more realistically comes down to whether or not there is a vibrant ("significant") homebrew community using these devices.
What about the DSi?
With the addition of music and video playback in the DSi, they're undermining the need for some homebrew like Moonshell. But there will always be a demand for other homebrew apps and games. If they really want to eliminate the R4, M3 and other carts, then they need to eliminate the need for these devices. That means having some Nintendo sanctioned method for writing your own games. With the addition of the SD card in the DSi, they now have a mechanism for doing this.
But will they do it? Sadly, I think that it's unlikely. My guess is that Nintendo has a love/hate relationship with homebrew. Actually, it's probably more of an "indifferent/hate" relationship. Some people in the company probably think it's cool what people are doing with their hardware, while others can only see dollars (and yen) lost to evil pirates.
And even if they do allow user-created games to run from the SD card, there are so many ways for them to screw it up and render it (mostly) useless. The most obvious mistake would be to not grant these SD card-based games full access to the hardware, but they could also require that apps be signed or some other nonsense. Nintendo just needs to look at how Apple is handling approvals for the iPhone App store for inspiration.
But this is all speculation. We know very little about what Nintendo is planning on doing with the DSi. My hope is that they will enable homebrew on the SD card, but I'm not holding my breath.
It also sounds perfect for game piracy, which is why I'm doubtful that Nintendo would make this slot anywhere near as useful as it sounds. Aside from maximizing their market share, Nintendo's greatest desire is to eliminate game piracy for their systems.
Nintendo vs. the Aarrr! 4
Earlier this year Nintendo sued a group of companies in Japan for importing "game copying devices" like the R4DS. Because that's how they view them - simply as "game copying devices" with the implication that all game copying is illegal.
Of course, that's how they have to present their case. If they drew attention to the various uses for these cartridges which are clearly non-infringing like Moonshell, DS Organize, and the numerous homebrew titles, then they would be presenting a weaker (but more truthful) case.
Granted, it's likely (although I have no figures) that a significant number of R4 carts have at least one pirated game on them. And the "game backup" defense that is often used is weak because Nintendo made it impossible for normal users to create their own backups. This is important because the courts view a file you made yourself differently from a file you downloaded from the web. One is a backup and the other is not - even if the 2 files are identical and you own a legitimate copy.
Regardless, the legality of these carts (in the U.S. at least) will likely be determined by the precedent established in the Betamax case. This is where the "significant/substantial non-infringing use" defense comes into play. That is, the legality of these devices will depend on whether or not they support a non-infringing use like homebrew. Since all of these devices effectively enable homebrew, it probably more realistically comes down to whether or not there is a vibrant ("significant") homebrew community using these devices.
What about the DSi?
With the addition of music and video playback in the DSi, they're undermining the need for some homebrew like Moonshell. But there will always be a demand for other homebrew apps and games. If they really want to eliminate the R4, M3 and other carts, then they need to eliminate the need for these devices. That means having some Nintendo sanctioned method for writing your own games. With the addition of the SD card in the DSi, they now have a mechanism for doing this.
But will they do it? Sadly, I think that it's unlikely. My guess is that Nintendo has a love/hate relationship with homebrew. Actually, it's probably more of an "indifferent/hate" relationship. Some people in the company probably think it's cool what people are doing with their hardware, while others can only see dollars (and yen) lost to evil pirates.
And even if they do allow user-created games to run from the SD card, there are so many ways for them to screw it up and render it (mostly) useless. The most obvious mistake would be to not grant these SD card-based games full access to the hardware, but they could also require that apps be signed or some other nonsense. Nintendo just needs to look at how Apple is handling approvals for the iPhone App store for inspiration.
But this is all speculation. We know very little about what Nintendo is planning on doing with the DSi. My hope is that they will enable homebrew on the SD card, but I'm not holding my breath.
30 December 2007
Converting videos for use with Moonshell (NDS)
One of the tasks that I needed to do over the holidays was to get some Nintendo DS/GBA flash carts set up for some people who are just getting started in Gameboy/DS homebrew development. Even though the primary use for this card is for homebrew, I thought it would be nice to get some audio/video playback working as well.
So I installed the multimedia player (homebrew) app Moonshell onto the DS flash carts. The latest version of Moonshell can be found in Moonlight's NDS archive. As of this post, Version 1.71+1 (August 2007) is the most recent version.
To use image and music files with Moonshell, you just copy your JPG/MP3 files (or a few other formats) over to your flash card and Moonshell will show/play them just fine.
Video, however, is a different beast as Moonshell won't dynamically convert the format or the size - it expects the video file to be GBA screen-sized and to be encoded in MPG1 video/MP2 audio. This means that you need to convert the videos into DPG format, which is a special format specific to the NDS and Moonshell. To convert videos into this format, there are a few free tools available (presented in the order in which I discovered them):
I tried all of these tools and had luck only with SUPER. There are clearly people out there using dpgenc and BatchDPG successfully, but I kept encountering problems with the conversion - probably codec related, but I didn't bother tracking them down since SUPER worked "out of the box" for my tasks.
To create DPG video files using SUPER, select "Nintendo - DS" from the dropdown list of output containers. This will simplify the interface by removing options that are not appropriate for DPG containers.
Now you can drag a video file into the window to add it to the filelist. Press the "Encode" button and SUPER will chug away and drop the newly encoded video file into your output directory.
One nice thing about SUPER is that, while the interface is a bit busy, there is plenty of context-sensitive help that pops up when you hover over the elements in the UI. This makes it fairly easy to get started with the program and get things working. To set the output directory, for example, just hover over the Output box and a message will pop up telling you how to set the output options.
So I installed the multimedia player (homebrew) app Moonshell onto the DS flash carts. The latest version of Moonshell can be found in Moonlight's NDS archive. As of this post, Version 1.71+1 (August 2007) is the most recent version.
To use image and music files with Moonshell, you just copy your JPG/MP3 files (or a few other formats) over to your flash card and Moonshell will show/play them just fine.
Video, however, is a different beast as Moonshell won't dynamically convert the format or the size - it expects the video file to be GBA screen-sized and to be encoded in MPG1 video/MP2 audio. This means that you need to convert the videos into DPG format, which is a special format specific to the NDS and Moonshell. To convert videos into this format, there are a few free tools available (presented in the order in which I discovered them):
- dpgenc.exe - This is included in the dpgtools distribution that comes with Moonshell. A basic tutorial on how to use (an older version of) this is at can be found in the MaxConsole Forums.
- BatchDPG - This is an alternative to dpgenc created by LS5, another homebrew developer. The official site still has the old original 1.0 version (with source), but updated versions from various people are also available (like Firon's 1.2 version). Be sure to review Yee and Firon's BatchDPG Guide because there are a number of pre-requisites (AviSynth, ffdshow, .Net Framework 1.1) that you'll need to have installed for this to work.
- SUPER by eRightSoft - "Simplified, Universal Player Encoder and Recorder" - This is a general video/audio converter that contains special support for DPG files. It can be downloaded from the SUPER main page, although to get to the actual download link, you'll have to navigate through a number of links. If you get frustrated trying to find the download, here is a direct download link. The latest build is 2007.23 (4 July 2007).
I tried all of these tools and had luck only with SUPER. There are clearly people out there using dpgenc and BatchDPG successfully, but I kept encountering problems with the conversion - probably codec related, but I didn't bother tracking them down since SUPER worked "out of the box" for my tasks.
Using SUPER to create DPG files...
To create DPG video files using SUPER, select "Nintendo - DS" from the dropdown list of output containers. This will simplify the interface by removing options that are not appropriate for DPG containers.
Select "Nintendo - DS" as the Output Container
Now you can drag a video file into the window to add it to the filelist. Press the "Encode" button and SUPER will chug away and drop the newly encoded video file into your output directory.
Drag your video files into the SUPER window
One nice thing about SUPER is that, while the interface is a bit busy, there is plenty of context-sensitive help that pops up when you hover over the elements in the UI. This makes it fairly easy to get started with the program and get things working. To set the output directory, for example, just hover over the Output box and a message will pop up telling you how to set the output options.
03 October 2007
Milking goats on your DS
Yaknow, I was thinking just the other day that there weren't enough goat-milking games for the DS and lo! I see these new screenshots for Konami's upcoming "Lost in Blue 3".
From some of the other released screenshots (see gamebrink or nintendic), it looks like this game also affords you the opportunity to be attacked by leopards or to sing with dolphins.
I wonder if there's a Wii version coming out...
From some of the other released screenshots (see gamebrink or nintendic), it looks like this game also affords you the opportunity to be attacked by leopards or to sing with dolphins.
I wonder if there's a Wii version coming out...
28 April 2007
Teaching GBA Homebrew to Kids
This past Thursday (April 26th) was Take Your Offspring to Work Day*. This is where you bring your young-uns in to work and then you show them what you do for your job. Rather than have them come in and watch me browse the web all day, I thought it would be nice to run a class for all the kids that were coming into Google's Kirkland office.
I've been putting together a simple Intro to Programming class for a local Montessori school so this seemed like a perfect opportunity to test things out before the trial run this summer.
The full class targets 10-12 year olds and starts with a basic introduction to computer engineering (binary, bytes, how things are represented in memory, ...), and then some gaming stuff like creating your own sprites, and then some code to move them around the screen, and then either animation or more coding depending on what direction the kids want to go.
For the 1-hour TYOTWD version, I needed to simplify things a bit so I dropped the computer engineering intro and replaced it with a demo of The Legend of Zelda - The Minish Cap running in an emulator. I demoed the game using the debugger version of No$gba so that I could show how the different background layers and sprites were used in the game.
After that, I showed them how to create their own sprites using Spritely, which is a sprite editor that I am writing. Now there are a number of nice tile/map editors out there, but none of them was perfect for what I wanted to do - they are either too complicated, or force you to work with tiles (instead of sprites), or cost money, or are really map/background editors, or have some other problem.
I wrote Spritely with a mind to make it easy to create GBA/NDS sprites, and I made a bunch of simplifying assumptions along the way. It only handles 8x8 pixel tiles, only allows the sprite sizes supported by the GBA/NDS, and restricts you to 16-color palettes. But it does allow you to directly edit multi-tile sprites.
In addition, Spritely has an option to generate the source code for a complete GBA or NDS project (including makefile) that you can compile and see your sprites in action. The generated project doesn't do much - it just allows you to move your sprites around - but it demonstrates the basics. The generated code requires that you have the latest version of devKitPro installed, but that's OK since I pre-installed everything needed on the laptops that the kids were using.
So in summary, I had the kids:
I also had a couple of cartridges available so that they could see their creation running on a real GBA/NDS. One 7-year old walked around with an NDS playing her "game" for (what seemed like) half an hour. Google was also nice enough to buy a few NDS cartridges to give out as prizes.
Note that even though I was targetting 10-12 year olds, there were kids ranging in age from 6 to 16 present. The younger kids needed their parents (or siblings) help with the computer, but had no problem creating their own sprites once they were shown the basics. I had hoped to go into the source code a bit with the older kids, but didn't have time.
Now, the TYOTWD class was slated to take an hour, but we kept an extra hour at the end for people who wanted to stay on and keep working. We ended up having to chase the kids off to the next event after nearly 2 and a half hours.
So it seems like it was a success. It started out a bit rough because my laptop wouldn't connect to the projector properly, and we didn't have One Laptop Per Child so the kids had to share, and the room was a bit cramped. But all-in-all it looked like the kids were excited to be there. It was nice to overhear some of them talking to their parents afterwards: "I hope you got all that information dad, because I want to keep doing this when we get home".
Hopefully at least one of the kids will continue their interest in programming. Maybe we'll see some innovative GBA/NDS homebrew coming out a few years from now.
As a final note, the kids were using a preview version of Spritely. I'll be releasing it widely once I fix a few obvious flaws and add a few more features.
* Take Your Offspring to Work Day (TYOTWD) is also known as Take Your (Daughters / Daughters and Sons / Spawn) to Work Day
GBA = Gameboy Advance
NDS = Nintendo DS
I've been putting together a simple Intro to Programming class for a local Montessori school so this seemed like a perfect opportunity to test things out before the trial run this summer.
The full class targets 10-12 year olds and starts with a basic introduction to computer engineering (binary, bytes, how things are represented in memory, ...), and then some gaming stuff like creating your own sprites, and then some code to move them around the screen, and then either animation or more coding depending on what direction the kids want to go.
For the 1-hour TYOTWD version, I needed to simplify things a bit so I dropped the computer engineering intro and replaced it with a demo of The Legend of Zelda - The Minish Cap running in an emulator. I demoed the game using the debugger version of No$gba so that I could show how the different background layers and sprites were used in the game.
After that, I showed them how to create their own sprites using Spritely, which is a sprite editor that I am writing. Now there are a number of nice tile/map editors out there, but none of them was perfect for what I wanted to do - they are either too complicated, or force you to work with tiles (instead of sprites), or cost money, or are really map/background editors, or have some other problem.I wrote Spritely with a mind to make it easy to create GBA/NDS sprites, and I made a bunch of simplifying assumptions along the way. It only handles 8x8 pixel tiles, only allows the sprite sizes supported by the GBA/NDS, and restricts you to 16-color palettes. But it does allow you to directly edit multi-tile sprites.
In addition, Spritely has an option to generate the source code for a complete GBA or NDS project (including makefile) that you can compile and see your sprites in action. The generated project doesn't do much - it just allows you to move your sprites around - but it demonstrates the basics. The generated code requires that you have the latest version of devKitPro installed, but that's OK since I pre-installed everything needed on the laptops that the kids were using.
So in summary, I had the kids:
- Create some sprites using Spritely
- Export the GBA/NDS project from Spritely into a directory
- Open a command prompt and "cd" to that directory
- Type "make"
- Double-click the .gba or .nds ROM to run the program in an emulator (either VisualBoyAdvance or the standard version of No$gba)
I also had a couple of cartridges available so that they could see their creation running on a real GBA/NDS. One 7-year old walked around with an NDS playing her "game" for (what seemed like) half an hour. Google was also nice enough to buy a few NDS cartridges to give out as prizes.
Note that even though I was targetting 10-12 year olds, there were kids ranging in age from 6 to 16 present. The younger kids needed their parents (or siblings) help with the computer, but had no problem creating their own sprites once they were shown the basics. I had hoped to go into the source code a bit with the older kids, but didn't have time.
Now, the TYOTWD class was slated to take an hour, but we kept an extra hour at the end for people who wanted to stay on and keep working. We ended up having to chase the kids off to the next event after nearly 2 and a half hours.
So it seems like it was a success. It started out a bit rough because my laptop wouldn't connect to the projector properly, and we didn't have One Laptop Per Child so the kids had to share, and the room was a bit cramped. But all-in-all it looked like the kids were excited to be there. It was nice to overhear some of them talking to their parents afterwards: "I hope you got all that information dad, because I want to keep doing this when we get home".
Hopefully at least one of the kids will continue their interest in programming. Maybe we'll see some innovative GBA/NDS homebrew coming out a few years from now.
As a final note, the kids were using a preview version of Spritely. I'll be releasing it widely once I fix a few obvious flaws and add a few more features.
* Take Your Offspring to Work Day (TYOTWD) is also known as Take Your (Daughters / Daughters and Sons / Spawn) to Work Day
GBA = Gameboy Advance
NDS = Nintendo DS
Subscribe to:
Posts (Atom)