The latest SVN bugs thread

[Mel]

All are floats. It is the amount of mip levels multiplied by a value taken from a texture, so it can somehow simulate a glossmap.
This is an example of the diference. On both cases the trilinear filtering is enabled, otherwise it wouldn't look correct, but in the OpenGL case looks exactly the same as if the trilinear filter wasn't used. I know the mip levels are taken because otherwise a seam would appear in the borders of the texture, so it must be the trilinear filtering not working.

[wing64]

Hi Teams,
Did you forget free SharedRenderTarget var, din't you ? (CNullDriver.cpp both trunk and branches)
Best,

[CuteAlien]

@wing64: Doesn't seem to be created with new or a function starting with "create" - so I don't think it should be drop()'ed. Do you get some memory leak there? If so - does it happen in one of the example or do you have some code to reproduce it?

[wing64]

Unclear question that I so sorry, I agree with you about leak memory not found if run program from official example (ex.13) but
leak of memory occured after user remove and re-adding render target while driver running, Pseudo code following:

Code: Select all

int main()
{
    rt = driver->addRenderTargetTexture(...); // rt ref = 1
    while(1) // main loop
    {
        driver->setRenderTarget(rt) // rt ref = 2
        driver->draw3dLine(...);
 
        if( user change rt resolution )
        {
            if( rt ) driver->removeTexture( rt ); // ref = 1, !!!leak here!!!
            rt = driver->addRenderTargetTexture(...); // ref = 2
        }
    }
    return 0;
}
 
Detected memory leaks!
Dumping objects ->
{27635} normal block at 0x07201FE8, 18 bytes long.
 Data: <irr_depth_stenci> 69 72 72 5F 64 65 70 74 68 5F 73 74 65 6E 63 69 
{27633} normal block at 0x07201F68, 18 bytes long.
 Data: <IRR_DEPTH_STENCI> 49 52 52 5F 44 45 50 54 48 5F 53 54 45 4E 43 49 
COpenGLDriver.cpp(3741) : {27632} client block at 0x071C9DC8, subtype 0, 176 bytes long.
 Data: < -@Q -@Qh       > B0 2D 40 51 C4 2D 40 51 68 1F 20 07 12 00 00 00 
Object dump complete. 

Best,

[CuteAlien]

@wing64: Can you make that a real example to reproduce the leak? Otherwise I have to write it and try to reproduce a bug you are already getting. And that is always hard (and I have no idea when I would find time for that). This is likely something in Nadro's area of expertice.

[devsh]

Have you guys ran into the Intel HD Graphics won't draw VAOs properly bug yet?

[19:26] <devsh> https://software.intel.com/en-us/node/635903#
[19:27] <Yaniel-> Why
[19:27] <devsh> because i think I found an Intel OpenGL driver bug
[19:28] <Yaniel-> Oh it's a bug report
[19:29] <Stragus> Someone else here complained DAS was broken on Intel, a while ago
[19:29] == ratchet_freak [~ratchetfr@94-224-113-57.access.telenet.be] has joined ##OpenGL
.....
[19:39] <devsh> if you guys can download my bug test cases, and leave a comment in the forum.. that would be great
[19:40] <devsh> time for intel to fix their shitty drivers
[19:40] == t0by [~t0by@host182-33-dynamic.45-79-r.retail.telecomitalia.it] has quit [Ping timeout: 276 seconds]
[19:40] <Stragus> Ah, we have several work-arounds for broken Intel drivers
[19:41] <Stragus> Evev things like Intel VAOs not storing the GL_ELEMENT_ARRAY_BUFFER
[19:41] <Stragus> Even*
[19:41] <devsh> Stragus: someone needs to stage a "Purge" style raid on their offices
[19:41] <devsh> Stragus: I know about GL_ELEMENT_ARRAY_BUFFER, but they fixed it now
[19:41] <ratchet_freak> intel drivers are that broken?
[19:41] == smoutz [a4d71362@gateway/web/freenode/ip.164.215.19.98] has joined ##OpenGL
[19:41] <ratchet_freak> do they even look at the spec?
[19:43] == toor_ [~toor@76.ip-51-254-204.eu] has joined ##OpenGL
[19:44] <devsh> ratchet_freak: I beleive they use it as a substitute for toilet paper at their office

[christianclavet]

Hi, Tried to compile SVN Irrlicht with #define _IRR_WCHAR_FILESYSTEM and there are compilation errors:

Gravité Code Description Projet Fichier Ligne
Erreur C2440 'initialisation' : impossible de convertir de 'const char [12]' en 'const irr::fschar_t *' Irrlicht C:\Users\Public\Projets\Irrlicht\source\Irrlicht\CWGLManager.cpp 41

Gravité Code Description Projet Fichier Ligne
Erreur C2440 '=' : impossible de convertir de 'const irr::fschar_t *' en 'LPCSTR' Irrlicht C:\Users\Public\Projets\Irrlicht\source\Irrlicht\CWGLManager.cpp 56

Found out that it might not be fixed from there: http://irrlicht.sourceforge.net/forum/v ... AR#p292314

Removing this preset and the compilation work.

There will be a examples cleanup due soon, as the examples all fail to link. (Linker errors)
Found also linker errors when compiling the examples: (They all fail with the same error)

Gravité Code Description Projet Fichier Ligne
Erreur LNK2019 symbole externe non résolu __imp_createDevice référencé dans la fonction main 01.HelloWorld C:\Users\Public\Projets\Irrlicht\examples\01.HelloWorld\main.obj 1

Other linker errors:

Gravité Code Description Projet Fichier Ligne
Erreur LNK2001 symbole externe non résolu "__declspec(dllimport) class irr::video::SMaterial irr::video::IdentityMaterial" (__imp_?IdentityMaterial@video@irr@@3VSMaterial@12@A) 03.CustomSceneNode C:\Users\Public\Projets\Irrlicht\examples\03.CustomSceneNode\main.obj 1

Gravité Code Description Projet Fichier Ligne
Erreur LNK2019 symbole externe non résolu "__declspec(dllimport) class irr::core::string<char,class irr::core::irrAllocator<char> > irr::core::LOCALE_DECIMAL_POINTS" (__imp_?LOCALE_DECIMAL_POINTS@core@irr@@3V?$string@DV?$irrAllocator@D@core@irr@@@12@A) référencé dans la fonction "char const * __cdecl irr::core::fast_atof_move(char const *,float &)" (?fast_atof_move@core@irr@@YAPEBDPEBDAEAM@Z) 16.Quake3MapShader C:\Users\Public\Projets\Irrlicht\examples\16.Quake3MapShader\main.obj 1

Gravité Code Description Projet Fichier Ligne
Erreur LNK2019 symbole externe non résolu "__declspec(dllimport) class irr::core::string<char,class irr::core::irrAllocator<char> > irr::core::LOCALE_DECIMAL_POINTS" (__imp_?LOCALE_DECIMAL_POINTS@core@irr@@3V?$string@DV?$irrAllocator@D@core@irr@@@12@A) référencé dans la fonction "char const * __cdecl irr::core::fast_atof_move(char const *,float &)" (?fast_atof_move@core@irr@@YAPEBDPEBDAEAM@Z) 21.Quake3Explorer C:\Users\Public\Projets\Irrlicht\examples\21.Quake3Explorer\main.obj 1

Note: Perhaps theses linker errors could come that I build everything in MSVC Community 2015?. EDIT: Tried to recompile in 32bit instead and did the same thing. I suspect the IDE for this one (MSVC 2015, I will have to see why)

EDIT2: Seem that MSVC set the paths for each project now instead of using a global one. The one for the LIB work but the reference paths for the rest doesn't. (MSVC 2015)

[CuteAlien]

Hm, looks like a new one (CWGLManager is new). Have to check. Thanks for the report.
Linker error looks like example doesn't link to Irrlicht for some reason.

[CuteAlien]

The _IRR_WCHAR_FILESYSTEM is compiling. You have to set #UNICODE when using that as well.
I still can't help with MSVC 2015 problems as I still haven't manage to get it working on my system (standard libraries have changed and something in having several VS versions installed messed it up and it looks in the wrong/old paths and I can't figure out how to fix it. One day I'll give it another shot, but already wasted a full day on that).

[AReichl]

To be on the safe side of life, you should set UNICODE and _UNICODE ( one is used in the headers and the other one in the runtime ).

[christianclavet]

Hi. I added the new command to the IrrCompileConfig.h: "define #UNICODE" and the lib compiled.

For the VS2015 linking errors, I was compiling as a static LIB, and decided to change it to a DLL and see. It compiled most of the examples, except this one: Quake3 Explorer. Looking at the code it load manually Irrlicht: (q3factory.cpp). Not sure if this would work on any type of configurations. The LIB has been compiled with UNICODE support.

Code: Select all

 
/*
    Dynamically load the Irrlicht Library
*/
 
#if defined(_IRR_WINDOWS_API_)
#ifdef _MSC_VER
#pragma comment(lib, "Irrlicht.lib")
#endif
 
#include <windows.h>
 
funcptr_createDevice load_createDevice ( const c8 * filename)
{
    return (funcptr_createDevice) GetProcAddress ( LoadLibrary ( filename ), "createDevice" );
}
 
funcptr_createDeviceEx load_createDeviceEx ( const c8 * filename)
{
    return (funcptr_createDeviceEx) GetProcAddress ( LoadLibrary ( filename ), "createDeviceEx" );
}

Some of them execute, but some open the window and close it immediately like "01.HelloWorld.exe", or "Demo.exe"

[christianclavet]

Hi, I still can't compile the examples on MSVC 2015. So today I tried to build them on Code::Block with the GCC compiler on Windows.

I get this each time I try to compile examples. I have not modified IrrCompileConfig.h in any way and compile the lib as Win32-release-static lib:

||=== Build: Windows in Irrlicht Example 01 Hello World (compiler: GNU GCC Compiler) ===|
.objs\main.o||In function `main':|
C:\Users\Public\Projets\Irrlicht-Trunk\trunk\examples\01.HelloWorld\main.cpp|126|undefined reference to `_imp__createDevice'|
||error: ld returned 1 exit status|
||=== Build failed: 2 error(s), 0 warning(s) (0 minute(s), 1 second(s)) ===|

Recompiling the library and using a DLL instead of a static lib make the examples compiling:

-------------- Build: Windows in Irrlicht Example 01 Hello World (compiler: GNU GCC Compiler)---------------

mingw32-g++.exe -L..\..\lib\Win32-gcc -o ..\..\bin\Win32-gcc\HelloWorld.exe .objs\main.o -lIrrlicht
Output file is ..\..\bin\Win32-gcc\HelloWorld.exe with size 231.56 KB
Process terminated with status 0 (0 minute(s), 0 second(s))
0 error(s), 0 warning(s) (0 minute(s), 0 second(s))

Can we still use Irrlicht in a static library?

[AReichl]

I just tried static lib with Visual Studio 2015 AND gcc/MinGW - both compiled fine ( i normally use Irrlicht as a dll ).
Now we have to fiddle with the settings to see what's different on both our computers. Can be anything.

By the way - UNICODE has to be set in the compiler options, not in a header file.

[CuteAlien]

It's still possible to use Irrlicht as static lib. But not sure if c::b examples have a target for static-libs in their project file (probably not).

[christianclavet]

Hi, Yes. The lib will compile fine, but the examples will not compile if the lib was compiled as static. Right now, I only having problem with the examples. The LIB project itself compile fine on both VS2015 and C::B. It only fail when I'm trying to build all the examples.

For the examples in C::B, they have only 2 build options-> Linux, Windows
So it probably missing something to use Irrlicht as a static lib. What kind of option to set it to use a static lib? I don't remember using a specific define or option when using Irrlicht in IRB.