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

[hendu]

The biggest thing that should happen is that irrlicht should be threaded or at least THREAD-SAFE, because thats the way the GPU APIs are moving right now (even new OpenGL rewrite). I shouldnt have to use my time in my precious rendering thread to poll for input, and be forced to load assets (textures, models) at the expense of issuing rendering commands.

Locking a mutex in every irr function would add horrible overhead.

I dont see why we need the Software Renderer (which is completely bloody useless, singlethreaded, buggy and missing more than a fair share of even OpenGL 1.4 capabilities!) or dx8 (seriously?, what do you develop for - GeForce 4MX? - there are actually few GPUs that only support dx8!)

Reading comprehension man I wrote that I *would* drop dx8 and one sw driver.

Re blending - huh? It's been per-material in 1.7 already.

[kklouzal]

Use Premake for building project files.
I can go ahead and set all of this up if it's something the project is willing to adopt.

[Brkopac]

I'm loving the flow of ideas, here are a few things off the top of my head that I can think of:

• Better organization of source and include files (no more giant list)
• Proper use of the Interface idiom in file naming (no more tagging files that aren't interfaces as interfaces)
• Removal of ifdefs that are compiler config options (use an actual build system to only build what is required)
• Removal of CWin32, CX11 systems (replaced with SDL2)
• STL Support
• Minimum compiler support raised to VS2008
• Cleansing of the SW Driver and DX8
• Better implementations of the scene graph (potentially some variations of scene graphs)
• No more fixed pipeline

[devsh]

The no-more fixed function pipelien thing needs big overhauls, its not just about removing FF-pipeline, you need to either break compatibility and provide only the most basic materials, or reimplement all the irrlicht materials without breaking the material deriviation (the baseMaterial in add shader confuses the gently caress out of me and many others, dont pretend you can apply one material on top of another... simply let people set the blend function for the material and attach the actual MESH to a proper render pass instead of trying to figure it out with quasi-deriviation of materials, plus the "parent" shader callback actually fucks up render states).

[devsh]

gently caress this poop
I'm making SIMD vector classes right now, will be in code snippets within 2 days... doesnt break existing interface and there is a _IRR_COMPILE_WITH_SIMD_ flag

once tested it can get added into repo no problem

[Brkopac]

gently caress this poop
I'm making SIMD vector classes right now, will be in code snippets within 2 days... doesnt break existing interface and there is a _IRR_COMPILE_WITH_SIMD_ flag

once tested it can get added into repo no problem

Is there an existing benchmark (against current irrlicht code) that shows how much of a performance increase this can bring to the table? Granted there will probably be one, but it would be nice to have a visual aid to really understand the benefit of the addition. My 2 cents anyway.

[devsh]

there is a benchmark.... 50k particle emitters and animators in Build A World

performance increase is 3-4x

[kklouzal]

Thank you very much devish, can't wait for these! I hope they get patched into the engine quickly

[devsh]

head over to http://irrlicht.sourceforge.net/forum/v ... =9&t=50230

[kklouzal]

To keep on topic, SSE3 for Irrlicht 2.0 is a bad idea, there are way too many devices still in existence that can't support SSE3.
Bringing SSE2 optimizations into Irrlicht 2.0 however sounds like a great idea!

[devsh]

mobiles and PS3 dont have x86 so SSE2 wont work on them
ARM v7 upwards have their own SIMD instructions

basically need to compile the engine with at least 3 different SIMD flags (SSSE3, ARM, no SIMD) and code around that

SSSE3 support is no problem because if someone doesnt have the CPU, they can compile without the flag

[hendu]

Without runtime detection, you'd have to ship two binaries. Hardly an improvement.

[devsh]

*sigh* no comment

[Brkopac]

Hey guys. Lets try and keep the thread on track, we're just spit balling some ideas here.

[Darktib]

My 2 cents:

- support from VS2008 (no more 2005 and before), meaning no C++11
- if we want portability, then we need to keep irrlicht containers. Implementation of the STL is not very good on some platforms (I'm thinking of android for example)
- SDL2. Yes. Maybe not drop Win32/X11 devices though
- GLM. Plain no. To be working everyday with this lib, it is very limited, eigen would be far better, however eigen is a bit of a pain memory-wise.
- maybe drop a software renderer (but I think we need to keep one at least)
- keep basic picking (I personnally full collision handling should be in a separate lib)
- keep gui but don't make it evolve (instead maybe integrate / just recommend something like GWEN)
- and finally: use CMake for the build script. notably don't put everything in the /source/Irrlicht subfolder, this is quite messy