Irrlicht Engine

If you acept that my system is fine-tuned and that there are no differences in driver performance between DX and OGL then you have to acept that the problem must be the OpenGL renderer because it is the only thing that changes.
I accept the first part, not the latter. I only said, that *if ...

elander, as much as you wrote wordwise, as little information you actually transported with it.

I don't doubt in the slightest, that OpenGL/DirectX has, optimal drivers for both provided, almost equal performance traits. All I doubt are your benchmarking skills.
You failed to provide informations ...

elander, exactly: Blame yourself instead of the tool.
Your naive "benchmarking" approach is totally meaningless. You can't just take two different super simple scenes that render with 300+ fps and try to draw any conclusions out of it. The differences of 300 and more fps are totally meaningless ...

It's Japanese.

Be more specific, if you want to have a real discussion going on here. If you have identified bottle necks specifically or problematic scenarios more generally: Speak up! Else this thread is pointless..

Thats normal behaviour and implicit to the way floating point values are handled. *Never* try to directly compare two floats/doubles using ==, instead check, whether one float is in some epsilon range/environment(?) of the other.


float EPSILON = 0.00001f // values that are less distant than this ...

A memory hog that's worth the mem, then. ;) VA is much, much better than IntelliSense ever was. It makes work with MSVC much more efficient. It is faster than intellisense and doesn't err or fail as much as IS does and provides more features and better highlighting and code navigation and and and ...

Make sure, you use the correct irrlicht.dll. This sounds as if you have multiple of them in your system and a wrong one is accessible from the working directory you configured in your project. So double check, that there is no irrlicht.dll somewhere in your %PATH% and also double check, that the ...

Indeed, that's what I meant. DDS can store DXT compressed surfaces with their mipmaps all prepared to be loaded in a speedily manner. Of course there is no maigc in DDS, this can all be done in runtime too.

DDS supports these and some other useful features (like in-mem compression and cutsom mipmaps) Though irrlicht doesn't support it sadly. though cubemaps can be also implemented as six seperate 2D textures.

Electron in your test, did you also scatter the sin/cos computations around in the code, that most of the time is doing different things and moving big heaps of mem? Because in a naive test application with computations done in a for-loop, you have the whole table in tha cache the whole time. No ...

These are different issues probably. Problems can occur when linux users check in CRLF style files, because they are considered to be already LF style and when checked out converted to windows style LF -> CRLF and thus it is made to CRCRLF leaving a CR at the end of each line.

If such files or ...

Knuttz, no. Custom clip planes are not supported by irrlicht right now. You have to add this functionality to it yourself.

lingwitt, the files in irrlicht don't have any such property set, so I don't understand why you got issues here. What specific issues do you have?

Debug it. Without any code at all, we have way too little information here.
First look into your cegui.log, to see if there are further informations.

If this doesn't help to resolve the issue: Use the debugger!
And if you can't figure it out then yourself, present a stack trace together with the ...