migration from irrlicht 1.4.1 to 1.8.4

[kas1e]

Add printfs to whole COpenGLDriver::setFog, build amigaos4 and win32 versions, and found a difference:

When we run it on win32, then while we come inside of #ifdef GL_NV_fog_distance , then for win32 we never come to if (FeatureAvailable[IRR_NV_fog_distance]) check. I.e. that "if" not true for win32. While for amigaos4 that "if" are true, so we come inside of it, and there we go for else and call "glFogi(GL_FOG_DISTANCE_MODE_NV, GL_EYE_PLANE_ABSOLUTE_NV);".

In other words, for both win32 and amiagos4 we come inside of #ifdef GL_NV_fog_distance , but then, for win32 nothing executes from there, while for amigaos4 glFogi(GL_FOG_DISTANCE_MODE_NV, GL_EYE_PLANE_ABSOLUTE_NV);.

So of course for sake of tests, i just comment out that part for amigaos4 build too, so to be able as on win32, and , it make no differences sadly, damn

[CuteAlien]

OK, Khronos says: "The EYE_PLANE_ABSOLUTE_NV mode is the most consistent with the way most current OpenGL implementations are implemented without this extension"
So in other words - that seems to be the usual default.

If you can split your floor-plane into more polygons it might get better. Or at least it might be better if the problem is vertex vs pixel depth (I'm just guessing here...)

[kas1e]

Ok so we found what issue was: you was close when guessing that it can be problem aoubt vertex vs pixel depth.

Issue, is that almost all realisations of opengl drivers (mesa on linux, gl4es on linux and amigaos4, gles1 on pandora) do calculation of fog per vertex, and OpenGL specs state that it is acceptable for a driver to implement fog calculation per vertex (instead of per pixel). That how it done probabaly on all drivers, but not on win32 , where it seems do calculation per pixel.

Now, as we have sources of drivers for amigaos4 and linux's version , and they use shaders for, we just move calcualtion of fog from vertex shader, to fragment shader : and viola. Fog issue is gone.

Originally all this calculation of fog in vertex done because of speed of course, but well .. instead of fixing game's code (and i not sure how much it will take), we just do it like this.

Now .. The last issue is left is to understand why bots mirrored and some textures shifted on the map when we migrate to irrlicht 1.8.4

edit: btw, when i tried latest trunk version it did fix for me issue with "can't see textures when far from them, but they appears to be visibly when i come close to them" , do not know what exactly was fixed there ?

[kas1e]

Oh damn, seems found another issue when migrate from irrlicht 1.4.1 to 1.8.4: all the textures (at least, those ones which used for spalsh screen), by some reassons for me looks like if i shrink them a bit (while im not of course). While for 1.4.1 compiled with the same gl4es all fine. So i suspect its again irrlicht .

See, 1.4.1:

http://kas1e.mikendezign.com/aos4/gl4es ... splash.jpg

See, 1.8.4:

http://kas1e.mikendezign.com/aos4/gl4es ... splash.jpg

Very visibly on letter "G" and "O" at top phrase. Need to recheck all irrlicht's 1.8.4 ifdefs i do in code, maybe some fault on my side, but then which one .. Maybe something should be enabled/disabled for irrlicht 1.8.4 now in compare with 1.4.1 to make look of those images be clean as before. Maybe have any ideas about ?:) Maybe the default material changed and bilinear filtering is gone? Or the oposite, it now use filtering where it wasn't before?

[CuteAlien]

Ok, glad you figured out the fog problem.

Now .. The last issue is left is to understand why bots mirrored and some textures shifted on the map when we migrate to irrlicht 1.8.4

Make a simple example where it can be reproduced. Often one already finds the problem while doing that. Or if not then I'll have at least an example where I can help out finding the problem. Note that I still have a bug with quaternion on my todo (maybe, maybe it turns out to not be bug, so far it's just a report), but will still be a while until I get to that one.

edit: btw, when i tried latest trunk version it did fix for me issue with "can't see textures when far from them, but they appears to be visibly when i come close to them" , do not know what exactly was fixed there ?

And we're back to mip-maps. I change stuff in those ~2 weeks ago. But was more than one change - a lot of things have been rewritten there over the years and I made also several changes recently.

About the splash-screen. The 2d rendering is using a special material which I think has no filtering (COpenGLDriver::setRenderStates2DMode does set that). Comparing code from 1.4 to 1.8 a few things seem to have changed.
Is your screen resolution identical? How do you draw the image - is this a gui-element or one of the draw2dImage functions of driver (if so - which one)?
If you give me the exact values you use for drawing and maybe the image itself I can look if I see something.

[kas1e]

About the splash-screen. The 2d rendering is using a special material which I think has no filtering (COpenGLDriver::setRenderStates2DMode does set that). Comparing code from 1.4 to 1.8 a few things seem to have changed.
Is your screen resolution identical? How do you draw the image - is this a gui-element or one of the draw2dImage functions of driver (if so - which one)?
If you give me the exact values you use for drawing and maybe the image itself I can look if I see something.

Yeah, screen the same, i just run one binary, exit, and run second one.

Loading and drawing done like this:

Code: Select all

 
//load textures:
   m_pGameLogoTex = m_pDevice->getVideoDriver()->getTexture("./data/textures/ui/game_logo.bmp");
 
//calc position based on screen size
    m_Position = position2d<s32>((m_pDevice->getVideoDriver()->getScreenSize().Width/2)-512, (m_pDevice->getVideoDriver()->getScreenSize().Height/2)-384);
 
 
//draw the image:
    complete = false;
    completeTime = m_pDevice->getTimer()->getTime()+500;
    while(m_pDevice->run() && !complete)
    {                
        //calculate time diff
        int diff = completeTime - m_pDevice->getTimer()->getTime();
        
        //is complete?
        if(diff <= 0)
        {
            diff = 0;
            complete = true;
        }
        
        //calculate ratio(0-complete, 1-incomplete)
        float ratio = (float)diff/500.0f;
        ratio = 1-ratio;
        s32 alpha = (s32)(255*ratio);
 
        m_pDevice->getVideoDriver()->beginScene(true, true, SColor(255,0,0,0));
        m_pDevice->getVideoDriver()->draw2DImage(m_pGameLogoTex, m_Position, rect<s32>(0,0,1024,768), 0, SColor(alpha,255,255,255), true);
        m_pDevice->getVideoDriver()->endScene();
    }
 

And there is image itself:

http://kas1e.mikendezign.com/aos4/irrli ... e_logo.bmp

[CuteAlien]

I also need the size of your Irrlicht device please (the one you use when creating it).
And would be good to know which values you get from videoDriver->getScreenSize().

And you know if you just added a few more lines you would have an example like the following (and I wouldn't have to delay my lunch-time to create it!):

Code: Select all

 
#include <irrlicht.h>
#include <iostream>
 
using namespace irr;
using namespace core;
using namespace video;
 
#ifdef _IRR_WINDOWS_
#pragma comment(lib, "Irrlicht.lib")
#endif
 
 
int main()
{
    E_DRIVER_TYPE driverType = video::EDT_OPENGL;
#if defined(IRRLICHT_VERSION_MAJOR) &&  IRRLICHT_VERSION_MAJOR == 1 && defined(IRRLICHT_VERSION_MINOR) && IRRLICHT_VERSION_MINOR >= 8
    IrrlichtDevice * device = createDevice(driverType, dimension2d<u32>(1024, 768));
#else
    IrrlichtDevice * device = createDevice(driverType, dimension2d<s32>(1024, 768));
#endif
    if (device == 0)
        return 1;
 
    IVideoDriver* driver = device->getVideoDriver();
 
    // You may not get the same size here as you passed to the device
    std::cout << "width: " << driver->getScreenSize().Width << " height: " << driver->getScreenSize().Height << std::endl;
 
    ITexture* logoTex = driver->getTexture("./media_kas1e/game_logo.bmp");
    position2d<s32> pos((driver->getScreenSize().Width/2)-512, (driver->getScreenSize().Height/2)-384);
 
    while(device->run())
    {
        s32 alpha = 255;
        driver->beginScene(true, true, SColor(255,0,0,0));
        driver->draw2DImage(logoTex, pos, rect<s32>(0,0,1024,768), 0, SColor(alpha,255,255,255), true);
        driver->endScene();
    }
 
    device->drop();
 
    return 0;
}
 

Sorry, I can't reproduce it. At least not on Linux/X11. Irrlicht 1.4, 1.8 and trunk all look the same here.
But I do get a screen-size of 1024/768 on this system, which might not be the case for you. So check those values.

[kas1e]

I just test your example, and with 1.4.1 all clean, while with 1.8.4 like i show before.

So probabaly at this point size of irrlicht device does not matter (as your simple test case already show issue for me)
And values from videoDriver->getScreenSize() are: width: 1024 height: 768.

My desktop size are 1920x1080x32.

And i do test it with SDL renderer if that make difference, and later with SDL2 one : the same issue.

Maybe there some big-endian changes was in bmp loader since 1.4.1 or something ? Or there was maybe some other new changes and some big-endian ifdef missed somewhere.

[CuteAlien]

I tried again (this time with SDL), but still can't reproduce it.
I even experimented with some filters like:

Code: Select all

 
SMaterial& mat2d = driver->getMaterial2D();
mat2d.TextureLayer[0].BilinearFilter = true;
mat2d.TextureLayer[0].TrilinearFilter = true;
mat2d.TextureLayer[0].AnisotropicFilter = 16;
driver->enableMaterial2D(true);
 

But didn't see any difference when playing with filters. Same when playing around with AntiAliasing.
My desktop resolution is the same as yours.
Note that in your screenshots your window does not have height: 768, but height 720. But I also tested it with that size here and it still didn't look like that.

So... no clue :-(

edit: Minor note, in Irrlicht trunk draw2DImage got rewritten to no longer use GL_QUADS which are pretty outdated and badly supported on some driver. But I just checked and 1.4 and 1.8 both use that.

[kas1e]

I asked to check the same test case on Pandora, and here is the capture of the screen (1024x768 is bigger than Pandora screen size, but we didn't resized and let it display it).



See, same issue ! Quite strange. Maybe again some shaders-in-driver issue (but then why it works with 1.4.1)

[CuteAlien]

Still no clue. The thing I do when I have no idea at all is often to check out svn versions until I find the version where it breaks. Obviously doing a binary search (always taking middle version-number between non-working and working versions). Can take a while doing that, but usually you'll find the breaking version within 2-3 hours that way. And that might give a clue what's going on.

I don't really have another idea. I just tried running it on Windows as well, but still can't reproduce it. So probably just something not happening on my system.

[kas1e]

In meantime i tried to go exclude-way just to find out when those bugs with "shifted/disappeared textures", "rotated zombies" starts , by compiling all versions of irrlicht since 1.4.1 till 1.8.4.

In meantime found only ,that all bugs already there in 1.6.1 already. 1.5.2 build with that game failed to run causing some "std::alloc" error, so i think i can skip it for now, and tried those ones: 1.4.2 , 1.5 , 1.5.1 and 1.6 versions. At least i will have something.

Then i may try to check commit logs, and also find out what changes are guilty for what.

Creating a sample will be tricky, as it will be in the interaction between Game Code and Irrlicht...

[CuteAlien]

Better to go with svn for such tests. Doesn't take that long to find the exact version which breaks something. If you always take half the version number between a version you know works and one that breaks you'll need max. 13 tests in worst case until you got it. You can use svn update to hop between different versions.

[kas1e]

Problem there that for every version i need anyway adapt a bit game's code. With every version almost always something changes, even just a little

At moment i pinpoint that 1.4.2 version are fine (because it have no major changes in compare with 1.4.1).

Then, 1.5, 1.5.1 and 1.5.2 versions crashes on loading with segm.fault on win32, and on linux i have some "bad_alloc" error before that. It happens when i have in console "Could not open file of texture" words, so maybe its something about nulldevice dunno.

Then, 1.6 version already have issues with shifted/disappeared textures and rotated zombies just like 1.7.x and 1.8.x.

Changes with camera happens to be exactly in 1.5 version, and till 1.8.4 they mostly didn't changes. So, i assume once i will undestand why 1.5.x versions cause crashes on loading, and fix it, i can see if 1.5 version have all those issues already.

But i just think, that its all can be my "migration ifdefs", because i do not know game's code, and only replace parts where compiler cry. Maybe some parts of code somewhere need to be changed because of that too, even if compiler happy. Will keep tri

[kas1e]

@CuteAlien
Can you clarify a bit about how releases done vs revision commits ? My issue is:

1) for example i download 1.4.2 release of irrlicht from there: https://sourceforge.net/projects/irrlic ... p/download
2). seeing the date of release, i browse through commit logs, and found, that 1.4.2 version was "tagged" at r1580.
3). I download r1580 and compare with 1.4.2 download: everything different.

So question is, how to find what exactly revision are in release archive i choice to test ?

For example now i want to find exactly what revision have the same 1:1 code as in 1.4.2. Can't understand at moment what wrong there, but for example "include" directory from the 1.4.2 download, and from r1580 are surely different.