Irrlicht Engine

I really like this idea and framework.

I guess something like this could be implemented using google's test-framework "google-test".

I'd like to add things such as number of memory allocations (which I noticed is quite a lot at startup), memory fragmentation statistics, etc.

If someone is up for ...

http://img265.imageshack.us/img265/7071/msvcscreen.jpg

A few words about clean code. :)

These methods are implemented in the header and are very short, so you should declare them inline.
The pointers never change, so you should return a constant pointer.
The methods don't change the state of ...

Simpe , you have a point, but remember that most uses of irrlicht are currently on desktop systems which dont use out-of-order CPUs.

I think you meant the other way, (most desktop systems are out-of-order execution cpu's)... possibly because I typoed it in my post :P

But yeah, most irrlicht ...

... Or in a place where you can perform multiple vector operations at once. Such as a brute-force culling-algorithm.

However, I'm assuming that you've been testing on x86/x64 which are out-of-order cpu's and they can be pretty awesome at times to swallow "bad code". If you compare that to a in ...

actually x86 and x64, yeh i get the point.. even i dont think its worth it

... together with the ppc-architectures that's on the xbox360/ps3 as well. I wouldn't be surprised if SSE instructions will be available on mobile devices quite soon. If you design your code to be SSE-friendly you can get ...

I still don't see too much relation between the virtual methods calls and the rend4er call batching.
Well, batching rendercalls means that you can essentially exchange a lot of vcall's for a lot fewer. That's the relation.

But IMHO the former is not our main problem with the engine right now ...

Sure all speed-optimizations show up on a profiler, but what I mean is that the vcall-cost doesn't show up when running a profiler to "find" what the "issue" is.

Anyways, what I thought of was something in the ideas of


struct SDrawCall
{
const SGeometry* m_GeometryPtr;
int m_StartIndex;
int ...

Yes, but it can get really tricky really fast. Guaranteeing atomic operations isn't easy.

There's a lot of atomic operations out there :P There really isn't too much tricky about it. You just have to solve it in a way that's more adapted for your demands rather than apply a general solution to a ...

Oh and by the way, vcalls is not something that will show up in your profiler... but you probably know that

Hi CuteAlien,

With all respect, with the current solution you'll see vcall-issues on shorter pipelines architectures when you work at roughly 3-500 drawcalls. Pushing it anything lesser than that will most likely not show up as anything noticable on profilers.

The differance is essentially not ...

Hi,

I've come to the conclusion that some of the design-decisions taken regarding some implementations in Irrlicht leads to high-frequent calls to virtual functions. Now on most modern architectures such as i7 or similar this isn't much of a problem. They have long enough cpu-pipelines and big ...

To be honest, if you want performant threading-communication you should leave semaphores, mutexes and other poor-performing threading-communications out of the context. Lock-free communication as far as possible is the way to go.

I think that it's pretty vital to keep the design of a linear array. Since a lot of Irrlicht's calculations is done by iterating through a list of objects it's sane for the sake of cache-coherency to keep lists of objects as a linear chunk of memory.

A linear array is not a list. It's a linear ...