Irrlicht Engine

[edit: oops, beaten by AlexL :)] I've been scratching my head about that Linux error, I still couldn't say why exactly it happens, but just adding #define glXGetProcAddress glXGetProcAddressARB somewhere suitable (linux defines) is a work-around if you get this error. I'm not sure, but it might be ...

I've done some 2D work with Irrlicht. It's a great place to start, but if you are doing a purely 2D game, it might be worth finding an engine written specifically for the purpose (there are plenty). However, if you plan to extend into 3D rendering, then stick with Irrlicht, it won't let you down. I ...

Basically your model has too many vertices for Irrlicht to handle. You either have to wait until Irrlicht gets 32bit indices, or trim your model down. Unfortunately, theres not much else to do. If I remember right, nx++ added support for 32bit indices, so perhaps you could try porting that back to I...

I get image problems like that when my desktop colour depth is set to 16bpp, I havn't really looked into it though, so I can't tell you the whys. I'll have to try it with different image formats to try and see if the problem is with the image loaders themselves, or it could possibly be a problem wit...

It's not really no, but it is improving all the time as Niko seems pretty receptive to contributions to the OpenGL device. If you have any ideas of how to improve the speed then grab the source and start playing :D Render-to-texture and GLSL should hopefully already be in the next release, but if yo...

How about saving the key states between events as booleans //(somewhere outside of event handler) bool leftPressed=false, upPressed=false; //as many as you have actions //(event handler) if(keyPress==LEFT) { leftPressed = event->KeyInput.PressedDown; } else if(keyPress==UP) { upPressed = event->KeyI...

Change scene::ICameraSceneNode* camera = smgr->addCameraSceneNodeFPS(0,100.0f,1200.0f); to camera = smgr->addCameraSceneNodeFPS(0,100.0f,1200.0f); You were creating the camera with local scope rather than refering to your previously defined pointer, so the camera variable that the event receiver was...

You would use the same scene manager for both scenes: smgr = device->getSceneManger(); but have your two 'scenes' attached to it: ISceneNode scene1 = smgr->addEmptySceneNode(); ISceneNode scene2 = smgr->addEmptySceneNode(); And then instead of creating your scene nodes with parent 0, pass them scene...

You could try using 2 dummy scene nodes, and use them as the root for your two scenes, simply hide one while displaying the other. I don't think that that would cause any complications, but perhaps someone whose tried something similar could confirm this?

Glad I could be some help :) I like the tweaks you made, they make it more conventional. I have an additional change though, under linux you can't guarantee that . and .. will be the last two entries on the list, as it is simply sorted alphabetically, and other files can start with "." as ...

I just tried it out on Ubuntu and was surprised that I hadn't spotted this before, I get the exact same problem. I managed to fix it but it would be nice to know if it also works on your system. All of the changes are in CFileList.cpp. Near the top in the LINUX includes, add: #include <sys/types.h> ...

Yes - yes you can. Check out Jirr or Bindenlicht. I'm working towards another release of Bindenlicht soon, so don't be too put off by the lack of apparent progress, it is still alive

I think what you are after is the relative mouse movement. I'm assuming you know how to obtain the x and y coordinates when the mouse has moved, if so, then simply store the previous x and y, and subtract that from the new x and y to get the amount the mouse has moved since the last event. From the ...

I haven't looked at it, but from my own experience with ODE, trimesh physics responses are done differently to primatives. If the boxes are colliding wth primatives then it should work fine and your problem is something else, but if they are meant to be bouncing off of a trimesh terrain or any other...

I have seen this problem before and the fix was to simply use a 24/32 bit z-buffer rather than a 16 bit one. I don't know how you can force z-buffer size in Irrlicht, you may have to dive into the engine code and tweak it.