(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.
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 119 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.
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!).
Subscribe to:
Posts (Atom)
