Page 9 of 11

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

Posted: Thu May 07, 2015 4:50 pm
by 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 ;-)

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

Posted: Fri May 08, 2015 5:23 am
by 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

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

Posted: Fri May 08, 2015 5:55 am
by thanhle
chronologicaldot wrote: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

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

Posted: Fri May 08, 2015 9:19 am
by 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..

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

Posted: Fri May 08, 2015 9:41 am
by 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).

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

Posted: Fri May 08, 2015 10:54 am
by 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

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

Posted: Fri May 08, 2015 11:40 am
by fargoth
Hm, maybe just provide an RAII guard than.. There is a link for an implementation of one in these forums

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

Posted: Fri May 08, 2015 11:46 am
by 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.

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

Posted: Fri May 08, 2015 2:29 pm
by Foaly
chronologicaldot wrote: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.

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

Posted: Fri May 08, 2015 4:01 pm
by 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)

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

Posted: Sat May 09, 2015 7:57 am
by 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.

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

Posted: Sat May 09, 2015 9:36 pm
by 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

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

Posted: Tue May 12, 2015 1:50 pm
by 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?

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

Posted: Wed May 13, 2015 4:02 pm
by 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.

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

Posted: Wed May 27, 2015 10:58 pm
by 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?