Irrlicht Engine

Should work with correct color this way.

While they are many fan games, if any of them goes too popular, big N will be interested in it. Square Enix has already shut down a project based on Chrono Trigger, while the developers already had an engine, tons of models, maps and stuff... looked like a few months (at least) work to me :/.

In ...

There is a bug in CGUIEditbox that enables you to write more characters than the max limit you set. Simply, when you paste text from clipboard the max character limit isn't checked. Fix:
(CGUIEditBox.cpp, processKey() function)

case KEY_KEY_V:
// paste from the clipboard
if (Operator)
{
s32 ...

I've corrected EMT_SOLID_2_LAYER material renderer in OpenGL. It works nicely, but the problem is that with vertex colors applied, those colors are visible only on the first texture. I'm not an expert in OpenGL programming, so it probably contains some mistakes:


class COpenGLMaterialRenderer ...

Um... I'm not sure if I understood the question.

It creates a new particle for each particle in the base system, in short intervals (e.g. 50 ms). This increases polygon count quite a bit, but I think the effect's worth it.

The variables it takes from the "base" particles is position and optionally ...

Not smaller in size, because in Irrlicht all particles in a system have the same size. It looks like that with the fadeout affector, which decreases a particle's alpha value over time so it appears more and more transparent.

Also, if you're using dynamic shadows, try disabling them. On my system Irrlicht's OpenGL driver runs horribly slow with shadowing enabled.

Because Irrlicht doesn't allow particles to leave trails, I've written a patch that implements it. Basically, it's adding an emitter that makes the particle system act as trail generator for another particle system.

These screenshots show a simple explosion-like particle system without and with ...

Try a top-down shooter, or other such game that doesn't require much AI (like FPS) and is quite fast to code.

Hmm... I noticed that you _could_ achieve the same effect by using the default code with a very high timeForceLost. I guess that the change's worthless :/

The original gravity particle affector behaves in a weird way - the particles have constant speed when falling, which IMHO looks unnatural and ugly. I've written a small fix to make them accelerate over the time they're falling down, like they should according to physics:

< I removed the code ...

Check if smgr doesn't point to NULL:

if(!smgr) printf("Fatal error\n");


If this won't help, try calling any other method of the scene manager (eg. smgr->clear()) just before smgr->drawAll(). If that call will cause illegal operation, then the pointer isn't pointing to a ISceneManager object ...

I took a look at your code. Wouldn't it be faster to write a single drawIndexedTriangleList call in the render() method, instead of calling it for each single quad?

It's not a bug, but a missing feature. I can't find any reason why the skybox node can't be rotated (or scaled), so I'm posting here the code to fix it. It's just changing one line in CSkyBoxSceneNode.cpp:

void CSkyBoxSceneNode::render()
{
video::IVideoDriver* driver = SceneManager ...