What happened to Irrlicht?

[obadakhamis]

Is irrlicht discontinued or what? The last update was in 2013

[thanhle]

The engine is in an update state.
I think the guys are working hard adding new ogl and dx11.

1.9 will release when everything is in a stable state.

Look in trunk for latest addition.

Regards
thành

[obadakhamis]

Thanks.

[CuteAlien]

DX11 will not be in 1.9 - only OGL-ES (aka Android & iPhone). And yeah, that is long overdue.

But you can always work with svn trunk which contains the latest version. And we try to keep that stable all the time.

[REDDemon]

Irrlicht is the only opensource engine that is still massively used. Ogre didn't have so much luck in recent times

[Granyte]

Much of the action is in the FVF branch

[AReichl]

> Irrlicht is the only opensource engine that is still massively used. Ogre didn't have so much luck in recent times

aha - nice to hear. I am interested in such "comparisons". Where do you have the info from?

[CuteAlien]

Yeah, I read that on the internet... (from REDDemon in this thread - does that count?) ;-)

[REDDemon]

Well you can see how many users are active in Ogre forum and the activity in subversion/git to get an idea (wich is my source of information). Apart that I just think Ogre has many engineering issues so that if you wanna try it you'll know what to expect:

- first of all the build system: Ogre uses Cmake but to get it working with mingw requires hacks in many places (wich basically defeats the purpose of using cmake ...).
- Obese, there are classes that have dozen of methods (1 random class has 110 methods: http://www.ogre3d.org/docs/api/1.9/clas ... ortal.html ).
- preprocessors everywhere, also "pre" and "post" header files... (wat?!)
- there is a webgl demo for ogre wich is broken (or at least on my PC don't load asynchrounously what should load)
- plugin system (so basically, ehy why instead of liking a DLL at compile time don't you load it at runtime? O_O that's usefull for something like GIMP where you load modules.. later. but most Ogre games are just 1 standalone package)

[Kojack]

and the activity in subversion/git to get an idea (wich is my source of information).

Primary Ogre development of the 2.0 branch (with AZDO (Approaching Zero Driver Overhead), new physically based shading material system, etc) is currently private. A Community Tech Preview of 2.0 will be released soon.

preprocessors everywhere, also "pre" and "post" header files... (wat?!)

Are you talking about OgreHeaderPrefix.h and OgreHeaderSuffix.h? These make it easier to temporarily disable annoying warnings without leaking into non ogre code.

Obese, there are classes that have dozen of methods (1 random class has 110 methods: http://www.ogre3d.org/docs/api/1.9/clas ... ortal.html ).

I don't think "dozen" is really that bad.
In irrlicht, the IGUIElement has 94 methods, CMatrix4 has 83, IAttributes has 145.

plugin system (so basically, ehy why instead of liking a DLL at compile time don't you load it at runtime? O_O that's usefull for something like GIMP where you load modules.. later. but most Ogre games are just 1 standalone package)

You can link the plugins statically at compile time, they don't have to be dynamically loaded.
Ogre 2.0 has also scrapped a lot of plugins. All scene manager plugins are gone. One of the renderers will be gone soon too (and maybe a second). The "obese" class you linked to above is part of a plugin that doesn't exist in 2.0.

[REDDemon]

Well also irrlicht has some big class, in general those are smaller. The most important point for users is still the build system, if they can't get it to build they can't use it. For the warnings, it is no excuse, the project must compile without warnings at all.

[Kojack]

The most important point for users is still the build system, if they can't get it to build they can't use it.

I don't use MingW, so I don't really know what issues are involved there.

For the warnings, it is no excuse, the project must compile without warnings at all.

Irrlicht disables warnings 4284, 4786, 4244 and 4996.

[REDDemon]

I don't use MingW, so I don't really know what issues are involved there.

Short version: it does not compile out-of-the-box with mingw.

[Kojack]

I don't use MingW, so I don't really know what issues are involved there.

Short version: it does not compile out-of-the-box with mingw.

I did a little testing.
It seems a user submitted patch did break mingw support. But that was fixed months ago in the default (1.10) branch by the team member who supports mingw. I just did a mingw build without any "hacks in many places" (or any changes to ogre or mingw at all). Just cmake then make, no problems and runs fine. So it does work out of the box with mingw.

I didn't try the directx 11 renderer. I've read that mingw doesn't have dx11 support so I unticked that in cmake. No other changes from the default were made.

(Not trying to hijack the thread)

[REDDemon]

lol. 1.1 is a preisorical version. I mean Ogre 1.8.1... against GCC 4.9.2

cmake then make not work;) (only gl renderer)