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

[CuteAlien]

@Foaly: Absolutely agreed. Don't worry about devsh, he put's simd's in his daily muesli and renders it with shaders before breakfast ;-)

[chronologicaldot]

Mel made a motion trails scene node. Ask, and he might let us put it in the engine.
http://irrlicht.sourceforge.net/forum/v ... de#p272700

[thanhle]

Mel made a motion trails scene node. Ask, and he might let us put it in the engine.
http://irrlicht.sourceforge.net/forum/v ... de#p272700

There is a minor bug with that motion trails. If you perform a circle trail, vertices becomes a line at certain direction.

Regards,
thanh

[fargoth]

I was just wondering... Is there any work being done towards a 2.0 version?

I agree with others here who stated Irrlicht should switch to usage of modern smart pointers (shared, weak and unique) instead of the IReferenceCounted - this would make everything much easier to handle..

[CuteAlien]

No plan for using smart-pointers so far. Not even sure if it's really a good idea for the library (might make wrappers to other langauges more complicated).

[devsh]

The only thing I'd advocate is using atomic reference counting to make some basic objects (meshes) safe to manipulate in a different thread

[fargoth]

Hm, maybe just provide an RAII guard than.. There is a link for an implementation of one in these forums

[CuteAlien]

Yeah, I wrote one of those ;-) But I suppose it's easier to integrate it with modern c++ shared pointers the way it's now than if we would add an Irrlicht shared pointer implementation. We could maybe add it as example for people who don't find it in the forum, but it's rather a c++ specific implementation detail than something about the engine itself so I'd prefer not to.

[Foaly]

Mel made a motion trails scene node. Ask, and he might let us put it in the engine.
http://irrlicht.sourceforge.net/forum/v ... de#p272700

I looked at it. The one I decided to write was meant to work differently, but adding wind is interesting. I may add that as well.

[devsh]

shared pointers =/= threadsafe ref counting

the refcounting classes are unsafe to grab in one thread and drop in another, so memory leaks due to multithreading are possible

modern C++ pointers dont exactly help here, add to that that Nvidia CUDA compiler clashes with gcc c++x11 and MSVC didnt do C++x11 until recently and you have a clusterfuck

atomic counters are nice, built into x86 and ARM and they have nice compiler intrinsics to use them, and changing refcounting to atomic only takes 8 or 16 lines tops (thats if you want to support gcc, msvc apple compiler, intel and x86 and arm)

[hendu]

Atomic counters won't help you if you're too racy, the other thread might drop the count to zero from under you.

That is, you will have to control the lifetime in another way anyway.

[Granyte]

If a thread drop the refcound under your feet then some one thier does
while(true)
x->drop();

or you didn't properly implement grabbin when using and dropping when done

Also irrlicht igniored threading as long as it could with the next generation of API becoming natively threaded irrlicht will never be able to handle this in it`s current form

[devsh]

You can use an atomic counter as a SRW lock with spinwaiting which doesn't matter much as only waits would be:
1) when object is in use by other threads, and another thread wants to drop it - the dropping thread would have to wait (spin && sleep)
2) when object is being dropped and another thread wants to do something with it - the doing thread does a spinwait and no sleeping and after waiting it returns from the function immediately

======================================================================================================

Anyway, has anyone thought of keeping irrlicht LSB conformant?

[thanhle]

Maybe use coroutine. Then fire event to add/delete event or what ever if needed.

But then again this is the same as adding an event to manage delete and addition in the main loop.

I might word it wrongly, just ignore me if it is wrong. Don't blame me, because I'm not a programmer.

[sunnystormy]

Now that VULKAN has been announced by the Khronos Group, has there been any consideration in implementing this API once it's publicly released?