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 Granyte » Thu Feb 18, 2016 4:49 pm

DX11 is almost completely fixed the only thing remaining is the text scenenode is depth writing for no good reason.

But as i told befor the patch is already massive because the whole material system was poorly done and will probably only get worst when i fix the textscenenode
Granyte
 
Posts: 846
Joined: Tue Jan 25, 2011 11:07 pm

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

Postby lumirion » Fri Feb 19, 2016 2:50 am

In potential vulkan support and/or dx11 what about using a render target that uses per-pixel linked lists of fragments to provide order independent transparency by default. Any GPUs with over 100mb ram should handle it just fine.
lumirion
 
Posts: 79
Joined: Tue Sep 13, 2011 7:35 am

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

Postby hendu » Fri Feb 19, 2016 9:35 am

Radeon R200 series, introduced in 2001, had 128mb VRAM cards.
hendu
 
Posts: 2587
Joined: Sat Dec 18, 2010 12:53 pm

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

Postby devsh » Fri Feb 19, 2016 9:37 am

In potential vulkan support and/or dx11 what about using a render target that uses per-pixel linked lists of fragments to provide order independent transparency by default. Any GPUs with over 100mb ram should handle it just fine.


Thats too high-level, I think its something the developer should decide or at least have very fine grained access to

Remember, memory is not primary concern, performance is.
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: 1759
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK

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

Postby lumirion » Sat Jul 30, 2016 4:32 pm

what about replacing type enumerations with some sort of type registration? That way deriving new extensions from the defaults would not require modifications to the Irrlicht source and the engine could dynamically accept new types. The cost would be slight over head of storing the type along with an int identifier.

cpp Code: Select all
 
RegisterableTypeEnum
{
     string type;
     int ID;
     operator int*() {return ID;}
}
 
lumirion
 
Posts: 79
Joined: Tue Sep 13, 2011 7:35 am

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

Postby kornwaretm » Thu May 18, 2017 3:42 am

how about scalable timer. lets say device->setGlobalAnimatorTimeScale(0.5); and all animation speed scaled down to half speed. device->setGlobalAnimatorTimeScale(0.0); and all animation paused, particle emiter stop emitting etc.
kornwaretm
Competition winner
 
Posts: 187
Joined: Tue Oct 16, 2007 3:53 am
Location: Indonesia

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

Postby CuteAlien » Thu May 18, 2017 10:06 am

@kornwaretm: ITimer::setSpeed should do that.
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: 8322
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany

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

Postby kornwaretm » Fri May 19, 2017 7:25 am

ow it is already exist this whole time :oops:
kornwaretm
Competition winner
 
Posts: 187
Joined: Tue Oct 16, 2007 3:53 am
Location: Indonesia

Previous

Return to Open Discussion and Dev Announcements

Who is online

Users browsing this forum: No registered users and 1 guest