How to use mod_wpad when compiling your code in other platforms

Following the entry on how to compile directly from the Wii's Homebrew Channel, I'd like to comment on a little "trick" that'll allow you to compile code that uses mod_wpad both on your computer and in your Wii.
The idea is to use preprocessor macros to "hide" the code when compiling in platforms other than the Wii.
Following with the meta.xml from that example, the new one would be as follows:


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<app version="1">
    <name>Compile Fancy Game</name>
    <coder>Your name</coder>
    <version>Version number</version>
    <release_date>Release date</release_date>
    <short_description>A short description.</short_description>
    <long_description>A longer description for the entry that'll compile your code.</long_description>
<arguments>
             <arg>boot.prg</arg>
             <arg>-o</arg>
             <arg>/apps/fancy_game/boot.dcb</arg>
             <arg>-D</arg>
             <arg>TARGET_WII</arg>
     </arguments>
</app>

That code would be pretty much like compiling your code in the PC like this:


bgdc boot.prg -o /apps/fancy_game/boot.dcb -D TARGET_WII

And in the code, where you do the mod_wpad import, you'd change it to:

#ifdef TARGET_WII
import "mod_wpad"
#endif

And, a little bit below that:

#ifndef TARGET_WII
#define wpad_is_ready(a) 0
#define wpad_info(a, b) 0
#define wpad_info_nunchuk(a,b) 0
#define wpad_info_classic(a,b) 0
#define wpad_info_guitar(a,b) 0
#define wpad_info_bb(a,b) 0
#define wpad_rumble(a,b) 0
#endif

The first block will only import mod_wpad in case the compiler defines the TARGET_WII macro, and that'll only happen in the Wii, if you adapted the code above.
The second block will void the wpad_* functions. For your program's logic, it'd be as if no Wiimote was connected.

Hope this helps you with the Nintendomax Wii Dev Competition 2011, where you can win a Nintendo 3DS console, and much more".

Happy coding!

BennuGD for Wii RC1!

It's time to release RC1 of BennuGD for Wii.
You can seed a list of changes below:

• The code is now much easir to mantain thanks to a slightly redesigned design (more on this to come) and is fully up to date with the upstream sources and overall, the port should feel much more stable.
• Finally found the reason to why some FNT files weren't loading: seems like there's a bug in zlib for Wii that prevents it from working as documented (try to open file as gzipped, if that fails, try to open it as a raw data file). Somewhy it ends up reading from the file in incorrect places. To avoid that, always make sure your FNT files are gzipped. You can know that they're gzipped if you open them with your favourite uncompressor and they open correctly.
• Small bugs fixed here and there.

I'm calling it RC1 as I consider it to be ready for public consumption, even there's a problem triggered with multiple Wiimotes that I must fix.

To sum up, here's a full list of things that you must know when porting your existing game to the Wii.

• Make sure you've read the Getting Started page on the Google Code project site.
• Make sure your FNT files are gzipped. They'll also take less space. To be on the safe side, also gzip you FPG and your MAP files.
• OGG might work, but it's safer to use MP3. Also, recode the MP3 and WAV files @48KHz. You can use a program like Audacity to recode your music. Module tracker formats such as S3M, IT, XM... work just fine.
• The builds don't include mod_debug. If you need it and cannot compile the code yourself, send me an email and I'll send you a copy of the runtime with mod_debug enabled.
• If you need a more integrated experience, you can always use the bundled mod_wpad. That way you'll be able to query info about the controllers such as battery levels, accelerometer input, available controllers...
• You can open websites on the user's Wii.
• If something goes wrong and BennuGD crashes badly, you can send me a photo of the crash and that'll be helpful!

Get BennuGD for Wii RC1 from here.

So what now? For the next releases I'm planning on:

• Trying to fix the joystick bug in SDL. Right now SDL seems to give wrong info about the number of present joysticks and when they were pressed.
• Improving mod_wpad to support button state reading and include Wii MotionPlus support.
• Integrating mod_chipmunk into the build for reallistic physics simulations.

Hope you liked the news! Have fun.

Comments on Beta 2 and a refresh to the second beta.

As a first note, I'd like to comment that I've uploaded a beta 2 refresh. This is to solve a very small yet annoying bug I had missed: OS_WII was not being defined (ups!). It also includes small updates to libjoy and mod_joy coming from upstream.

As for the changes included in beta 2 with regard to beta 1, I'll highlight a few:

• Exported mod_wm symbols. These where being compiled, but I forgot to export them, so they were unusable.
• I also touched get_desktop_size() to return the size of the mode SDL has set. I wanted to have this return the Wii's native resolution for you, but this seems to not be easy as of now, so at least you've got a mode you can set_mode() to.
• I also changed the dependency map so mod_mouse and mod_wpad both now depend on libjoy. This is to ensure correct hardware initialization and to improve compatibility with newer versions of the Homebrew Channel.
• Speaking of mod_wpad, I improved it a bit. Now you can check if a particular controller has a Guitar Hero 3 guitar or a Classic Controller attached to it with:
• WPAD_INFO(int channel, WPAD_HAS_GUITAR);
• WPAD_INFO(int channel, WPAD_HAS_CLASSIC);
• A few corresponding functions has been added to query those devices:
• WPAD_INFO_CLASSIC(int channel, int info);
• WPAD_INFO_GUITAR(int channel, int info);
• info can (as of now) only retrieve the battery level from those, with the value:
• WPAD_BATT
• mod_wpad can now also report the acceleration, as read from the Nunchuk. Please remind that the Nunchuk can only read acceleration in one axis, the rest will be 0. To get those readings, use:
• WPAD_INFO_NUNCHUK(int channel, int ACCELX);
• WPAD_INFO_NUNCHUK(int channel, int ACCELY); and
• WPAD_INFO_NUNCHUK(int channel, int ACCELZ);
• We can now also read the orientation of the Wiimote (in thousandths of a degree, I must double check this is coherent with Bennu's way of doing things). This works with WPAD_INFO_NUNCHUK() too but again, the results will only be valid on certain axes. Here are the new functions:
• WPAD_INFO(int channel, int WPAD_GX);
• WPAD_INFO(int channel, int WPAD_GY); and
• WPAD_INFO(int channel, int WPAD_GZ);

I believe that's pretty much it for the changes. Bugs have been solved, and some initial work has been done on integrating more unofficial modules, namely mod_image, mod_iconv and mod_sqlite3. But that's incomplete and has not been compiled into this release.

For a real example on how to use the new mod_wpad functionality, check this examples code.

Also, mod_debug has been left out in this release just because it makes the binaries bigger and I believe it'd be a pain to try to use it in a real Wii. If you need those, please let me know and I'll send you a copy of the binaries with mod_debug integrated.

I believe that's pretty much it, as always, you can get the binaries for the beta from the google code page.

Progress

Even if I've not written about it lately, there's been some very interesting progress lately.
I released alpha 5 of Bennu, which includes and improved version of mod_wpad. This new version allows you to query your Wiimote for the raw accelerometer data, make it vibrate...
A few days later, my brother found the cause of the bug that was triggered when using save and load. I released alpha5~1 which solved it and integrated mod_iconv (a wrapper around iconv I created some time ago).

For alpha 6, I'm working on making module loading dependant on your code. Right now, all the bits from all the supported modules are loaded when you fire the interpreter.
This is suboptimal as you may end up initializing things you won't be using later; and memory is an important concern in this particular platform. So, from alpha 6 on, if you want to use the functions in -say- mod_wpad, you'll have to import it.
This'll make the code more compatible with upstream Bennu, and less cluttered.
Also, mod_wpad will be expanded to allow reading the data from the Nunchuk's accelerometers and a way to find the appropriate resolution for each Wii.

Now, some people have been working with the latest alphas in the BennuGD forums, and they've shown the things is quite usable, already.
Have a look at this video by BomberLink that shows an arcade game he's currently working on where he's using accelerometers to control the main character.

Also, Me Matsusaka has ported his KOF Flames of Courage v5 (a King of Fighters clone) to the Wii. You can get it here:
http://www.megaupload.com/?d=ZZKFY5VL

I have not tried it myself, but hope to do it this evening :)

Alpha 4 released

Today, I'm releasing alpha 4.
This version changes the way mod_say works: until now, it'd just do a printf(). This caused artifacts onscreen. From now on, mod_say will output text to a file named "stdout.txt"
Also, this version includes a new module: mod_wpad. This Wii-specific module tries to provide much more info about the controller input than what the normal Bennu version would.
This is a very preliminary set of functions, and seems to not be working perfectly right now:

• WPAD_IS_READY(int channel). Will return 1 if channel channel is available and started. Otherwise, it'll return <0.
• WPAD_IS_BALANCEBOARD(int channel). Will return 1 if channel channel corresponds to a Wii Balance Board.
• WPAD_QUERY_BALANCEBOARD(int channel, int data). Will query info from a balanceboard. Data can be:
• 0: X position of the center of gravity.
• 1: Y position of the center of gravity.
• 2: Weight measured on the TOP-LEFT base.
• 3: Weight in TOP-RIGHT.
• 4: Weight in BOTTOM-LEFT.
• 5: Weight in BOTTOM-RIGHT.
• WPAD_BATTERY_LEVEL(int channel). Will return the battery level for a particular channel. 0<level<256.

Other functions will come, and you'll be able to get info on Wiimote acceleration, and other data. Also, as I said, the function names or return values are not done yet. It's a beginning, though.