Irrlicht Engine

OK, just noticed I still had this one on my todo. This got fixed recently in svn [r6599], so will work be in Irrlicht 1.9 Was actually rather trivial to fix - hardware buffers don't have to wait 20.000 frames when they keep the last reference to a meshbuffer. This won't release hw-buffers in all cas...

Ah, yes - mixture of animation and movement. Always a challenge. And can get super complicated once you have crazy stuff like walk into water and start swimming ;-)

I wouldn't worry too much about speed of camera calculations. You don't run many of those, so it's unlikely to ever be a bottleneck.

X can animate (there is an animated dwarf.x model in Irrlicht media), but there's hardly any support for that format out there anymore. I have unfortunately no examples for non-working animated .x models, so not sure what problem there was with the one there.

Note about sleep and yield in Irrlicht. Basically sleep() on Window is really a bad idea for games as it always is around 15ms minimum. So one call and you limit your game to ~65 FPS which people with 144hz screens these days won't like. Yield in Irrlicht 1.8 was just as bad as it used sleep(1) so i...

Noiecity recently made a tutorial video about that, maybe it helps? viewtopic.php?p=307310

Hm, mip-maps are usually good. Try setting AnisotropicFilter to 16 and enable TrilinearFilter for your texture layer in SMaterial. Both are off by default.

Hm, it could have focus and still be hovered. Hovered can have 2 grabs. So next mouse-event the hovered should be gone. Focus can stay until you clear focus or something else gets it (sadly remove doesn't handle this in Irrlicht, very old todo...). So to be really safe with current Irrlich you shoul...

Yeah, that's a problem. Irrlicht has no file-save dialog so far. I've searched around the forum a bit and it seems someone had written one in the past: viewtopic.php?p=151961
But can't tell you much about it, I haven't really checked it out.

Yeah, worry about it later. For a start just make sure your media-path is variable or function and not hardcoded all over the place. Then you can do things like: mediaPath + "some_folder/files" and fixing it later means only modifying a single place.

Yes, kinda the reason why Irrlicht has that folder structure I think ;-) In svn trunk we switched to a tool function called getExampleMediaPath. But basically paths always depend on the working directory you are in at the moment you call a file-function. Independent of library or programming languag...

The problem is you return always true for event.EventType == irr::EET_KEY_INPUT_EVENT.
"true" means: this event is handled and Irrlicht shouldn't use it any further. So you prevent any key input to reach the gui.

You already mentioned this in your other thread. And after my answer you just wrote "Correctly" and posted some code which didn't seem related to the problem. So I thought it works now. My guess is still that you catch the key-input in your event-handler (by returning true), so it's no lon...

Why not use your GUIisHover function when it works? Those checks are cheap, so speed shouldn't be a worry.
You can pass the gui environment to your event-receiver then you can use every function from it in there.

GUIisSelected only updates on mouse-up so it's set when you *release* the mouse button. But you want to know if it's pressed. Your mousePress is true *before* GUIisSelected is set. GUIisHover on the other hand checks where the mouse is. So left-mouse-click-down: GUIisSelected is false. mousePress is...