Irrlicht Engine

needforhint wrote:no , I got it right

2^64
= (2^32)*(2^32)
= (2^16)*(2^16)*(2^16)*(2^16)
= 65536*65536*65536*65536

So far, Saturn is right.

The reason is code reuse simply. CNullDriver does the generic part of the implementation of the IVideoDriver interface. Else this interface had to be implemented inside a header, which were acceptable for smaller functions, but not for 40k big source. Other alternative were to implement those ...

The problem is that you have two device variables. One at global scope, and one inside main. When you call createDevice() you assign to the one in main, but the global one is still left pointing to garbage. You then use the garbage device pointer to call getGUIEnvironment() , which crashes ...

I think I thought about something more like Spintz' version. What is basically required for Irrlicht is to store the meshes on the gfx card and recall it from there. All the fancy vertex streams will not add that much performance anymore and should be kept in the background as much as possible. I ...

If this a usefully thing to code? [will you use this in your apps] :roll:

The real question is more along the line of "will YOU use it?" If you have the need for such modification, do it. If not then try to spot why you don't need it - maybe it is too complex, maybe it is not that usefull, and so ...

Thanks
But this is the first time I use the debugger. This is what it says:

Program received signal (SIGSEGV)
Segmentation fault
Previous frame inner to this frame (corrupt stack?)
error


So what could it be?

You don't verify any pointer you get. createDevice() might return NULL (although this ...

Maybe the public interface should indeed just use some simple vertex array and buffer properties instead of giving access to the full-blown hardware buffer mess. Each driver can then create the internal representation necessary. I'm not sure if there is a chance to make this somewhat performant and ...

I just gave a quick look to IrrSpintz, so I may be wrong in these conclusions (please feel free to correct me).

As of today, only the IIndexBuffer class is exposed to the public. This class is a standalone class that is not related to hardware index buffer, although it can be used to backup the hw ...

Hardware index buffers are already supported in IrrSpintz. The difference is the ID for the buffer is not stored in the IIndexBuffer but in the mesh. A simple design change if needed.

What's the problem with the VertexBuffer / IndexBuffer implementation in IrrSpintz?

This all seems like ...

Those pictures are all so different that the comparisom is unfair. Just a few more lighting effects, a few more waves. That's all. It can all be done in DirectX9. Now many programmers are expected to learn a new DirectX( Not for the lucky Irrlicht users though! )! :lol: The face test is the worst ...

Personnally, I find that NaturalDocs is also quite good. It lets you write comments that are not cluttered with strange symbols. Unfortunately, the C++ support is not completed yet, so you may find it less powerfull than doxygen.

Eclipse 3.2 is fantastic for C++ IDE...
I am not new to Irrlicht however. Quite the contrary. I have followed this engine for 6 years and I am very impressed with the improvements...


You managed to follow the engine development 2 years before it actually began. I'd say that it is a very ...

Hello y'all,

I updated my proposal to v0.4 (find it here ).

The old proposal still lies here: http://members.gamedev.net/emmanuel_deloget/external/old/IrrlichtBufferObjects.v0.3.pdf .

Change includes:
* suppression of the name parameter for addXXX() methods
* addition of a method to create a ...

(I have split these posting into a new thread to avoid messing the other thread too much)
I am a little short on time currently, but I've downloaded it already and will try to respond in the next days.
But the less changes to the API are necessary the better for the solution. Ease of use is the ...

EmmanuelD, I read your proposal and have a few comments.

The smallest of these: What's the name in the add-function for? I don't believe vertex/index buffers need to be handled by name in Irrlicht, this should be removed. If an application needs to track those by name, it can easily do the mapping ...