irrpache - yet another fork of irrlicht

[zenaku]

Ever since I started irrlua, I've been debating whether I should make a custom version of irrlicht that would be easier to bind to lua, or should I use the default build of irrlicht and do a complex/difficult binding instead. So far I've been doing the later, and it's been tedious. Some issues would simply go away if I could only tweak the API a little, but I can't, so it hurts.

I was thinking of forking irrlicht and patching it to the point to where the Lua binding could be automated and would no longer need to be maintained, or at least reduce the maintenance greatly. It could also be tweaked for a SWiG binding, and that would give even more language options.

There are a number of other projects that I also wanted to include in the fork, mostly patches that have been submitted to irrlicht but never accepted. There are some really good patches that simply have not been accepted that I would put into the fork. I'm thinking of the name irrpache in honor of irrlicht and apache. I would try, in the spirit of apache, to create a game engine out of irrlicht + all the great patches, code snippets, shaders, etc people have sent in. I plan on gratuitously stealing code from other projects that allow it (bsd license, zlib license, etc). The fork should be released under the LGPL as it is the least common denominator of the various licenses. LGPL can steal from BSD, but BSD can't from LGPL, so ultimately LGPL will always end up with a larger code base to pool from (and I want to use OpenAL which is LGPL ).

To the 5 irrlicht namespaces, a few more will be added:

irr.audio -- rebranding / irrlichtifying of OpenAL.
irr.physics -- rebranding / irrlichtifying of either ODE or Bullet (haven't decided)
irr.interop -- scripting stuff goes here (irrlua/jirr stuff)

The purpose of rebranding the APIs is to provide a consistent engine across the board. I had initially created bindings for Irrlicht and ODE, and you could use them together in Lua, but a type translation layer needed to be created in order to do it because as an example ODE vector != Irrlicht vector. Not the most efficient solution. A consistent engine would solve that problem.

Finally the source itself would have a consistent build system across platforms. The target is Eclipse with the CDT using gcc as the compiler. Eclipse + CDT runs everywhere, so does gcc, so it's a natural cross platform/no issues setup, and it's completely free. I looked at Code::Blocks and it works really great but is just not as well supported as Eclipse/CDT is.

I've split up irrlicht source into modules and made Eclipse/CDT projects for each module. I have irr.core.so, irr.io.so, irr.gui.so, and irr.video.so already working. All the source has been split into different directories instead of one huge folder of source like it is now. Someone please let me know if this is a good idea and if I should continue with it. Also I'm completely open to suggestions for anything and everything about the project.

[Luben]

Is it possible to use irrLua for scripting in a host irrlicht application? Like creating the device and stuff in c++ and the use irrlua to do just some things, like, adding scene nodes from within a lua script executed by the host?

[zenaku]

Code: Select all

Is it possible to use irrLua for scripting in a host irrlicht application? Like creating the device and stuff in c++ and the use irrlua to do just some things, like, adding scene nodes from within a lua script executed by the host?

Yep it sure is. You don't need to use the lua interpreter to use irrlua. Lua has a C api that you can call from your C++ program.

You just do something like:
(from http://www.lua.org/pil/24.1.html )

Code: Select all

#include <stdio.h>
    #include <lua.h>
    #include <lauxlib.h>
    #include <lualib.h>
    
    int main (void) {
      char buff[256];
      int error;
      lua_State *L = lua_open();   /* opens Lua */
      luaopen_base(L);                /* opens the basic library */
      luaopen_table(L);                /* opens the table library */
      luaopen_io(L);                    /* opens the I/O library */
      luaopen_string(L);               /* opens the string lib. */
      luaopen_math(L);                /* opens the math lib. */
          
      while (fgets(buff, sizeof(buff), stdin) != NULL) {
        error = luaL_loadbuffer(L, buff, strlen(buff), "line") ||
                lua_pcall(L, 0, 0, 0);
        if (error) {
          fprintf(stderr, "%s", lua_tostring(L, -1));
          lua_pop(L, 1);  /* pop error message from the stack */
        }
      }
    
      lua_close(L);
      return 0;
    }

That's a basic, line by line interpreter. With a little work you could pass your IrrlichtDevice pointer created in C++ into the lua state created above. Inside Lua, you'll already have an IrrlichtDevice * that you can reference and 'add scene nodes to' or what not. Once you have the device in Lua, you'll need irrlua to actually do anything useful with it. To use it you'd use ' require "irrlua" ' in your script before accessing the Device.

If you wanted it to be completely internal you could hard code the script into a C++ string and pass it in to Lua without ever reading any files.

Code: Select all

lua_loadstring("insert your lua code here");

You can do this with most scripting languages. The difference with Lua is that it was designed to make it very simple to do.

[pinballwizard]

This sounds interesting. A couple of thoughts...

Wouldn't a fork make it harder to keep up with new Irrlicht developments? There's also the issue of community - e.g. Lightfeather, an Irrlicht fork, seems to have far fewer users than the main Irrlicht trunk. So forking Irrlicht would likely (at first, anyway) reduce the audience size. Will compatibility with Irrlicht be maintained, or discarded?

Regarding licensing, I think Irrlicht's ZLIB/MIT-style license has wider applicability (usable on consoles or in a commercial game company) and could increase adoption and build a larger audience. LGPL could limit adoption rate and result in a smaller audience, but ensure openness of the Irrpache core. My personal preference (which, admittedly, is tainted by having worked as a contractor in the game programming industry and having had to assume personal responsibility in case of any possible legal dispute over code licenses) is an Irrlicht-style license or self-written code for my core game architecture. It's a very conservative position, I know, but having to assume personal legal liability in case of code licensing problems makes some people like myself a bit wary about using LGPL code in situations where it might cause real legal trouble. Of course, people like me might not be your target audience for Irrpache

One option regarding licensing would be a modular approach, e.g. the IrrLua part, which interfaces with Irrlicht-licensed code only, could be Irrlicht-licensed. The Lua-OpenAL part, which interfaces with LGPL code, could be LGPL. The user of the combined Irrpache project could decide which modules to use - if they can live with LGPL, they can use all of the modules; if they can't, then they can only use the Irrlicht-licensed modules.

Also, a modular approach could allow or even encourage custom development of Irrpache modules (e.g. additional physics modules for other physics libraries, or other sound libraries, etc).

Regarding the build platform, does Eclipse/CDT support cross-compilation, e.g. from Linux to Windows? Right now I have my Irrlicht and IrrLua set up such that, from my Linux box, I can build a ready-to-run Linux or Windows executable. This, of course, all runs from the command line with Makefiles. I would hope that an environment such as Eclipse/CDT would support cross compilation targets as well as native targets.

Finally another thing to think about is tool support: the best engine in the world is useless if you can't get art/assets/game objects/physics properties/etc into it. I'm a big Blender fan myself, as I suspect many Irrlicht users are.

Anyway, just some thoughts for now... I'm also toying around with different bits and pieces of game architecture and how best to combine them. At some point, I even hope to make a game

[omar shaaban]

ya i think it is a cool idea but yet so haarrdd.........

[bitplane]

Hmm I don't think a fork is such a good idea, I voted against it. also it's really bad idea to use a different license for a fork, specially a viral one like the LGPL. it would mean that every person who wants to use some of your improvements in a closed source project will have to write to you and ask you for permission.

I'd much rather see things go the other way - some kind of scripting interface for any language, so people can share generic scriptable extensions to Irrlicht and users can use whatever language they like.

regarding the patches, which ones do you need?

[pinballwizard]

Regarding the splitting of the code into separate libraries, I think the criteria for whether or not this is a good idea is the dependencies between the thus-created libs. Is every lib needs every other one to function, there's no point, IMHO, in a split. If, however, every library can be individually used without any of the others, then a split makes sense. Most likely the real-world situation lies somewhere between these two extremes. It's a judgment call, then, about whether the libs are "independent enough" from each other to warrant a split. Are they?

[bvanevery]

Generally speaking, I think you're committing community suicide.

"irrpache" is a terrible name. Sounds like an Italian appetizer.

Finally the source itself would have a consistent build system across platforms. The target is Eclipse with the CDT using gcc as the compiler. Eclipse + CDT runs everywhere, so does gcc, so it's a natural cross platform/no issues setup, and it's completely free. I looked at Code::Blocks and it works really great but is just not as well supported as Eclipse/CDT is.

Forcing an IDE and a compiler is a way to ensure that lotsa people won't touch your work. Try instead something like CMake, which can handle lots of different compilers and IDEs. People in the CMake community are currently using external makefiles with Eclipse. It's not as elegant as people might like, but it's not terribly difficult and people are succeeding at it. Some abstraction work has recently been done in the CMake internals to make adding new IDEs easier, so do think there will be forward progress on Eclipse support in the coming year. Meanwhile, CMake does traditional makefiles and MS Visual Studio files exceedingly well.

[roxaz]

idea sounds quite good but i dont think many users would use it. i wont too. it wont be official irrlicht so its baaaad. official stuff is gooood

[Dukdalf]

Better invest your time in making good additions to the official code of irrlicht then concentrating on making your own branch.

What will you do if your set of add-on's isn't compatible with irrlicht 1.4 or higher? It is bound to happen!

Although it sounds cool, I won't use it!

[Midnight]

a one man band doing a major scripting wrapper project thats a so called irrlicht fork with a name thats half completely unrelated.

no comment... oh wait too late.

bwt you lost me at lgpl.


the question isn't if you should do it... but why.. and why turn irrlicht into a crap lisence.. do you really expect that to work?

does anyone really want this?

you have gotten me interested in lua though so if I ask you for permission when you create this and it actually works... am I going to get it? something tells me.. not without a cut I'm sure..

[zenaku]

Yeah, in the end it's not a good idea.

The reason for the lgpl is because it's the least common denominator. You can add zlib licensed code to lgpl'd code but not the other way around. I actually like the irrlicht license better. At least It's better for developers.

"you have gotten me interested in lua though so if I ask you for permission when you create this and it actually works... am I going to get it? something tells me.. not without a cut I'm sure.."

If it was lgpl I couldn't stop you

I have already made a branch of irrlicht-1.3 that builds under eclipse/CDT, split into 5 modules, e.g. irrpache.core.so, irrpache.scene.so, etc. I moved all the source into sub folders (currently irrlicht source is all in one monolithic folder layout). I still needed to update the API to make it easy to automate the script bindings.

Ultimately it's a lot of work and I figure my time would be better spent contributing to the main irrlicht project instead of splintering off the 100,001th sourceforge project.

Instead I've been working on making irrlua work with irrlicht-1.3.1 but it's been slow going. I'm trying to make the the process more automated but that ends up happening slower at first. Parsing c++ isn't fun

Lua is definately one of the coolest scripting languages. I like other scripting languages like python, perl, ruby, etc but I always end coming back to Lua for it's simplicity and elegance.

[mhack]

Lua is definately one of the coolest scripting languages. I like other scripting languages like python, perl, ruby, etc but I always end coming back to Lua for it's simplicity and elegance.

I agree with you on that. I'm sold on Lua for its simplicity and power. It's so small you can really understand exactly what's going on. When faced with the challenge of trying to integrate a scripting language with C++, that has been a major plus for me. I wouldn't dream of digging into the guts of Python to resolve some problem in my project, but looking at and understanding Lua internals is no problem.

As far as integrating it with Irrlicht, I don't see the need for a branch. I've been having good success using Lua and swig to interface with Irrlicht. There have been a few difficulties, such as with nested classes, but I've been able to use the workarounds that are available with swig. swig is very mature and powerful, once you get over the initial learning curve. I think more people should consider it as a scripting option for Irrlicht.

[zenaku]

As far as integrating it with Irrlicht, I don't see the need for a branch. I've been having good success using Lua and swig to interface with Irrlicht. There have been a few difficulties, such as with nested classes, but I've been able to use the workarounds that are available with swig. swig is very mature and powerful, once you get over the initial learning curve. I think more people should consider it as a scripting option for Irrlicht.

Ok, after reading this and after looking over Pyrr, I'm going to try to move IrrLua over to using swig instead of tolua++. With any luck we will be able to combine efforts. Initially it will be a huge step backwards for irrlua but sometimes you have to do that in order to move forward.

Update: Creating a Lua binding for Irrlicht using SWiG is disgustingly simple. It took all of 4 hours to get something basic working. SWiG certainly has come a long way.

[mhack]

With any luck we will be able to combine efforts. Initially it will be a huge step backwards for irrlua but sometimes you have to do that in order to move forward.

I would be happy to contribute some of my swig-lua-irrlicht stuff to a suitable project such as IrrLua, or perhaps just some tutorials/demos. Let me know if you are interested.