Irrlicht 2.0 - What's in store for the future!

[CuteAlien]

I suspect (don't know) the reason why we might not have material names could be that it would introduce dynamic memory management into SMaterial. Or a fixed-length string which always scares coders. Well, or a pointer to names managed in some other place which is also a little ocnfusing. But yeah - names would be useful. Same with a custom data variable which is _not_ used by any Irrlicht material. I could have used that very often already.

[devsh]

in BaW-Irrlicht we have a void* pointer which doesnt get copied on assignment or copy ctor (instead set to NULL)

[FloatyBoaty]

I vote for a QtCreator project - all the targets in one ide: Linux, Apple, Microsoft, Android, Blackberry.

And an OpenCL ray-trace driver.

[devsh]

hahaha OpenCL ray-trace driver, that warrants a construction of an entire new engine

[ent1ty]

And an OpenCL ray-trace driver.

you can have this one: https://github.com/LoganKelly/LOLTracer

[FloatyBoaty]

hahaha OpenCL ray-trace driver, that warrants a construction of an entire new engine

True, but this is the direction graphics should take.

[FloatyBoaty]

And an OpenCL ray-trace driver.

you can have this one: https://github.com/LoganKelly/LOLTracer

Cool. I'll have to take a look.

[Darktib]

Haha, a ray-tracer in lolcode...

hahaha OpenCL ray-trace driver, that warrants a construction of an entire new engine

True, but this is the direction graphics should take.

Actually, that will probably not happend before at least a decade. Rasterizers are more complex than pathtracers, but pathtracers are way more costly - even on a GPU. And any improvement on the pathtracing side will also improve the rasterizing side - so don't expect a big change too soon.
(also, the irrlicht architecture is not quite adapted to a CUDA/OpenCL pathtracer - plus that would be a big module to maintain)

I vote for a QtCreator project - all the targets in one ide: Linux, Apple, Microsoft, Android, Blackberry.

If this is another one (that is vs + qtCreator + C::B), then ok, but I'm against it if it is exclusive.
The best thing IMHO is to have a script using premake (as the other seems to dislike CMake).

[FloatyBoaty]

If this is another one (that is vs + qtCreator + C::B), then ok, but I'm against it if it is exclusive.
The best thing IMHO is to have a script using premake (as the other seems to dislike CMake).

QtCreator is not as easy to work with as I had hoped. Premake seems like a good option.

[Granyte]

isn't QT the abomination of a library that eats 2GB of hdd just to compile some demos?

it's an other abomination ....

[FloatyBoaty]

isn't QT the abomination of a library that eats 2GB of hdd just to compile some demos?

it's an other abomination ....

I've been using CB, but have been having some issues; probably because I'm using the development build.
I tried to compile CodeLite but keep getting stuck with the EclipseCXX something cpp giving an error that "wxDir" has not been declared in the scope.

[Brkopac]

isn't QT the abomination of a library that eats 2GB of hdd just to compile some demos?

it's an other abomination ....

QT is widely considered one of the best, if not the best, cross-application framework in existance. I'd hardly call it an abomination :/

[Darktib]

Qt is probably the best GUI library out there - it is also not that big, just dozens of MB

[ent1ty]

I don't see what's wrong with make
Irrlicht makefile is pretty cool, has dependency checks that recompile files only when necessary and afaik works flawlessly on every linux distro (and also possibly with mingw?)

[Darktib]

Make is cool, it can also brew coffee. However, if I want to use visual studio then makefile are not really good - as I want to control the build step from the IDE, not from a file. That's why solutions like cmake or premake are better