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

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.

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

Postby CuteAlien » Thu May 07, 2015 4:50 pm

@Foaly: Absolutely agreed. Don't worry about devsh, he put's simd's in his daily muesli and renders it with shaders before breakfast ;-)
IRC: #irrlicht on irc.freenode.net
Code snippets, patches&stuff: http://www.michaelzeilfelder.de/irrlicht.htm
Free racer created with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
User avatar
CuteAlien
Admin
 
Posts: 8365
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany

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

Postby chronologicaldot » Fri May 08, 2015 5:23 am

Mel made a motion trails scene node. Ask, and he might let us put it in the engine.
viewtopic.php?f=9&t=47221&p=272700&hilit=ghostTrailSceneNode#p272700
User avatar
chronologicaldot
Competition winner
 
Posts: 546
Joined: Mon Sep 10, 2012 8:51 am

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

Postby thanhle » Fri May 08, 2015 5:55 am

chronologicaldot wrote:Mel made a motion trails scene node. Ask, and he might let us put it in the engine.
viewtopic.php?f=9&t=47221&p=272700&hilit=ghostTrailSceneNode#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
thanhle
 
Posts: 324
Joined: Wed Jun 12, 2013 8:09 am

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

Postby fargoth » Fri May 08, 2015 9:19 am

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..
fargoth
 
Posts: 19
Joined: Fri May 01, 2015 7:43 pm

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

Postby CuteAlien » Fri May 08, 2015 9:41 am

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).
IRC: #irrlicht on irc.freenode.net
Code snippets, patches&stuff: http://www.michaelzeilfelder.de/irrlicht.htm
Free racer created with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
User avatar
CuteAlien
Admin
 
Posts: 8365
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany

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

Postby devsh » Fri May 08, 2015 10:54 am

The only thing I'd advocate is using atomic reference counting to make some basic objects (meshes) safe to manipulate in a different thread
We chose to stream mesh data from Multiple OpenGL Contexts in many threads and do the other things, not because they are easy, but because they are hard! - JFK
User avatar
devsh
Competition winner
 
Posts: 1769
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK

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

Postby fargoth » Fri May 08, 2015 11:40 am

Hm, maybe just provide an RAII guard than.. There is a link for an implementation of one in these forums
fargoth
 
Posts: 19
Joined: Fri May 01, 2015 7:43 pm

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

Postby CuteAlien » Fri May 08, 2015 11:46 am

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.
IRC: #irrlicht on irc.freenode.net
Code snippets, patches&stuff: http://www.michaelzeilfelder.de/irrlicht.htm
Free racer created with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
User avatar
CuteAlien
Admin
 
Posts: 8365
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany

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

Postby Foaly » Fri May 08, 2015 2:29 pm

chronologicaldot wrote:Mel made a motion trails scene node. Ask, and he might let us put it in the engine.
viewtopic.php?f=9&t=47221&p=272700&hilit=ghostTrailSceneNode#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.
Foaly
 
Posts: 141
Joined: Tue Apr 15, 2014 8:45 am
Location: Germany

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

Postby devsh » Fri May 08, 2015 4:01 pm

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)
We chose to stream mesh data from Multiple OpenGL Contexts in many threads and do the other things, not because they are easy, but because they are hard! - JFK
User avatar
devsh
Competition winner
 
Posts: 1769
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK

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

Postby hendu » Sat May 09, 2015 7:57 am

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.
hendu
 
Posts: 2587
Joined: Sat Dec 18, 2010 12:53 pm

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

Postby Granyte » Sat May 09, 2015 9:36 pm

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
Granyte
 
Posts: 846
Joined: Tue Jan 25, 2011 11:07 pm

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

Postby devsh » Tue May 12, 2015 1:50 pm

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?
We chose to stream mesh data from Multiple OpenGL Contexts in many threads and do the other things, not because they are easy, but because they are hard! - JFK
User avatar
devsh
Competition winner
 
Posts: 1769
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK

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

Postby thanhle » Wed May 13, 2015 4:02 pm

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.
thanhle
 
Posts: 324
Joined: Wed Jun 12, 2013 8:09 am

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

Postby sunnystormy » Wed May 27, 2015 10:58 pm

Now that VULKAN has been announced by the Khronos Group, has there been any consideration in implementing this API once it's publicly released?
My blog: http://osgdp.wordpress.com "The Open-Source Game Development Pipeline"
sunnystormy
 
Posts: 98
Joined: Mon Jun 02, 2014 2:32 am
Location: Washington, D.C.

PreviousNext

Return to Open Discussion and Dev Announcements

Who is online

Users browsing this forum: No registered users and 1 guest