Irrlicht Engine

@3DModelerMan I believe so, if your OpenAL implementation supports that.

@freetimecoder We are using the exact same function as OpenAL, we will probably change it later to be a little more user friendly, but it is exactly the same as if you entered the value into the OpenAL property for a source.

The equation used for distance calculations is: volume = MinDist / (MinDist + RolloffFactor * (distance - MinDist)); MinDist being the value in setMinDistance, RolloffFactor being the value set in setRolloffFactor (default 1), and distance being how far away the source is from the listener. The volu...

We do have a separate source package for 2.0.0 on our sourceforge page. I do know that there were some bugs in 2.0.0 with 64 bit support that have been fixed in the SVN trunk. We will probably release packages for 64 bit platforms in our next release (which is coming up shortly and will contain a bu...

Well, z testing is still on, thus the grid will still be hidden by other objects. However, the grid really shouldn't be writing to the z-buffer, since it really can't (and shouldn't) hide anything behind it.

I've updated the node to disable z-write. Thanks for the patch.

Sounds like you are getting a z-fighting bug. You may be able to fix this bug by making a small change to CGridSceneNode::render() in CGridSceneNode.cpp ... // Axis Lines are only drawn if the State is true if(m_AxisLineState) { driver->draw3DLine(core::vector3df((f32)m_size,0.01f,0),core::vector3df...

You forgot to include the cpp file into your project, didn't you?

A common mistake.

on the emitter point, if you wanted to, you could code your own particle emitter in your application in order to get a particle system to emit particles however you want it to. Thus, why things are set up the way they are. As for the orientation of the particles, you will have to edit the particle s...

Thanks for the fix, I tested it with both the lastest stable and svn and it seems to work fine here. The node has been updated and a new link posted on the initial post.

Also the fix has an added side effect of reducing memory usage slightly.

One thing you need to note. Using an std::vector (or equivalent like irrlicht's array) for 2d dynamic arrays is a mistake. A vector cannot handle its contents resizing themselves. You need to use an std::deque or pass pointers to the second dimension of arrays to the first level. For example: std::d...

If you placed your world inside a MySQL database, you would obviously include ALL the properties of characters etc in e.g. modelling data (SMeshBuffer?) would be stored as a BLOB of some kind? Storing mesh or texture data in the database is a very bad idea. I would advise storing the filenames to s...

I cannot duplicate the bug on my end with the latest stable and svn release. I'm afraid you will have to debug this on your own. If you do find something wrong with the node, I will be happy to update it.

Double check to make sure both the irrlicht library and your application are compiled in Release mode.

Strange, I cannot see anything in the code that would cause this issue, perhaps something else is to blame?

Honestly, the only way I would work on this is if you were paying me for my services. I have bills to pay, and this project will not help me do it.

Alright, I'll humor you and explain some of the basics. First of all, if you want to be able to edit this easily, I might suggest you set up a database (could use mysql) to store the positions and properties of objects in the world, instead of relying on text/xml files (or worse, hardcoded maps). Al...