Irrlicht Engine

Well, it seems i am a little bit late, since i do not look regurlary in this forum nowadays....

But also from me welcome/herzlich willkommen Daniel

Hello, First of all nice work @devsh, this fork looks very promising :) I was able to fix the build in VS 2017, all i needed to do were two things: 1. The VS-project still has files listed in it which are not existing anymore, an example is the gui stuff which has been removed. So i removed all non-...

Hello together, Sorry to necro an old thread but unfortunately i got a problem with the Hardware instancing or i am doing something quite wrong. It seem to be impossible to do some RTTing on the instanced node. As soon as i apply the render target texture to the material of my node i am getting a se...

Besides, here is the diagram of my project, which means that about 700 tiles are loaded, and unloaded:       MB 687.8^                                                                     :        |                                                                  #:::        |                        ...

Thanks for the advice hendu, i didn't knew massif. :oops: I did some runs with it over the little example i posted, and for the sake of simplicity i took away the two or three lines about gui stuff.   #include <irrlicht.h>   using namespace irr; using namespace core; using namespace scene; using nam...

@hendu: Well, valgrind reports nothing at all since the memory is released on the ending of my game, resp. after device->drop. The problem i have, is that the memory never gets released before, resp. during the game. So, if my game is running it keeps using more and more ram over time.

I thought if i use removeHardwareBuffer() i would free the hardware buffers explicitly and therefore immediately, or not?..., in this thread: http://irrlicht.sourceforge.net/forum/v ... er#p277288, it is told so.

Some additional information: I use Ubuntu 16.04, GCC 4.9.0, and stock Irrlicht 1.8.3

Thanks for your reply CuteAlien. Besides, in the example i used animated meshes but it also applies for static meshes... Anyway, i think i need to provide some more details... I am hunting a sort of memory leak in my project which is quite hard to detect and which unfortunately is really big problem...

Hello, First of all i am not sure if am experiencing a bug here or not. If not, i apologize for the wrong blame... As it seems, the memory is not completely freed when scene nodes and their meshes are not released in the reverse order of creation. I made a small testprogram to reproduce this:   #inc...

Hello, I am having a very weird problem, which is probably related to irrlicht and GCC 5.3.1: My Application is only crashing on the first line of code when it is built with GCC 5.3.1 and uses both Irrlicht 1.8.3 and bullet 2.83.7 which themselves are also built with this compiler. It works flawless...

I finally made it work :D I'll explain the changes here, and make a patch for it later. COpenGLTexture::uploadTexture           if (newTexture)         {         ...         }         else         {             if (IsCompressed)             {                 if(ColorFormat == ECF_DXT1)              ...

Ok, i think i am one little step further in understanding things now but it is still not working at the moment... I came up with the following changes after reading about glCompressedTexImage3D and glCompressedTexSubImage3D. I just put the functions lock and unlock back to their original state, e.g....

Thx again hendu. I tried to do this the following way, but now it's crashing because the image pointer is NULL: void* COpenGLTexture::lock(E_TEXTURE_LOCK_MODE mode, u32 mipmapLevel) {         IImage* image = (mipmapLevel==0)?Image:MipImage;     if (IsCompressed)         return image->lock();     ......

Thanks for the answers. @Vectrotek: I will keep this in mind when i am searching for information. Regarding my black textures issue i am not persuaded that it's a fundamental driver problem. As far as i know it is possible that this sort of problems are related to texture binding which is done in th...