Welcome! Log In Create A New Profile


The sate of homebrew, long term development, questions about devkitpro, how do contribute?

Posted by jimbanes 
Me and a few friends are looking to build a video game, we prototyped it on iPhone but we would really like to put it on a console. We are all Nintendo "fanboys" and want to do a classic side-scroller and as we have no intensions of selling the game or mass publishing it Wii homebrew looks like a great direction for the game. That being said I have a few questions about the sate of homebrew on Wii and the homebrew community.

I apologize in advance if any of these questions have been asked. If they have would you be so kind to point me to the proper thread :)

The state of homebrew on Wii?

Now that the Wii has reached the end of its life with the Wii U launched. Does this mean that Nintendo will stop delivering updates to the Wii keading to a "final"/stable and "acceptable" method to run homebrew games on the Wii?

Will team Twiizers continue to do awesome work and develop/support devkitpro for Wii now that Wii U is out, or will the focus on Wii U?

What is the legal status of homebrew on Wii. I assume its technically legal to run what ever code you want on a Wii you own... Its just the content that matters right? Running emulators and pirated nintendo roms on your Wii is illegal. But theres nothing wrong with running your on homebrew games on your own hacked Wii right?

I have been looking at devkitpro, I have it installed on my machine and I can compile the examples on my machine and run them in an emulator... Cause Im super hardcore right? It all seems to work but it begs me to ask the question.

How did devkitpro come to be? And how do you think it compares to the "real" nintendo wii SDK? By which I mean, How were the devkitpro tool chain written? Did you have to reverse engineer the Wii hardware and write everything from scratch?

What about the hardware drivers? are the hardware drivers for the Controller and sensor bar and cd drive, ect., written by the devkitpro team? or do the drivers reside in the Wii's firmware?

I see that there are some Wii specific game engines on the wiibrew wiki. What about all the other game engines out there? From what I can tell and see from the examples I have downloaded is that devkitpro games are just c or c++ applications. What limitations are there to using other.. non wii specific c/c++ libraries? Can I use any c/c++ game engine on Wii providing I use the GX and audio, ect. apis provided by devkitpro?

How can I contribute to devkitpro. I dont see any devkitpro or related repos on github. Is this due to legal issues with the status of homebrewing? or does the community just prefer SVN and sourceforge? Is there any chance the devkitpro and related repos will ever be moved to githib?

Edited 1 time(s). Last edit at 12/09/2012 07:57PM by jimbanes.
Re: The sate of homebrew, long term development, questions about devkitpro, how do contribute?
December 09, 2012 10:03PM
I can't answer all your questions, but I'll do the best I can:

For many years, the Homebrew Channel (HBC) has been the de facto standard for launching homebrew. The only thing that has really changed is how the channel is installed. At the current point in time, there are a reasonable number of exploits available for use with everything up to the latest version of the system software. The compatibility table here shows all the current (and indeed, past) exploits: [wiibrew.org]

Team Twiizers (TT) have just launched in the last few days an updated version of HBC actually (the update was to add support for the Wii mode of the WiiU, but it also works on the Wii). TT aren't working as much on the Wii as they were at one point, but that's largely because they don't need to; HBC in it's current state works very well, and Nintendo haven't launched any update for the Wii to block current homebrew efforts in quite a long time. It looks unlikely there will be another Wii update.

TT aren't (solely) responsible for devkitPro though; many, many people, including TT members, have contributed to devkitPro over the years. An individual called WinterMute takes on the task of maintaining devkitPro. As for whether it bears similarities to the official SDK; sadly, yes. There are parts of it ripped right out of the official SDK (my understanding is that no one ever bothered to properly reverse engineer certain things, so WinterMute just ripped the relevant sections from the official SDK). Unfortunately, this means the legal status of anything built with devkitPro is questionable, but that is generally ignored by the homebrew community. Most people aren't even aware of this I don't think. It's still better than other scene's where there is no homebrew SDK and leaked official SDKs are the only choice (e.g. xbox).

As for how it came to be: Most of it was reverse engineering of existing code. Figuring out how things work, then writing code to do those things. As I said, some portions were ripped from the official SDK.

Hardware is all controlled by "IOS". To understand this, you need to know that there are two processors in the Wii: A PowerPC and an ARM. The PowerPC is what runs the code you see, e.g. System Menu, games, homebrew. The ARM runs code called IOS. Basically what IOS does is give the code running on PPC access to the hardware, and also implements the security system. So for PPC code (e.g. homebrew) to access the various hardware, it basically has to "ask IOS". These IOS requests are wrapped up nicely in the functions of libogc (the Wii part of devkitPro), so programmers don't really need to worry about this. But essentially IOS contain the hardware drivers, and we can use those drivers from PPC code to do whatever needs done.

Stuff about game engines and libraries etc., I don't really know, as I'm not a developer. Hopefully someone else can pop in to answer that.

As for contributing to devkitPro, you can submit patches I believe, but it is an SVN on sourceforge, and I don't think that's going to change anytime to soon.
Sorry, only registered users may post in this forum.

Click here to login