(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.
Friday, December 2, 2011
Sunday, September 25, 2011
Marcos Lopez: Part II
Tuesday, September 13, 2011
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.
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.
[Update] Ups! Looks like I screwed up something with the binaries! thanks a lot to beredezebe for testing them.
Saturday, September 3, 2011
"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.
Meanwhile, you can see a video of the game below:
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]
Thursday, August 4, 2011
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.
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):
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
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):
- 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.
- BennuGD asks the system to load the library and quits if it finds any errors.
- 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.
- 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.
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
Sunday, June 26, 2011
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:
The other BennuGD-created game I know of -Pong Breaker- has rated seventh in the contest.
Have a lot of fun!
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!Which -roughly, my French is not what it used to be- translates to:
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.
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!
Thursday, June 2, 2011
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!).
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!).
Wednesday, May 18, 2011
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:
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:
Hope you like it.
PS: I'll update some games soon.
PS: I'll update some games soon.
Saturday, May 14, 2011
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 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.
Monday, May 2, 2011
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.
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.
Friday, April 8, 2011
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:
That code would be pretty much like compiling your code in the PC like this:
And in the code, where you do the mod_wpad import, you'd change it to:
And, a little bit below that:
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!
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_WIIAnd in the code, where you do the mod_wpad import, you'd change it to:
#ifdef TARGET_WII
import "mod_wpad"
#endifAnd, 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
#endifThe 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!
Tuesday, April 5, 2011
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:
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!
Friday, March 25, 2011
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:
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:
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!
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!
Sunday, March 13, 2011
Nintendomax Wii Dev Competition 2011
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.Read all about the contest here [en] or here [fr].
- 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.
Hope to see your entries soon!
Wednesday, March 2, 2011
BennuGD for Wii RC1+ (mod_chipmunk integrated!)
Today I'm refreshing the BennuGD for Wii binaries with a very nice addition: Chipmunk physics library integration. Just in case you missed earlier posts, mod_chipmunk is a wrapper for BennuGD created by Prg that allows you to unleash the full potential of the Chipmunk physics library with a BennuGD friendly syntax.
You can see some examples of what Chipmunk can do in this video:
The cool thing about this library is that creating a reallistic physics simulation is quite complicated even for those with a clear understanding of what's going on and this library manages all the physic interactions easily and effectively.
I've adapted one of the examples Prg includes in his package so that you can run it directly from the Homebrew Channel in your Wii.
I'm asking if any of you can create a little video of this demo, so that I can embed it in this post. I cannot do it with a good quality myself so I'd thank it if anybody can help me with that.
You can get the refreshed BennuGD binaries with mod_chipmunk integrated here:
Please, understand that physics simulation can be a very processor-intesive process. If your game slows down too much, try reducing the number of active processes.
You can see some examples of what Chipmunk can do in this video:
The cool thing about this library is that creating a reallistic physics simulation is quite complicated even for those with a clear understanding of what's going on and this library manages all the physic interactions easily and effectively.
I've adapted one of the examples Prg includes in his package so that you can run it directly from the Homebrew Channel in your Wii.
I'm asking if any of you can create a little video of this demo, so that I can embed it in this post. I cannot do it with a good quality myself so I'd thank it if anybody can help me with that.
You can get the refreshed BennuGD binaries with mod_chipmunk integrated here:
Please, understand that physics simulation can be a very processor-intesive process. If your game slows down too much, try reducing the number of active processes.
Saturday, February 26, 2011
BennuGD for Wii RC1!
It's time to release RC1 of BennuGD for Wii.
You can seed a list of changes below:
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!
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.
Friday, February 25, 2011
Puzsion for Wii RC1 [Updated with video]
After finding the cause to the FNT load bug, today I'm pleased to finally release Puzsion RC1 for Wii.
I'm calling this RC1 because the game still needs some testing and might undergo some minor tweaking to further adapt it to the Wii but to my knowledge there are no bugs and it's perfectly playable.
Please let me know in the comments section if you find any issue with the game so that I can fix it.
[Update] Cid2Mizard has created this video of the game in action:
Thanks for taking the time :) Also, I forgot to mention Hokuty and Amzg for their job in the game, all credit goes to them.
Hope you like it!
As to give you a small progress update, I'll upload a new binary version of BennuGD for Wii later today, which I'll be calling RC1.
Work on Firewhip for Wii/BennuGD in general is going great; together with the author I've squashed quite a few bugs related to the Fenix->BennuGD conversion and the game feels great in the Wii. Hopefully we'll be able to relesae it soon.
I'm calling this RC1 because the game still needs some testing and might undergo some minor tweaking to further adapt it to the Wii but to my knowledge there are no bugs and it's perfectly playable.
Please let me know in the comments section if you find any issue with the game so that I can fix it.
[Update] Cid2Mizard has created this video of the game in action:
Thanks for taking the time :) Also, I forgot to mention Hokuty and Amzg for their job in the game, all credit goes to them.
Hope you like it!
As to give you a small progress update, I'll upload a new binary version of BennuGD for Wii later today, which I'll be calling RC1.
Work on Firewhip for Wii/BennuGD in general is going great; together with the author I've squashed quite a few bugs related to the Fenix->BennuGD conversion and the game feels great in the Wii. Hopefully we'll be able to relesae it soon.
Wednesday, February 23, 2011
FNT loading seems to be fixed!
With quite a bit of help help from my brother, I've just found what appears to be the cause of the failure in font loading in the Wii!
I will do more testing tomorrow, but if this is really working we've killed the last standing big bug in the BennuGD port for the Wii.
Expect a RC very soon :)
PS: @beredezebe And Puzsion is working great now!!! I'll just make sure the musics are encoded at the right freq and release it in the next few days.
I will do more testing tomorrow, but if this is really working we've killed the last standing big bug in the BennuGD port for the Wii.
Expect a RC very soon :)
PS: @beredezebe And Puzsion is working great now!!! I'll just make sure the musics are encoded at the right freq and release it in the next few days.
Monday, February 21, 2011
Firewhip
I just took this photo of Firewhip running in my Wii.
To my knowledge, it's the first time this very cool game is being run in a Wii. There's still a lot of integration work to do (controls, mostly) and bugs to fix.
I just thought it'd be cool to show that the game seems to be running well with the cleanup I just finished doing to the new architecture (more on that to come, but to sum up I changed a bit the way the whole monolithic system works to make it even easier to mantain and updated the code to match the latest upstream version of BennuGD).
[Updated] This game's just so cool! I've adapted the controls for the Wii in a matter of minutes and spent a few minutes playing it... Things look nice!
Sunday, February 13, 2011
Vigoroth le livreur
Beredezebe lets me know that user blabla (cool nick!) has posted a note in the French BennuGD forum about a game he's ported from microlua to BennuGD. It's called "Vigoroth le livreur" (Vigoroth the delivery man, if I'm not mistaken) and you can read all about the game here [fr].
My french is not as good as it used to be, but from what I can understand, this is a collection of 4 mini-games where you must help Vigoroth with his deliveries.
As I'm still busy with my university exams, I haven't been able to test it just yet but I promise I'll write a post about the game after I've played it.
Meanwhile, you can get it from here, and you can see some screenshots for the game below:
My french is not as good as it used to be, but from what I can understand, this is a collection of 4 mini-games where you must help Vigoroth with his deliveries.
As I'm still busy with my university exams, I haven't been able to test it just yet but I promise I'll write a post about the game after I've played it.
Meanwhile, you can get it from here, and you can see some screenshots for the game below:
I'd like to congratulate blablabla for his game and thank beredezebe for letting me know AND for packaging the game for the Wii.
Also, as I said in the last post, the project is far from dead and right after I finish my exams I'm planning on doing a few nice improvements to the port. Right now I'm using the little free time I have to clean up the monolithic design I created so that it's much easier to mantain. I'll try to write more on that later.
Also, forum user Prg has created a physics module (wrapping around the Chipmunk physics library) which seems pretty cool. I'll try to bring that to the Wii, too.
You can have a look at what Chipmunk can do in the video below:
Happy coding!
PS: Sorry for the off-topic, but IMHO it's important.
Just using the screenshots I've posted above might be considered a copyright infringement and might be used as a reason to close this blog without any judiciary intervention once the new Sinde law [en] is passed in the Spanish Congress (even if the Congress rejected it last december, the two major parties have brought it back to life). They say it's a way to fight "piracy" but it could just as well be used for censorship. This is not good. If you live in Spain, you might consider not voting for PSOE, PP, CiU or any other party that supports censorship in the upcoming election.
[Update] And the law just got passed today. As I said, if you can vote in Spain, don't vote for them [es].
Monday, January 31, 2011
Tutorial in french
Just writing to note that work will resume after I finish my exams (I plan to work on fixing FNT loading, improving input handling and Wiimotion Plus support).
Anyway, if you are new to the project and speak french, you might want to check out beredezebe's tutorial about working with BennuGD in the Wii here.
Anyway, if you are new to the project and speak french, you might want to check out beredezebe's tutorial about working with BennuGD in the Wii here.
Tuesday, January 4, 2011
Beta 3 released
I've uploaded some binaries I like to call beta 3. Chnages from previous beta include:
- Proper support for the Wii Balance Board (see here for a usage example). Thanks to the guys from devkitpro for fixing this in the latest libogc 1.8.6
- Default sound frequency has been changed from 32KHz to 48KHz. Had to do it because newer versions of VLC refused to resample the audio to 32KHz. Also many popular audio programs seem to handle 48KHz sound much better than 32KHz ones. Please note that as OGG Vorbis sound playback was failing, you are now encouraged to use MP3 and module music formats instead.
- Updates from upstream Bennu. I've re-sync'ed many things from upstream BennuGD. Please note that this build corresponds to revision 146 from SVN, and not the current one (190). The changes between this versions derive from the SDL 1.3 support I added to trunk to gain iOS compatibility and I most probably broke something so latest code is not working as expected. I'll fix this soon.
- Bennu can now open websites if the user has installed the (free) Internet channel.
- Some other misc bugfixing.
Hope you enjoy the changes and the proper balance board support and sorry for changing the default sound freq. it was just needed.
You can find the binaries here.
Subscribe to:
Posts (Atom)