Although, I can't see real use of IrrXML, because there is a great bunch of xml tools already.
IrrKlang & IrrEdit on the other hand are useful
Thanks.
IrrEdit and friends - Big Waste of Niko's and friends' time
I've done plenty to push Irrlicht's limits. Since your profile is blank (everyone gets PM) and I can't find any links in your posts I can't ascertain what you yourself have actually done with Irrlicht; I assume that if you have done something then you haven't hit Irrlicht limitations.SiriusCG wrote:What is really ludicous here is that *no one* has pushed the current Irrlicht implementation to anywhere near it's limits... and they're wailing about "we need this and we need that"... what nonsense....
I'm reading the pablum that these "serious" game designers are spewing and all I can do is laugh... The "place the blame on the engine" is as old an excuse as it gets...I'm switching to Ogre. Irr's future as good game renderigng engine is very uncertain.
Irrlicht is a very good engine and the only uncertainty I can see is whether or not these "wanna be" game devs actually can produce something more than a tetris clone...
A selection of limits I have encountered:
1. 4 textures - just about enough for my Doom3 models with diffuse/normal/gloss/displacement maps.
2. no NPOT rendertargets for DX - rendering an exact copy of the framebuffer not possible.
3. No per texture-stage settings - a single wrap for UVW in one texture stage and applying to all texture stages.
4. Single filter setting applies to all texture stages.
5. Rendering to multiple rendertargets during a scene - scene is updated at every smgr->drawAll() call leading to all rendertargets being out-of-sync. If you pause the timer, things like cpu skinning are still redone for every drawAll().
6. No HW buffers (DX: VB/IB) support - its quicker for me to render an entire Quake3 level in IrrSpintz than to use an octree to "optimise rendering" (about 4 times quicker).
7. tiny.x currently renders at 78fps for me. My MultiAnimation demo can render over 100 tiny.x faster than that and they're being blended between two animations.
8. Shader constants: float only. No bool or int.
9. Can't have a rendertarget bigger in width or height than the original window in DX, as depth buffer is shared.
Irrlicht Demos: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=45781
i think that the main problem with patches is cross-platform requrements. for example i`m windows guy and can`t (and don`t want) to bother with different compliers, etc, but already did a lot of (DX/Windows only) stuff for my game that worth adding to the engine but is not cross-platform so left out. Look at sprintz (great additions but DX9 only) and other extensions. May be it is time to expand code with not-cross platform things but put dummy classes for non-supported OSes, thus encouraging linux/etc guys to fill them with proper implementations? Just guessing, i know this will raise hell a lot of other problems
Another big issue with Irrlichts itself is leak of hardware vertext buffers. Without it it will never be used for really big projects imho
I hope GPU/CPU/Hardware progress will change the whole concept before this happens
Another big issue with Irrlichts itself is leak of hardware vertext buffers. Without it it will never be used for really big projects imho
I hope GPU/CPU/Hardware progress will change the whole concept before this happens -
hybrid
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
I think we have already met a point where we cannot stick to "always all platforms". So there are different limitations on different platforms and this will even increase. I think it's not a problem to have something missing, the only thing which has to be fixed is when behavior exists on several platforms, but is different. That's why the key repeat hadnling is currently filed as a bug in Irrlicht (Windows only send down events while Linux sends up-down sequences).
sio2, to my great pleasure I already have some things from your list implemented (not in SVN yet, though). It merely contains all per-texture material settings, i.e. texture wrap, texture matrix and (not yet in code) the filtering. I hope to have it fixed for the next release. You can already add more textures (simply override the constant) - all initialisation code should work with the correct numbers.
I'm sorry that I cannot help you with the DX limitations, I simply don't know enough about them. But the animation stuff should become much better as soon as the new animation system will become effective. And HW buffers are a major feature Irrlicht definitely needs, but a proper implementation needs some time. I'm pretty sure that Irrlicht will have them before the 2.0 release
sio2, to my great pleasure I already have some things from your list implemented (not in SVN yet, though). It merely contains all per-texture material settings, i.e. texture wrap, texture matrix and (not yet in code) the filtering. I hope to have it fixed for the next release. You can already add more textures (simply override the constant) - all initialisation code should work with the correct numbers.
I'm sorry that I cannot help you with the DX limitations, I simply don't know enough about them. But the animation stuff should become much better as soon as the new animation system will become effective. And HW buffers are a major feature Irrlicht definitely needs, but a proper implementation needs some time. I'm pretty sure that Irrlicht will have them before the 2.0 release
LOL. My apologies to you sio2! I was going to add to my original post that you were probably the only one who had... but I got distracted...I've done plenty to push Irrlicht's limits.
Still, who in this forum using Irrlicht has produced *anything* beyond a techdemo that would justify the "we need feature xxx" hew and cry?
I've used Ogre, wonderful engine, well designed, PITA to develop with, IMHO.
Irrlicht, despite some issues is easer to code with, again IMHO. I especially like IrrEdit and IrrKlang as support to the Irrlicht core...
<Insert Engine Name HERE> has <Insert wonderful feature list here> ....
It's all a trade-off...
To me, Irrlicht development for the LINUX platform was always a waste of time. No market share...I think we have already met a point where we cannot stick to "always all platforms".
Not really. As noted elsewhere, Ogre has a very clean OO-based internal structure. However, that doesn't make it any easier to get content into it...That's self-contradicting.
Torque is the same way... great engine, terrible and convoluted content pipeline...
Gotta keep your artists happy too...
No argument there... great for the "starving programmer" in all of us. However, if one were looking to publish their game, the LINUX market is a poor one. Mac and MS are much more lucrative. YMMV...Moreover, since OpenGL is itself cross-platform, Linux and OSX are (despite those input problems etc) for free.
I noticed that this guy never again posted in this thread...and never backed up his claim of being a pro game dev. I knew I smelled a smokescreen...Valtras wrote:I've already made a commercial game (not on irrlicht, of course...) and I know what a gamer need, so don't instruct me, please...
We all live in a yellow subroutine.
(\__/)
(='.'=) Copy bunny into your signature to
(")_(") help him gain world domination.
(\__/)
(='.'=) Copy bunny into your signature to
(")_(") help him gain world domination.
You punk get your hands off Linux!!!SiriusCG wrote: To me, Irrlicht development for the LINUX platform was always a waste of time. No market share
Linux is supported by ID Software, Epic Games and some others.
So think twice before telling bullshit here
And making irrlicht platform-dependant code will not increase number of irrlicht users, it will only decrease it. (Why don't you say it to OGRE users, I ASK YOU? AH?). Because A PLATFORM DOESN'T MAKE YOUR GAME POPULAR or unpopular. It's YOU who make it good. And as you see from Doom, Quake, Unreal Tornament they ARE great games and ARE cross-platform.
-
lostclimategames
- Posts: 331
- Joined: Sat Sep 02, 2006 4:11 am
- Location: Michigan
- Contact:
doom3 sucked, and i agree linux is a very small population, its not about platform dependency making a game popular or not, its about it being a small amount of the population, its like saying im going to sell t-shirts with very limited resources to start with, i will only sell popular colors because i dont have money to waist on colors with a very limited appeal.
___________________________
For all of your 3D/2D resource needs:
For all of your 3D/2D resource needs:
It also decreases the number of improvements/patches that can be done by regular users. Thus making engine less competitive. Thus making less developers to start with itkornerr wrote: And making irrlicht platform-dependant code will not increase number of irrlicht users, it will only decrease it. (Why don't you say it to OGRE users, I
Haha, Doom sucked? Ah?
What have YOU done?
And UT sucks too? HAHAHA. You noob.
And regular users DO NOT develop anything useful. They simply come up here asking how to rotate camera and then leave the forums.
Non-avarage users care not only of himself, but try to make it available TO ALL. That's what Open Source means, you really missed it.
Of course, you can say that get and port it.
But then i say: just write it with Cross-platform tools and that's all. If you wanna say they suck, then again, have a look at Epic Games.
What have YOU done?
And UT sucks too? HAHAHA. You noob.
It doesn't if you're not windows guy only.It also decreases the number of improvements/patches that can be done by regular users. Thus making engine less competitive. Thus making less developers to start with it
And regular users DO NOT develop anything useful. They simply come up here asking how to rotate camera and then leave the forums.
Non-avarage users care not only of himself, but try to make it available TO ALL. That's what Open Source means, you really missed it.
Of course, you can say that get and port it.
But then i say: just write it with Cross-platform tools and that's all. If you wanna say they suck, then again, have a look at Epic Games.
You just confirm my point. Compare number of crossplatform tools with OS-dependant ones (for example MS tools). Take into account that all of them have their users (and some of them have a lot of users). and then compare numbers. Sticking with cross-platform requirement just diminish user (developer) base.But then i say: just write it with Cross-platform tools and that's all. If you wanna say they suck, then again, have a look at Epic Games.
And talking about "regular users" you forgot to mention that it is not users, it is developers. Developer can do smart things by design! If you think that good developers (that can contribute back to the engine) do everything in cross-platform way then YOU are wrong. Look at irrSprintz and other irr braches/extensions - the obvious reason they was made as separate modules is non-crossplatformity of irrlicht. I`m can post some additions too , but they are DX only so i don`t think they will be of any use here. But of course you can think as you wish.