It was a lot of fun!

As you probably know, Satoru Iwata passed away last Saturday. In case you don't know him, he is credited as the mind behind the Wii console.
In the 90 previous technical posts I have described some of my mistakes and some of the lessons I learned while porting BennuGD to the Wii. I still consider this port as one of the coolest things I've done with computers to date.

It was a lot of fun coding for and learning with such a great console!
I might've not used the console in the way Mr Iwata intended it to be used but he was a hacker, he'd understand.

Preview release of binaries based on official monolithic version

I'm releasing a preview version of BennuGD for Wii based on upstream monolithic code.

Known bugs:

• There's something weird going on with directories and as a result of that BennuGD won't automatically set the working directory to the path where your DCB resides. This means that you won't be able to launch your games from the Homebrew Channel just yet.
  I've only tested the binaries to work when launched through wiiload.
  You'll also still need to change the working directory from your BennuGD code to the correct path, with something like:
  chdir("/APPS/MyAPP/");

This build only includes the official modules, but includes all of them. I've also left some debugging info on. It'll go away when the proper release arrives, obviously.

<<Get it from here>>

If you know how to compile and run your code through wiiload I'd like to ask you to download it and tell me if it's working fine for you.
Cautions from previous releases still apply:

• Convert your music to 48kHz
• Don't use FNT files compressed with gz
• All that stuff

If it's not, please report bugs in the comments section of this post or -better- in the project's bugtrack section.

Thanks a lot.

Compiling the Wii port with the official monolithic code (Part II: BGDI)

So this is what the official monolithic version of bgdi looks like when compiled for the Wii and run without arguments.

It's noteworthy that it's a complete version of BennuGD: all and only the official modules are built in: I'll still have to merge unofficial modules (mod_wpad, mod_chipmunk) before doing a proper release but this is a completely up to date build of BennuGD.

I'll run a few tests and in case everything is working as expected I'll drop the binaries here for you to play.

[EDIT] Sorry, no release for you today: Modules are loading and some functionality is there, but there's some major stuff not working and I need to fix it before releasing anything useful :(

OpenGL coder needed!

[Cross-posted to bennugd-wii and bennugd-mobile blogs]
[Please note that this is my own personal initiative and, while Splinter is fully aware and approves it, he's not directly involved with it]


Over time BennuGD has achieved quite a few milestones: not only it's one of the easiest open source game programming languages around but people have used it to create very fun games, thousands of people have downloaded BennuGD games for the Wii and hundreds of thousands of people (if not millions) downloaded SorRv5 in the few days before it was taken down by Sega. It also hit the front of many game related magazines. And even after the official links were removed, loads of people continue to post Youtube videos with SorRv5 game content, which is really cool.

More importantly, BennuGD now works in most PC OSes, but it has also been ported to some really interesting platforms: classic game consoles and handhelds plus iOS and there's a WIP port (that's proving to be more difficult than initially thought) for Android. This enables you to create your game in your computer and, if you take a few basic precautions, run it in your favourite platform.
In most platforms performance is not a problem but in others it is not ideal. For example, trying to run a BennuGD game with a multi-plane scroll in iPad 2's native resolution results in a more than sub-optimal experience, and we want that situation to improve. Games need to render faster and for that to happen we need a new hardware-based blitter that can co-exist with the current software based blitter.

Day after day we see games that could easily be made with BennuGD (plus some unofficial extensions) succeed in those new mobile patforms but we need that new 2D blitter if we want to allow people to create such games.

Right now it doesn't look like the current members of the community can step up and create the new blitter themselves, so I'm asking for help. As I said before, this is not an official effort in the sense that the BennuGD project leader is not behind it but he also feels the need for this and if some good code appears I'm sure he'll be happy to see how it fits in the official code base.

Technically the work that needs to be done roughly consists in rewriting/modifying some of BennuGD's core libraries to be OpenGL (+OpenGL ES?) based. Those would be libgrbase, libvideo, libblit, librender and probably others, too.
The new code should be written in C and your code would be distributed under the zlib license (just like BennuGD is) so that games created with it can be distributed in any manner no matter the platform.

If you feel like you can help and want to use some of your time helping an open-source project please leave me a note in the comments and I'll get in touch with you. Don't worry if you don't know how Bennu works internally, I can help you with that.

Thanks a lot in advance!

Compiling the Wii port with the official monolithic code (Part I: BGDC)

Yesterday I spent an hour or so playing around with the official monolithic code.
I got BGDC to compile from SplinterGU's monolithic code.

What you're seeing is the standard info message you get when you call "bgdc" without any arguments.

Not really impressive but it's progress, in a sense :)

PS: The patch includes one small dirty section; we'll fix it before release

Official Monolithic architecture now available!

(Cross-posted to bennugd-wii and bennugd-mobile blogs).
SplinterGU just made an official monolithic implementation of BennuGD available in the official SVN repo.
The implementation is pretty-similar in design to mine but SplinterGU has managed to make it much easier to mantain (the header with the list of required symbols are generated automatically so he basically just maintains the modular version). That said, future updates to my ports (both for the Wii and for mobile platforms) will be based upon this design. I don't yet know if I'll publish full sources or just a set of patches against the official repo.

In any case, SplinterGU has expressed interest in the Wii port so it might become official at some point.

Not much more to announce: I advanced quite a bit with the iOS port and should published an updated template shortly. The android port still has troubles with the sound, and those don't seem to be going away shortly.

Happy coding!

La Red Resiste

(This is a post about the Spanish government passing a ruling by decrete that bypasses judiciary power just to please a moribund industry and the US government, please excuse the off-topic if you're only interested in programming)

Hace exactamente dos años tuvimos conocimiento del anteproyecto de Ley Sinde. Gran parte de la ciudadanía señaló de inmediato su rechazo en las redes a través del #manifiesto por los derechos fundamentales en Internet. En estos 24 meses el debate social sobre esta iniciativa ha sido intenso y ha aglutinado a ciudadanos y organizaciones preocupados por la merma de derechos y libertades. Ahora, pocos días después de haber sido deslegitimado por las urnas, un gobierno moribundo pretende aprobar el reglamento que desarrolla esta ley en abierta connivencia con el gobierno entrante.

La Ley Sinde tendrá numerosos efectos indeseados: al introducir una fuerte inseguridad jurídica en la regulación de Internet, se dificulta gravemente la actividad de los emprendedores tecnológicos que el Partido Popular pretende que contribuyan a reactivar la economía. La redacción de la Ley Sinde señala claramente que se aplica a todos los servicios de la sociedad de la información; no deben confundirnos los mensajes que afirman que su única razón es la de cerrar webs de descargas. Nada es peor para el crecimiento de un mercado que la inseguridad de no saber si al día siguiente un negocio puede ser cerrado por la aplicación arbitraria de una norma en manos del gobierno de turno.

El panorama de la propiedad intelectual en nuestro país es atroz: la Embajada de los Estados Unidos ha impuesto la aprobación de la Ley Sinde, el canon digital a empresas y administraciones fue declarado ilegal por el Tribunal de Justicia de la Unión Europea pero tras año y medio se sigue pagando, los antiguos dirigentes de la SGAE -siempre defendida por el Ministerio de Cultura- se hallan imputados en la Audiencia Nacional por el saqueo generalizado del dinero de los autores. Este panorama cuadra con el general: una corrupción política extendida y no censurada en las urnas, unida a la subordinación de la democracia a los intereses de unos pocos con nombres y apellidos a los que sin embargo se les llama “mercados”.

Sólo con inteligencia, diálogo y trabajo se pueden resolver los actuales retos de la propiedad intelectual y comenzar a construir una salida a la preocupante situación económica actual. Como el Tribunal Europeo de Justicia, entendemos que la tensión entre la propiedad intelectual y la libertad de empresa, el derecho a la privacidad y el derecho a recibir o emitir información ha de resolverse en favor de estos tres últimos derechos. Será la única manera de crear riqueza y de mantener las libertades que tanto ha costado conseguir.

Frente a la arbitrariedad, la defensa histórica de la ciudadanía ha consistido en asegurar la garantía de los derechos fundamentales sustrayéndolos de la política, esto es, de los poderes de la mayoría y del mercado: se trata de derechos inviolables, indisponibles e inalienables. Los gobiernos van y vienen. La red resiste.

Marcos Lopez: Part II

BennuGD user beredezebe has packaged mz's "Marcos Lopez: Part II" game to our loved Wii console.
You can find more details of the game here and in the meantime you can watch a video of the game in action below but you better give it a try!

Get it from here.

Updated binaries

As you might now from the BennuGD-mobile blog, my most recent work on BennuGD has been focused on using the monolithic architecture I created for the Wii port to engineer the Android & iOS ports.
While most of the work has gone into those, the Wii port has also received all the updates from upstream BennuGD and the other day I made some test binaries just to check that the Wii code still compiles as it should.

I'm releasing these untested binaries just in case they're useful to anybody, but please be aware that they might expose bugs and eat your homework. Apart from that, they feature the latest and greatest in BennuGD featureness.

Grab the updated binaries from here.

[Update] Ups! Looks like I screwed up something with the binaries! thanks a lot to beredezebe for testing them.

"Morshu the MMMMMM" new BennuGD-Wii game!

Reader Beredezebe writes to let us know that a new BennuGD-Wii game created by user blabla has been released. It's called "Morshu the MMMMMM" which features pretty cool graphics and is available in French and in English.

Read all the news and info about the game in the original NintendoMax thread [FR].


Meanwhile, you can see a video of the game below:

Get the game from here.

Hope you like it, and thanks to Beredezebe!


[Updated to cite blabla as the author of the game, beredezebe is the author of the port]

On the new monolithic architecture

(Cross-posted to bennugd-wii and bennugd-mobile blogs).
I've been wanting to write this post for quite some time now. I feel it's time to share some of my thoughts about how the monolithic version of BennuGD is designed.
If you've followed the bennugd-wii blog since it began, you may already know that the current design is the third iteration of the monolithic version of BennuGD. This article is obviously about the current design.


Why do we need a monolithic version of BennuGD?
Some of you might know that one of the main design goals of BennuGD after forking Fenix was to become modular so, why do we need a monolithic approach?
Well, even if the modular approach seems to have many advantages over a monolithic one, not all the systems support it. BennuGD relies heavily on dynamic libraries (dlls if you're on Windows, so files if you're in most Unix-like systems or dylibs if you're on OSX) and the operating system provides a way of dealing with them.
In most systems, that way is called libdl and it works really well. If you look inside your system you'll realize that there are literally thousands of dynamic libraries lying there, so the system works.
In other -usually smaller- systems we don't have that system nor any other equivalent one and it turns out that some of those systems are particularly interesting for us in the game-making world* so we must find a way to avoid that limitation while conserving as much of the modular design as possible. 

But that makes loading libraries that weren't compiled in impossible, doesn't it?

Yep, that's why I call the design monolithic. It would be perfectly possible/pretty easy to create a design based on the current one that combined both ideas by including some modules inside the main binary and loaded others from external module files, but I didn't bother to create it as I don't feel it makes much sense.



How does BennuGD handle modules?
In trying to understand how to bypass the limitation, we must first understand how BennuGD works with the modules.
This is -roughly- what happens when you ask BennuGD to import a module (let's use mod_video as an example):

1. BennuGD will look for a file that follows the system naming convention for dynamic libraries in a set of pre-defined directories in your system. For example, in Windows BennuGD would first look for mod_video.dll in the current working directory. Let's imagine the file is found there.
2. BennuGD asks the system to load the library and quits if it finds any errors.
3. It asks the system for a list of symbols that define compose it. For example, mod_video_constants_def** would be an array containing the constants defined by the library and mod_video_functions_exports would be an array of the functions that the module provides. There are many more that the libraries can define and they're all completely optional.
4. Based on the info gathered from mod_video.dll and the rest of the modules BennuGD creates a table with all the information they provide and goes on to compile your code taking that information into account.

So, how to bypass that process?

Well, the best way I could think of when creating the monolithic approach is to construct that table of symbols by hand when creating the BennuGD binaries and compile all their functionality inside the interpreter. Obviously I also had to change the code that performed steps 1-3 so that instead of looking for the symbols in the actual module files it looks for them in the array. As a result when the library loader module is asked to load a module it looks for the library in the array and returns its position in the array (it literally returns a number: look for this library's symbols in the nth row in the array).

You can have a look at that table here; lines 137 and on.

There are two symbol arrays there
It turns out that the BennuGD compiler and the interpreter need slightly different symbols: the compiler doesn't really care about what your program does as long as it is written correctly and therefore it only cares about the symbols that define how a correctly-written program should look like. So it needs to know how a function should be called (which is the function name, what type of/how many arguments it accepts) but it doesn't care at all about what it does.
The interpreter, in the other hand, needs to know everything about what that function does when called.
There are, also, symbols that both parts need to know about (which are a particular libraries' dependencies, for example) and others that are only useful to the interpreter and therefore I chose to split the list of symbols in two: one with the symbols only needed by the interpreter and another one with the symbols useful to both the compiler and the interpreter.


Defining the actual symbols
If you have a look at the code linked above, you'll find that the symbols themselves are not defined in that file but are included from another file called mod_video_symbols.h.
That file doesn't exist in upstream BennuGD and it explicitly declares the the symbols required by the BennuGD compiler and tells the C compiler what the names of the rest of the symbols are and that they're complete declaration will come from somewhere else (hence the extern word in the declaration after the #else clause).
You can see that the last column in the functions list is set to 0 when compiling BGDC. That column should tell BennuGD what C function to call when the user calls that  BennuGD function. As I said, the compiler doesn't care about what that function does and therefore we don't need to declare it. If we did declare it we'd have to compile all the code for all the modules into BGDC, too. There are other more complex reasons to not try to compile all the module code into BGDC, too. 


When compiling the module code, the symbols come from mod_video.c which is the unmodified module file from upstream.


So you're writing the symbols many times!
Yes. The issue would be very easily solvable if I were the main author of BennuGD and that was how the second iteration of the architecture worked.
Unfortunately that meant that any patch from upstream takes a lot of work to be integrated as ALL the symbol-defining files had to be modified by hand: when a change came from upstream I had to locate the exact line where that change was done and apply it by hand into my code. Taking into account that each patch might contain hundreds of changes split across multiple files, that made maintaining the project a huge task even if we forgot that the main goal of the project was not to create a monolithic build of BennuGD but to create a port of BennuGD to a set of new platforms, which meant quite a bit of work by itself.
Right now I can just drop the files from the upstream version of BennuGD into my source tree and upload the code to the SVN server. I still have to be careful with the patches to supoprt platforms not available upstream (Wii, PSP, iOS & Android) but this new way of working makes things much simpler than before.


Advantages of this approach
To start, DCBs compiled with upstream BennuGD work just fine -endianess issues aside- in the monolithic builds and vice-versa.
The modular approach isn't gone. Even if the modules are all inside the binaries, they won't get loaded until you actually import them. This saves memory in some systems and from the user's point of view it's transparent: both architectures behave consistently to him.
My code is prepared to be compiled as either a monolithic build or the normal BennuGD modular structure so you can compile both from the same source code.




So that's pretty much it, hope to hear your thoughts in the comments and hope I made it clear in case it's useful to anybody.


* Consoles like the Wii or the PSP don't support it and other systems like the iPhone do support it but Apple seems to be very restrictive about the use of dynamic library loading in third party applications.
** That's why you cannot just rename your modules, BennuGD would then look for the wrong symbols.

[Update 2015-07-14] Updated the link to monolithic_includes.h

A game made with BennuGD wins the NintendoMax contest!

Beredezebe writes to let me know that the results for the Nintendomax Wii Dev Competition 2011 are now out, and know what? La Momia que Fuma's "Mr. Sitwell in Turbo WC Magical Adventure" is the winner!

The judges say:

Cid2mizard: J'adore l'ambiance déjanté du jeu, c'est un shoot them up original. Les effets visuels sont super, la maniabilité est très bonne. Un jeu comme on voudrait en voir plus souvent. Je ne serais pas surpris de le voir à la première place!

beredezebe: Ça, c'est ce que j'appelle un jeu ! Pour commencer, on a affaire à un humour très fin (un type sur des toilettes volantes qui doit cracher des trucs sur un Sumo aérien), les graphismes sont excellents, la durée de vie est très bonne et la difficulté est au rendez-vous ! Je n'ai vraiment rien à redire, mis à part la voix de Mr. Sitwell (au bout d'une demi-heure, c'est un supplice) et une difficulté un peu trop grande dès le départ (on doit pouvoir s'adapter avec le temps). Mon coup de cœur pour cette année.

ConsoDreams: Un jeu bien réalisé, graphiquement c'est pas mal. Dans les bons titres.

Which -roughly, my French is not what it used to be- translates to:

Cid2mizard: I love the crazy ambiance of the game, it's an original shoot'em up. The GFX are great and the playability is very good. A game like we'd like to see more often. I wouldn't be surprised to see it in the first place!

beredezebe:That's what I call a game! To start, we're dealing with a very fine sense of humour (a guy on a toilet who must shoot a flying Sumo), the graphics are excellent, the life    endurance is very good and the difficulty is fine! I really don't have any complaints except for Mr Sitwell's voice (after half an hour, it's a punishment) and the difficulty might be a bit to high at the start (it should adapt better during playtime). My favourite for this year.

ConsoDreams: A very well-done game, graphics aren't bad at all. It's amongst the good titles.

So there you have it. The jury's also noted the high quality of the entries, which makes Momia's victory even more valuable :)

Download the latest update of the game from here.

The other BennuGD-created game I know of -Pong Breaker- has rated seventh in the contest.

Have a lot of fun!

Mr. Sitwell in Turbo WC Magical Adventure

The date has arrived and the game submitting phase for the Nintendomax Wii Dev Competition 2011 is now over and at least one BennuGD game has been submitted: La Momia que Fuma's

La Momia que Fuma (Momia, for short) is well known for his unique drawing style and his humorous games. He won last year's BennuGD/GPH game programming compo with EEEEK! EEEEEK! HOOOOOOK!!!. I already blogged about the game and its Wii version in this blog enntry.

You can see a video of his new game below (thanks to Cid2Mizard!).

Hope you like it.

Get it from here.

BennuGD for mobile blog, more games

I've created a new worklog on using BennuGD to create games for mobile devices. The binaries published there share the same code base as those for the Wii and also come in a monolithic package.
I've written a few articles there already, so be sure to give them an eye if you're interested in creating games for mobile devices.
You'll notice that most articles are iOS-centric, but fear not Android fans! an Android port is underway and once it's usable, I'll post more info for you too.

Just a small note, iOS & Android usually work on little-endian chips so the DCBs created in your Wii just won't work there, on the bright side you can use the DCBs compiled in any other little-endian machine (your computer, that is) in you pocket computer.

Without further ado:

BennuGD for Mobile

Hope you like it.

PS: I'll update some games soon.

BennuGD to change license to Zlib (you can now create console games with BennuGD)

Good news everyone!

BennuGD has changed license to Zlib. What this means is that you can now use BennuGD to create commercial games for any popular consoles.
In particular, you can now create BennuGD games for the Wii and publish them through the official channels. To do so, you need to be a registered Nintendo developer (conditions and application forms at Wario World). You won't be able to use the binaries I provide here through the original channels, as you'll need to use Nintendo's own SDK.
If you've got a developer license for the Wii or any other major console and want to see BennuGD ported to that platform in order to rapidly create wonderful games, drop me a line; we might be able to help each other.

bennugd-monolithic ported to Xbox

A user by the nick of A600 has ported the bennugd-monolithic code to the original Xbox console (the one with the Intel processor, not the Xbox 360) for the purpose of running Streets of Rage Remake there.
You can grab everything needed to run the game there (the package includes full source code and a Visual Studio solution for compiling the code) from here.

A bit off-topic, but I thought it might be of interest to some of you.

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!

Streets of Rage Remake v5 final released, it's impressive!

Bomber Games have released the final version of their BennuGD game called Streets of Rage Remake v5 (remember the video I posted about it featuring accelerometer controls?). This release is the culmitaion of 8 years of hard work and features 103 stages, 19 playable characters, 64 enemies. The source code for the game is over 80000 lines of code and tries to faithfully recreate the experience of the original game.

It's really cool, although it seems to have some problem on the Wii. I'll work with BoMbErLiNk to try to make sure the game comes to our Wiis at some point.

Be sure to read their own presentation of the game in their blog.
I leave you with some media from the game:

BTW, in the meantime you can play it in your computer, download it from here.

Congrats, Bomber Games!

Compiling your code directly from the Homebrew Channel

The recommended method for compiling BennuGD games in your Wii is by using wiiload to both upload your code and to execute commands there.
If your Wii is not connected to your Wifi network (or you don't have one) things get a bit more complicated and previously I created a method for compiling that was a bit complicated. Today I'm going to show you a simpler one.

First of all, make sure that your Homebrew Channel is updated as this method requires one of the latest versions available.

Then, we'll create two entries in your Homebrew Channel: one for the game itself and another one for compiling.
The first one is created just normally, and the boot.elf file that you must put there is the normalbgdi.elf file, as found in the latest available BennuGD release and you'd just copy all the game's resources there, as usual. The meta.xml file for that entry would be something like:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<app version="1">
    <name>Fancy Game Runtime</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, more detailed description of your game.</long_description>
</app>

Now, in the other entry (just another directory in the "APPS" folder of your SD card) you'd place your game's source code. The boot.elf file corresponding to that entry would be bgdc.elf from the release and the meta.xml file would go 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>
     </arguments>
</app>


Where, obviously, "/apps/fancy_game" corresponds to the location in your SD card for your game's runtime (the first entry in this example). Also, "boot.prg" is the name of your main source code file.

If everything went fine, you can now insert your SD card in your Wii and you should now see two entries: one called "Fancy Game Runtime" and another one called "Compile Fancy Game". When you click on the compilation entry, your code will be compiled and the DCB file will be generated -assuming BennuGD liked your code- in the runtime entry, which you can click right away to test your code.

This process won't save your from having to grab the SD card from your console, copying the new files and putting it back in your Wii, but I'm sure it'll somehow make testing easier for you.

Hope you liked it!

PS: Remember you can win a Nintendo 3DS console just for coding by entering the Nintendomax Wii Dev Competition 2011! Good luck to everyone!

Nintendomax Wii Dev Competition 2011

The guys at Nintendomax (most of the gameplay videos I post come from their site) have organised a new Wii Homebrew development contest and it's certainly looking interesting!

You can use any programming language you want to for the game, so why not use the best one around?. You might want to use the newly released rc1 version that include mod_chipmunk physics to create stunning games very easily. It feels great and has helped bring very cool games to the Wii ;)

Prizes:
They're giving out two Nintendo 3DS consoles, accessories, 150€ in cash and more. See the link below for details.

Rules:
Here are some of the rules for the competition, but be sure to read the whole thread linked below for more info.

- Everyone can participate, regardless of the country.

- All games or applications must be totally new for the Wii. This implies that no projects have been submitted shall be posted on another site before the competition closed, the projects involved in the Homebrew Bounty taking place at the same time are accepted.

- The project progress can be posted during the contest period (WIP, Previews, videos, etc.).

- A Splashscreen will be posted april 11, 2011 after a competition for designers organized by us.

- The splashscreen will be the first image to appear in the project and will be posted at least 5 seconds. Transitions and all types of effects are allowed.

- Participants may submit 1 or more projects.

- Ranking of the contest will be defined by a jury. No public vote is held.

- The classification criteria are multiple (originality, graphics, life, gameplay, personal notes, stability / bug, etc ...), a report will be posted after the vote.

- Competition results will be posted June 30, 2011.

- The Loader or applications that enable piracy of games is prohibited.

Read all about the contest here [en] or here [fr].

Hope to see your entries soon!