Slashdot Mirror

Perhaps you could demonstrate the difficulty of building a cross-GCC by phrasing your rant in the form of a good Stack Overflow question. Explain what you are trying to do, what web search queries you used, what you tried, what you expected, and what each failure looked like. If they are in fact "beginner problems", getting the question onto SO should eventually help future web searchers find the answer more easily. Or if Stack Overflow scares you, you might try looking at how it was done in devkitARM.

For line numbers in an M4 script, have you tried adding --synclines ?

If error messages from some compiler or interpreter are unhelpful, have you tried filing bugs against said compiler or interpreter to improve the usefulness of its error messages?

Consequently, Nintendo is the least evil games console manufacturer/distributor.

So you say it's "least evil" to exclude individuals, even serious ones, from officially developing games for its platform. And you say it's "least evil" to sue manufacturers and importers of GBA flash cards and R4-style DS microSD adapters, even those who ship source and binaries of the devkitARM homebrew SDK (or its predecessors) on a mini-CD with the product. And you say it's "least evil" to require region coding on all console games and all DSi/3DS games, as opposed to the PS3, Xbox 360, and iPod touch, where many or all games are all-region. And you say it's "least evil" to have, back in the NES era, threatened stores considering selling the Sega Master System or TurboGrafx-16 with shortages if they didn't go NES-exclusive, and threatened developers with "ROM shortages" if they didn't go NES-exclusive. Or are these examples of "bad guys at heart", not rising to "evil"?

Nintendo DSi vs. iPod touch: How is Apple more evil?

Wii vs. ION nettops such as Eee Box and Aspire Revo: How are ASUS and Acer more evil?

GX for Wii is a thin wrapper around the graphics hardware.

And the OpenGL (ish) in libnds for DS homebrew is a thin wrapper around the DS's graphics hardware: each entry in a display list corresponds roughly to one GL command. How is this possible?

Sounds good! here's the how-to for setting up devkitPPC (the standard Wii homebrew toolchain).
I don't know what Aquaria uses for graphics, but if it's SDL, running it on the Wii should be trivial.

That said don't misconstrue this as to have any actual sympathy for people selling devices to get around copyright protection. I understand that these devices can be used for homebrewing. And I'll support the first to support any company that actually tries to make a business out of homebrewing for the Nintendo DS. But first that company will have to do a pretty damn good job convincing me they really are trying to make a business out of homebrewing and aren't using it as a legal pretext to allow people to pirate DS games.

There is no business in homebrewing on the DS. But as someone who's spent a substantial amount of time in tinkering with the DS, let me reassure you that it's a lot of FUN! (Warning: your definition of FUN may vary). By todays standards you've got a very limited amount of room to do your work in and you have to make the most out of it, and most of the code you write is going to be really close to the hardware. If you're remotely interested in this sort of thing (even if you're not going to write a game), the DS is a pretty cheap ARM platform for all the hardware that's in it:

• two small screens, addressable through several memory banks, with several modes of operation (including a rudimentary OpenGL like 3D API on one of the screens)
• a touch screen interface
• wifi
• sound output via speakers and input via microphone

The DSi even has two cameras onboard, but I don't think they're supported by libnds yet.

Oh, and of course, very interesting is that a lot of people have made the source code for their homebrew games available. Sometimes you'll just go and have a peek at how someone else did something, and discover something really ingenious, often optimized to give the best performance given the limited hardware available.

But let's face the fact, without Nintendos official seal of approval (read: a wheelbarrow of cash and a reputable game-company backing it) there will never be any real money in whatever you're going to code. If you want to do something commercially, you'll have to buy Nintendos tools, etc. If tinkering with a piece of hardware you buy is going to make you a criminal, I fear for the next generation of geeks.

Let's hope we get a similar ruling in this country some time (seems unlikely under the yoke of Mandelson, but still).

Get developing!

Let's set thing straight. So far, homebrew on the Wii is an entirely different playfield from copied games. To play games on DVD-Rs, you need to hardware mod your drive, period.

Now, when you get to Virtual Console/WiiWare piracy, things get a little muddier. Unfortunately, if you can run homebrew, then you can effectively pirate VC games, because the terribly broken security means that you can pretty much just install them and they'll work. This might change in the future, when Nintendo fixes the problems.

Our (Team Twiizers') goal is to enable homebrew on the Wii, not piracy. We're not going to go out of our way to prevent piracy, but we also try to come up with methods of running homebrew that don't directly enable piracy. However, we can't work around the fact that, ultimately, if you can run unsigned code, then that code might be a game. We do have the advantage that pirates don't really have much of clue overall (so far), which is why we haven't seen a Wii ISO loader that can run games from an SD card yet. We sure as heck aren't going to write it, but if someone does, there's not much we can do about it.

As for homebrew, there is certainly a public, free, open source SDK available based on the GNU toolchain and an open source library to access the Wii hardware. In fact, most of the Wii's hardware is supported. Full graphics (though the API is mostly undocumented, it's all there), Wii Remote, SD card access, Gamecube pads, networking (WiFi or ethernet), USB mass storage, partial sound (no hardware acceleration yet), etc. See devkitpro for the toolchain and wiibrew for the community wiki.

I'm speaking here as an amateur Nintendo DS developer with some experience with DevkitPro, the "toolchain" made by some guys to run stuff on Gameboy Advance, Nintendo DS, Gamecube and recently Wii, among others. I have no direct experience with Wii developing, but I think I can help you a little...

* Which programming language can I use? I am guessing C/C++ is supported?

The "toolchain" is called "DevkitPPC" (a part of DevkitPro, which is available here) consists of GCC and some other utilities (many from GNU) and libraries to generate ELF executables that the Wii can run. So, basically, C and C++ are supported.

I don't know about the last version, but they're working daily on the CVS mainly with Wii updates, so expect the next version (r15) to be very nice. All this is available as a Windows installer, or you can get binaries (or the source) for Linux. I remember seeing something for OSX, but I don't know how it is nowadays.

* Which UI library exist? Is there support for input devices, can I also output text and images?

* Which network library exist? Can I use internet/WLAN connection, can I use Berkeley sockets API?

* Are there existing example applications? Not only "hello world"... maybe something more complex?

The libraries for the NDS are very low-level stuff, with very recent additions towards higher-level stuff; so I'd imagine the Wii stuff is still very low-level.

There are some Wii examples to get you started. I don't know if the main packages include them, you can grab them here if not.

Finally, if you start developing for the Wii, expect to visit forums, dig up information on IRC and generally learn *very* low-level stuff to do anything beyond a simple "hello world".

As a big fan of the potential of the Nintendo DS, I want to point out the possibilities of developing for handheld consoles. In terms of functionality, the current handheld generation, i.e. the Nintendo DS and the Sony PSP aren't far behind, if not even ahead of, cellphones and PDAs. They both have nice big screens and WLAN, which opens up a broad range of possibilities for homebrew software. For example, for the DS there is an e-Mail program, web browsers, internet radio clients, ssh (in DSLinux) and much more. The PSP has a fast CPU and a powerful graphics chip, while the DS two screens one of which is a touchscreen, so it encourages experimentation with novel user interfaces. Both consoles can deal with removable media: The PSP uses the Memory Stick while for the DS there are adapters for Compact Flash and (mini|micro)SD cards. The SDKs are both unofficial, but freely available and actively maintained. Both homebrew scenes are worth checking out, since they have produced a lot of great software, which is not only games. I admit that getting into development is a bit hard at first, but the coolness factor of having your own apps and games running on a games console is just worth it :)

Some links:
Devkitpro (Compiler toolchains and SDKs for DS, PSP and others)
Dev-Scene (DS homebrew news and homebrew database)
DSLinux

Pictoblog (one of my projects)
My DS coding blog

Cheers!
Tob

Just because you compile with GCC doesn't make your system a GNU system. Otherwise, the Game Boy Advance system would be the GNU/GBA, as Nintendo provided a port of GCC as part of the GBA SDK. (Homebrew developers use a different port of GCC.)

If I had to make a guess as to what deserves a GNU/ prefix, it would have something to do with the userland, which executes even when nothing is being compiled. As far as I can tell, only Linux uses glibc and GNU Coreutils out of the box. FreeBSD has BSD libc and BSD Coreutils.

So how do I make Flash games without a $700 devkit? With the DS, I need $500 for a PC, $130 for a DS, and $50 for an R4 and a microSD card. I download the software to CD or microSD at a public library, and then I take it home and install it on my PC. With the Wii, I need $500 for a PC, $250 for a Wii, and either $700 for an Adobe Flash license or $250 for an Adobe Flash Education Edition license and at least $450 for a semester of community college.

http://www.devkitpro.org/

I don't know, google around a little =P

The Nintendo DS community is a loud and wonderful beast. In the last few months... We've had DSDoom, DSLinux and Dev-Scene. natrium42 is a brillant developer and this is an interesting piece of hack but.. wouldn't be have been a better idea to post the bigger picture (for some reason all my submittions keep getting denied.)

You know, it's not actually that difficult to get into DS game development at all. The only significant hurdle is finding someone to pay to do the actual cart manufacturing. It's not god-awfully expensive, but it's more than I had originally expected; I wish I wasn't NDA bound to not give a number, but you can work out an upper bound with some common sense, and I'll just say "it's near that upper bound." If you can convince the people at Nintendo that you're not just going to turn around and sell the SDK, they'll usually sell you one for much cheaper than the price they quote on http://warioworld.com/. If you'd rather take the simple route and jus get going, the homebrew SDK is free, is GCC, and is quite easy to use.

From TFA:

Nintendo machines are traditionally hard for established companies to get a foothold on, let alone students.

Well, I'm a student, too, and I'm working on the port of Linux to the DS. And no, we do not have an official development kit. We use gcc and tools supplied by the homebrew community.

And there are countless others who are developing games and other applications, too. I'd say most of them are students. See here

Another difference to what TFA describes and the homebrew scene is that the homebrew scene is largely open source.

Since the team couldn't actually get hold of a DS development kit, Metalheads was made on a PC using a Wacom tablet in place of a touchscreen.

Doh. They obviously haven't informed themselves well before writing the game. They could have written it for real hardware and tested it on real hardware. See here

From TFA:

Go on, somebody give him a development kit.

Here you go.

I don't think we'll need an official toolchain for the wii. There is an actively maintained multi-platform open source homebrew toolchain for GameBoy Advance, GP32, Playstation Portable, GameCube and Nintendo DS here. Adding support for the wii will just be a matter of time. Actually the guys already opened up an IRC channel for the wii, even though there's probably not much coding going on yet :)

Unless the process you describe allows you to plug NES carts into the Gamecube

You plug the NES Game Pak -> CopyNES -> PC -> (optional) text translation, cheats, or other mods -> CF reader -> CF card -> GBA Movie Player.

By that standard, the Xbox is backward compatible to the Atari 2600 (and almost every other popular console).

The difference is that with the Game Boy Player + GBA Movie Player:

• You don't need to install a modchip of disputed legality. Lik-Sang was forced to stop carrying modchips but still proudly carries the GBAMP.
• You don't need to download an illegal copy of anything comparable to the XDK to compile emulators or other homebrew. You just need GCC for ARM architecture.

It's also a bit silly to assert you can't have a pet game for the PSP simply because you don't have two LCDs.

It's not the second screen as much as the fact that it is touch sensitive. Nintendogs could have been done without the top screen, but if you don't have a touch screen, how can you touch your dog in pleasant ways?

Yes, a few of these games are sequels or have related series.

And a lot of the DS games aren't. Feel the Magic, Meteos, Polarium, and the like are brand new franchises. There are borderline cases: Pac-Pix and Kirby Canvas Curse play nothing like other games in their franchises to the point where the franchise is nearly irrelevant, unlike the racing games (Wipeout, MC, NFS, RR) whose gameplay is just like that of their predecessors. There certainly aren't enough original franchises on the PSP to justify the $120 difference in purchase price.

Also, the PSP doesn't really have something to be backward-compatible with, yet

PS1 games through a Walkman-shaped accessory analogous to a GameCube Game Boy Player perhaps?

but that is a nice feature of the DS. (Although why they elected to disallow multiplayer link games is boggling.)

Probably because a link port would have taken up extra space on the console that is otherwise used for the real headphone jack, and because they wanted to prevent people from using flash card kits based on a GBA link cable.

where can I download Nintendo's hobbiest SDK?

A hobbyist SDK compatible with GBA and Nintendo DS is available here, and the forum is here.

You think they weren't entrenched after the SNES?

Because the Sonic the Hedgehog series and a more accurate port of Mortal Kombat 1 sold a lot of Sega Genesis systems, the Super NES wasn't entrenched nearly as much as the NES was.

Developers may also like the fact they can throw 1.8G on a PSP disc

How long does it take a UMD drive to read 1800 MB of data? Translate that into a temptation to drop to a NOW LOADING screen and you see what makes PSP not the best choice for playing five minutes at a time.