Irrlicht Engine

Tell me Halifax, who's trolling? What did your last post brought? Was it related to the thread?

It contributed absolutely nothing to this thread's discussion, but it did to the thread. I am trying to get an argument of a mute point to just stop.

I'm trying to get you all to see what is not being seen. Your awaiting something that isn't going to happen, for the developers to weigh in on this conversation. Obviously they haven't come for a reason, so why not take heed to that.

Honestly, if you want a true answer, then I would take this to niko. I am sure he is using the Irrlicht implementations, int he commercial games that he is producing, for some reason.

Yeah, well, keep the insight. If nothing else, I'm interested in knowing. If the claims made here have basis, I want to know. I want to know how much, why. I want to become better. I don't need false claims and "certitude". Those never helped anyone.

seeing as everyone wants to derail the thread i might as well.

POPCORRRRRRRRRN>

using namespace std;
std::vector <Point> verts ; //!< Contains all mesh vertexes
std::vector <int> vindex; //!< Vertex index
std::vector <Quaternion> nodeScaleRotsArbitrary ;

why on earth wud u have using namespace std, and then put std:: there?
even a beginner wudnt make that mistake.


Why DOESNT irrlicht use STL?

because the designer and architect chose not to. its simple.

Whats stopping u from using STL on ur own?

nothing, go forth and enjoy open source. make patches u can apply to ur own version of irrlicht. nobody cares

FuzzYspo0N wrote:Why DOESNT irrlicht use STL?
because the designer and architect chose not to. its simple.

Yeah, that's helpful. Decisions can be revised in face of new facts (new compilers) or greater experience or for many other good reasons.
If this is how all people thought all the time, we'd still live in caves or maybe not even that.

Ever heard of scope? Anyway, if two namespace supersede, you need to disambiguify anyway.

everyone else was jumping in with irrelevant topics i wanted to play too

anyway, lol. im happy with whatever the developers choose, they ALWAYS consider whats best (IMO). so yea

FuzzYspo0N wrote:everyone else was jumping in with irrelevant topics i wanted to play too

LMAO..

"Dorth-Vader"

LOL!!

Yeah I honestly agree with FuzzySpoon's ideals. The beauty of open-source is that you can change it, and patch it, with out any consequences.

I personally believe that the developers have your best interest in mind, and if your not happy with this engine, then use the engine next door!

Yeah, we got your opinion. Now either bring arguments, facts, patch or something tangible or butt out of the convo.

Dorth wrote:Yeah, we got your opinion. Now either bring arguments, facts, patch or something tangible or butt out of the convo.

I don't want STL, so it's pretty obvious that I'm not going to be coming with a patch. And I don't know what facts you want.

Dorth wrote:Also, CuteAlien, seems you missed a couple in TGE 1.5...

Well, actually I'm completely missing 1.5, as I wrote I evaluated the engines 2 years ago and 1.5 wasn't out that time. So obviously they have changed that now - which is certainly interesting.

Dorth wrote: Sorry, I can't stand bull. So that's 3 to 0, still 100% right now. Still waiting for proof guys, for right now, your arguments are not worth a thing.

Besides Irrlicht there's still the other two I mentioned - CrystalSpace ( http://www.crystalspace3d.org/docs/onli ... archy.html ) and Nebula ( http://nebuladevice.cubik.org/documenta ... rchy.shtml ). So of the 5 engines I've evaluated 2 years ago it's now no longer 4:1 but 3:2. I stand corrected and I'm sure I should be called a big fat bull for not buying every version of TGE in between to verify that.

edit: And as I got now curious about TGE I just searched the garagegames website until I could find some new documentation. And while I can't tell anything about the new sources, at least in the official API documenation for 1.5 they still seem to use their own classes. Those classes have sometimes a so called STL-Interface - which looks to me simply like offering the same functionality with the same names like STL is using within(!) their own classes and additional to their own functions. But that does not look like they would use stl. Something hybrid already has mentioned as a possibility for Irrlicht. And while I can't check your claims - here is the official link to the TGE API documentation from which I got that information: http://demos.garagegames.com/tge/TGE%20 ... erence.zip

Who really cares?
It's the way it is and it works.

I care. As others it seems, on both side of the argument. It works, but not as well. And the way it is can change if need be. We've already pretty much all agreed that if a proper patch that included a config flag to turn on or off the STL was submitted, it'd be included. The discussion is more academic at this point, which is why it'd be interesting if people would bring arguments and data instead of believes. If a better custom version could be put instead of the stl and/or Irrlicht, who would say no? But we need to compare them. See the reasoning behind the choices, see how well they compare to real life.

-Edit-
Btw...
current xkcd strip at the time of writing, posting archive link so that it holds...

http://xkcd.com/406/

Dorth wrote:[core::] works, but not as well [as std::]

I missed the part where we determined that with "data", using real world tests across all of Irrlicht's common platforms.

Perhaps Spintz could provide before-and-after evidence? Short of that, we'll have to suck it and see. An STL version isn't going to arrive through further point scoring. Perhaps the folks who want to see an STL version could raise their sweaty Cheetos-stained hands and, once their hearts stop racing from exerting themselves, get on with implementing it?

Ok, let me try a random shot. As rogerborg said, Spintz did make the jump from irr::core:: to stl. I won't scavange for the exact threads on his forum, but he said he saw a clear increase in speed.