I think its time for irrlicht dev team to put new people on board so the engine can get developed faster and with more features such as: mutlithreading, better GUI, better yet just make irrlicht a game engine instead of render since it doesn't do much of a good job rendering besides fast speeds.
Don't get me wrong I love irrlicht I'm using it with a commercial project in my studios but i think it's time for a change. 2010 not 2009
We are trying to produce next gen graphics while still trying to give irrlicht engine some PR, but the down side is very buggy and has a less feature set.
Tell me what you guys think.
Upgrades for irrlicht/ Time for a change
Do you realize the tone that your post sets? It's a very condescending and elitist attitude, I just hope you realize. So don't be surprised if you get a few nasty replies. You seem to be "whining" like an ungrateful child and throwing all the work, that the current development team has done, back into their face.
You say that you are working with a studio on a commercial project and using Irrlicht. That leads me to make two assumptions: you have quite a bit of experience with Irrlicht, and you are not an ignorant software engineer. Now given those two assumptions, you do realize the implications of what you are asking, correct? If your answer is yes, then great! Start writing up some design documents and post them up so the community and the development team can analyze them. If the answer is no, then I think you have to come to realization of how much you are asking of such a small development team.
Now what do I think, personally, on the topics you have raised:
1. Multi-threading - What exactly do you want multi-threaded? How will it help you? Are you just looking to add buzzwords to Irrlicht's list of features?
2. Better GUI - Honestly, I don't even think Irrlicht should have a GUI. That's just my personal opinion. It's not worth the development time to manage it when the other solutions out there are developing at a faster rate.
3. Irrlicht Game Engine - So you want them to spread there efforts even further? You want them to maintain code related to physics, audio, networking, etc. while simultaneously learning all the knowledge required to implement those technologies correctly and satisfying the infinite needs of people like you? Sounds great...especially when we already have all these great community projects around to help you out...
If Irrlicht isn't fitting your needs to produce "next-gen" graphics, then it's either time for you to put up, switch engines, or shutup. Simple as that.
You say that you are working with a studio on a commercial project and using Irrlicht. That leads me to make two assumptions: you have quite a bit of experience with Irrlicht, and you are not an ignorant software engineer. Now given those two assumptions, you do realize the implications of what you are asking, correct? If your answer is yes, then great! Start writing up some design documents and post them up so the community and the development team can analyze them. If the answer is no, then I think you have to come to realization of how much you are asking of such a small development team.
Now what do I think, personally, on the topics you have raised:
1. Multi-threading - What exactly do you want multi-threaded? How will it help you? Are you just looking to add buzzwords to Irrlicht's list of features?
2. Better GUI - Honestly, I don't even think Irrlicht should have a GUI. That's just my personal opinion. It's not worth the development time to manage it when the other solutions out there are developing at a faster rate.
3. Irrlicht Game Engine - So you want them to spread there efforts even further? You want them to maintain code related to physics, audio, networking, etc. while simultaneously learning all the knowledge required to implement those technologies correctly and satisfying the infinite needs of people like you? Sounds great...especially when we already have all these great community projects around to help you out...
If Irrlicht isn't fitting your needs to produce "next-gen" graphics, then it's either time for you to put up, switch engines, or shutup. Simple as that.
TheQuestion = 2B || !2B
I'm not trying to be mean nor having an attitude towards no one i'm just stating my opinions.....no need to get all up tight...I really appreciate what the development team has done but it wouldn't hurt to add people to their squad to help out the engine. I'm sure if the developers focus only on multi threading then everyone would be happy even though they are with release 1.7.
I'm just curious and wander if things will ever change.
I also understand that adding multi threading is a huge process but to stay up to date with current engine out today its probably good to implement it.
I'm just curious and wander if things will ever change.
I also understand that adding multi threading is a huge process but to stay up to date with current engine out today its probably good to implement it.
www.badastudios.com Bringing next gen games with the Irrlicht Engine
About your claim about the "buggy down side":
We worked actually a lot on bugfixing in the latest release. Also I just checked if you did raise any bugreports and it seems the only errors you have mentioned so far had been
a) linker errors, which is not an engine problem but a problem of the coder using the engine.
b) A problem you said you had with .X files without _any_ context information despite 3 people asking you for it.
So it seems you didn't report a single reproducible bug so far...
That said - we're not opposed to more team members and actually discuss this once in a while. Although the bigger problem is probably that many current members have trouble right now finding enough spare-time for Irrlicht. But I'd say there are enough programmers in the forum willing to help you out on most problems. So if you have _concrete_ troubles you will nearly always get some help.
We worked actually a lot on bugfixing in the latest release. Also I just checked if you did raise any bugreports and it seems the only errors you have mentioned so far had been
a) linker errors, which is not an engine problem but a problem of the coder using the engine.
b) A problem you said you had with .X files without _any_ context information despite 3 people asking you for it.
So it seems you didn't report a single reproducible bug so far...
That said - we're not opposed to more team members and actually discuss this once in a while. Although the bigger problem is probably that many current members have trouble right now finding enough spare-time for Irrlicht. But I'd say there are enough programmers in the forum willing to help you out on most problems. So if you have _concrete_ troubles you will nearly always get some help.
Last edited by CuteAlien on Sun Feb 07, 2010 12:10 pm, edited 1 time in total.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
I was trying to be as non-"uptight" as possible with that post.bhbtti wrote:I'm not trying to be mean nor having an attitude towards no one i'm just stating my opinions.....no need to get all up tight...I really appreciate what the development team has done but it wouldn't hurt to add people to their squad to help out the engine. I'm sure if the developers focus only on multi threading then everyone would be happy even though they are with release 1.7.
I'm just curious and wander if things will ever change.
I also understand that adding multi threading is a huge process but to stay up to date with current engine out today its probably good to implement it.
I even revised it twice. You still didn't answer any of my questions, and I'm quite interested in what your answers would be:
Halifax wrote: What exactly do you want multi-threaded? How will it help you? Are you just looking to add buzzwords to Irrlicht's list of features?
TheQuestion = 2B || !2B
Can I just say that whoever wants a new feature is welcome to give it a try and implement their own, instead of moaning about what others should do! 
Everything is possible, IF you know how.
Checkout my website for my upcoming game.(Currently on hold!)
http://www.projectbattle360.webege.com
Checkout my website for my upcoming game.(Currently on hold!)
http://www.projectbattle360.webege.com
or you can also pay niko $$ and ask him to add features that you want
My company: http://www.kloena.com
My blog: http://www.zhieng.com
My co-working space: http://www.deskspace.info
My blog: http://www.zhieng.com
My co-working space: http://www.deskspace.info
Well again I must mention that adding new stuff may be useful but this will be easier if the codebase may be a bit cleaned up before. I already thought about to branch irrlicht and create a deeper revision with the following goals:
- try to seperate the different aspects in subprojects to get more orthogonality. Means every namespace become a own subproject and the "core/factory" stuff can be seperated from things like loader, specific elements like different driver as well. This way it may be easier to work with more people and for an user to replace an aspect by own implementation. There are already efforts to reach this goal by the devteam (i.e. the different "COMPILE_WITH" things), but it does not force the developers to keep the implementations really independent.
-adding a flexible vertex format
-reduce the ITextures to pure HW-Bufferlinks
but I must admit that I have not the time to handle such a revision at the moment and I fear even if I would do so this wont be moved to the irrlicht-original base and I do not like to manage another seperate project. Moreover this would be just a revision with direct benefits. It would only make the next steps cleaner and easier.
- try to seperate the different aspects in subprojects to get more orthogonality. Means every namespace become a own subproject and the "core/factory" stuff can be seperated from things like loader, specific elements like different driver as well. This way it may be easier to work with more people and for an user to replace an aspect by own implementation. There are already efforts to reach this goal by the devteam (i.e. the different "COMPILE_WITH" things), but it does not force the developers to keep the implementations really independent.
-adding a flexible vertex format
-reduce the ITextures to pure HW-Bufferlinks
but I must admit that I have not the time to handle such a revision at the moment and I fear even if I would do so this wont be moved to the irrlicht-original base and I do not like to manage another seperate project. Moreover this would be just a revision with direct benefits. It would only make the next steps cleaner and easier.