migration from irrlicht 1.4.1 to 1.8.4

If you are a new Irrlicht Engine user, and have a newbie-question, this is the forum for you. You may also post general programming questions here.
CuteAlien
Admin
Posts: 9729
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: migration from irrlicht 1.4.1 to 1.8.4

Post by CuteAlien »

How and where do you check for shift+arrow? I made a quick & simple test and SDL correctly returns shift values at least in Irrlicht trunk (didn't check 1.8 right now, but code to set Shift value in SDL device looks identical).

Test:

Code: Select all

 
#include <irrlicht.h>
#include <iostream>
 
using namespace irr;
 
#ifdef _IRR_WINDOWS_
#pragma comment(lib, "Irrlicht.lib")
#endif
 
class MyEventReceiver : public IEventReceiver
{
    bool OnEvent( const SEvent &event )
    {
        if (event.EventType == EET_KEY_INPUT_EVENT)
        {
            if( event.KeyInput.PressedDown )
            {
                std::cout << "PressedDown:" << event.KeyInput.Key <<  " shift:" <<  event.KeyInput.Shift << std::endl;
            }
            else if( !event.KeyInput.PressedDown )
            {
                std::cout << "!PressedDown:" << event.KeyInput.Key << " shift:" <<  event.KeyInput.Shift<< std::endl;
            }
        }
 
        return false;
    }
};
 
int main()
{
    SIrrlichtCreationParameters params;
    params.WindowSize = core::dimension2d<u32>(640, 480);
    params.DriverType = video::EDT_OPENGL;
    params.DeviceType = EIDT_SDL;
    IrrlichtDevice * device = createDeviceEx(params);
    if (device == 0)
        return 1; // could not create selected driver.
 
    video::IVideoDriver* driver = device->getVideoDriver();
    MyEventReceiver receiver;
    device->setEventReceiver(&receiver);
 
    while(device->run() && driver)
    {
    }
 
    device->drop();
 
    return 0;
}
 
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
kas1e
Posts: 212
Joined: Sun Jan 21, 2018 8:39 am

Re: migration from irrlicht 1.4.1 to 1.8.4

Post by kas1e »

It's use shift like this:

Code: Select all

 
 
    for (s32 i=0; i<6; ++i)
        CursorKeys[i] = false;
 
    // create key map
    KeyMap.push_back(SCamKeyMap(0, irr::KEY_KEY_W));
    KeyMap.push_back(SCamKeyMap(1, irr::KEY_KEY_S));
    KeyMap.push_back(SCamKeyMap(2, irr::KEY_KEY_A));
    KeyMap.push_back(SCamKeyMap(3, irr::KEY_KEY_D));
    KeyMap.push_back(SCamKeyMap(4, irr::KEY_SHIFT));
 
Then, if i compile it via win32 device, that that code works:

if(CursorKeys[4]) { printf("we have shift!\n"); fflush(stdout); };

if i compile that over sdl device, then i never have that printf. Like that "CursorKeys[4]" is never have right value.


For sake of test i replace KeyMap.push_back(SCamKeyMap(4, irr::KEY_SHIFT)); , on KeyMap.push_back(SCamKeyMap(4, irr::KEY_KEY_J)); and then it works.

So it exactly KEY_SHIFT fail when its compiled for SDL, and works for win32 renderer.

Checked SDL code, i find out that block:

Code: Select all

 
    KeyMap.push_back(SKeyMap(SDLK_LSHIFT, KEY_LSHIFT));
    KeyMap.push_back(SKeyMap(SDLK_RSHIFT, KEY_RSHIFT));
    KeyMap.push_back(SKeyMap(SDLK_LCTRL,  KEY_LCONTROL));
    KeyMap.push_back(SKeyMap(SDLK_RCTRL,  KEY_RCONTROL));
 
But nothing like pure KEY_SHIFT (meaning any shift, not only right or left one).

So probabaly things not works with SDL, as there is no some KEY_SHIFT meaning both , and left and right. Probabaly that one can be added somehow like KeyMap.push_back(SKeyMap(SDLK_RSHIFT | SDLK_LSHIFT, KEY_SHIFT)); ?
CuteAlien
Admin
Posts: 9729
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: migration from irrlicht 1.4.1 to 1.8.4

Post by CuteAlien »

KEY_SHIFT should also no longer work on Win32 device in Irrlicht 1.8. This only worked back in Irrlicht 1.4, but is now converted to KEY_LSHIFT and KEY_RSHIFT. So you have to use those now. At least it looks to me like it when comparing the device code. That's unless you have a Windows before XP (some comment in code about the replacement not working on older Windows systems).
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
kas1e
Posts: 212
Joined: Sun Jan 21, 2018 8:39 am

Re: migration from irrlicht 1.4.1 to 1.8.4

Post by kas1e »

Tried to compile game over latest irrlicht code from trunk , to see how it will looks like, etc.

So, have 2 new errors with new code:

Code: Select all

 
CLevel.cpp: In constructor 'CLevel::CLevel(CGame*)':
CLevel.cpp:40:93: error: invalid new-expression of abstract class type 'irr::scene::CPlayerCameraSceneNode'
     m_pCamera = new CPlayerCameraSceneNode(m_pGame, m_pGame->getDevice(), 100.0f, 0.32f,NULL);
                                                                                             ^
In file included from CLevel.h:16:0,
                 from CLevel.cpp:1:
CPlayerCameraSceneNode.h:17:8: note:   because the following virtual functions are pure within 'irr::scene::CPlayerCameraSceneNode':
  class CPlayerCameraSceneNode : public CCameraSceneNode
        ^~~~~~~~~~~~~~~~~~~~~~
In file included from include_trunk/irrlicht.h:66:0,
                 from CLevel.h:13,
                 from CLevel.cpp:1:
include_trunk/ICameraSceneNode.h:167:16: note:  virtual void irr::scene::ICameraSceneNode::updateMatrices()
   virtual void updateMatrices() = 0;
                ^~~~~~~~~~~~~~
                                                              ^
 

And second one:

Code: Select all

 
CAIKamikazeZombie.cpp: In constructor 'CAIKamikazeZombie::CAIKamikazeZombie(CGame*, irr::core::vector3df, int)':
CAIKamikazeZombie.cpp:58:139: error: invalid new-expression of abstract class type 'irr::scene::CAABillboardSceneNode'
     m_pFire = new CAABillboardSceneNode(m_pNode->getJointNode("neck"), m_pGame->getSmgr(),-1,vector3df(0, 0, 0), dimension2d<f32>(50, 170));
                                                                                                                                           ^
In file included from CAIKamikazeZombie.cpp:9:0:
CAABillboardSceneNode.h:17:7: note:   because the following virtual functions are pure within 'irr::scene::CAABillboardSceneNode':
 class CAABillboardSceneNode : public IBillboardSceneNode
       ^~~~~~~~~~~~~~~~~~~~~
In file included from include_trunk/irrlicht.h:63:0,
                 from CAIKamikazeZombie.h:12,
                 from CAIKamikazeZombie.cpp:1:
include_trunk/IBillboardSceneNode.h:76:37: note:        virtual const irr::core::aabbox3d<float>& irr::scene::IBillboardSceneNode::getTransformedBillboardBoundingBox(const irr::scene::ICameraSceneNode*)
  virtual const core::aabbox3d<f32>& getTransformedBillboardBoundingBox(const irr::scene::ICameraSceneNode* camera) = 0;
                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
Have any ideas ? Looks like some missing methods, like some new ones was added ?


EDIT: oh , and even if i add those new 2 methods as dummy, it seems like CCameraSceneNode was changes pretty much. It have some new thing HasD3DStyleProjectionMatrix, so even constructor and all stuff changes. I tried to set it to 0, just like:

Code: Select all

 
    ViewArea.cameraPosition = getAbsolutePosition();
 
    core::matrix4 m(core::matrix4::EM4CONST_NOTHING);
    m.setbyproduct_nocheck(ViewArea.getTransform(video::ETS_PROJECTION),
                        ViewArea.getTransform(video::ETS_VIEW));
    //ViewArea.setFrom(m, HasD3DStyleProjectionMatrix);
    ViewArea.setFrom(m, 0);
 
Then, i was able to build it over latest trunks code, but then :

1. issues with some textures being shown only when i come close to it gone. So that definately bug in 1.8.4
2. zombies now looks fine visually, but moves in other way around. So seems something was changed, but not fully to make it be ok
3. some textures still not on the place where they should be
4. new bug : when i stay i just start to fall down.



So dunno , but probabaly i better need to stay with 1.4.1 version for that game, as migration to fresh irrlicht bring some new bugs, which i can't fix for sure.
CuteAlien
Admin
Posts: 9729
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: migration from irrlicht 1.4.1 to 1.8.4

Post by CuteAlien »

getTransformedBillboardBoundingBox can return getBoundingBox as fallback.
Camera has indeed changed again it seems. But why not just use the Irrlicht camera class if you use it unchanged anyway in your code?

Sorry, can't help with textures in wrong place and moving other way round. I really would like to have test-case so I could debug that. Without - I guess the bug will stay in :-( (tiny chance about the first one - I got some bug-reports about troubles with quaternions which are still on my todo, will get to those within a few weeks I hope).
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
kas1e
Posts: 212
Joined: Sun Jan 21, 2018 8:39 am

Re: migration from irrlicht 1.4.1 to 1.8.4

Post by kas1e »

Ok.. with those bugs i may try to made some test cases later.

Now, i have some other intersting bug, but that not related to 1.4.1 -> 1.8.4 migration, but still dunno if it something worth of creating another topic, as in end it all about the same game.

So, issue is, when i build game for win32, be it for irrlicht 1.4.1 , or for irrlicht 1.8.4 , floor always looks correct, like this:

http://kas1e.mikendezign.com/aos4/irrli ... _win32.jpg

Then, if i build the game for linux, or for amigaos4, for both, be it irrlicht 1.4.1 or irrlicht 1.8.4 , be it SDL or X11 renderer, floor looks wrong:

http://kas1e.mikendezign.com/aos4/irrli ... aos4_1.jpg

(see, all like "fog sky").

But texture loads fine, etc, because if i move head down, then i can see it (still wrongly by color, but still):

http://kas1e.mikendezign.com/aos4/irrli ... aos4_2.jpg

Sure you don't know how it all coded, but maybe visually you can think of anything which can somehow be related ?

I mean, strangely it works for win32, but didn't for other oses. Like, there is some "only works for win32" thing done, which i do not know where to look at at moment..

From implementation side, i can see that there is some *.irr file, in which we do just that:

Code: Select all

 
    <node type="octTree">
 
        <attributes>
            <string name="Name" value="" />
            <int name="Id" value="-1" />
            <vector3d name="Position" value="-35.984428, -0.494462, 0.000000" />
            <vector3d name="Rotation" value="0.000000, 0.000000, 0.000000" />
            <vector3d name="Scale" value="300.000000, 300.000000, 300.000000" />
            <bool name="Visible" value="true" />
            <enum name="AutomaticCulling" value="box" />
            <int name="DebugDataVisible" value="0" />
            <bool name="IsDebugObject" value="false" />
            <int name="MinimalPolysPerNode" value="256" />
            <string name="Mesh" value="data/plan.ms3d" />
        </attributes>
 
        <materials>
            <attributes>
                <enum name="Type" value="solid" />
                <color name="Ambient" value="ff5c5c5c" />
                <color name="Diffuse" value="ffcccccc" />
                <color name="Emissive" value="ff000000" />
                <color name="Specular" value="ff000000" />
                <float name="Shininess" value="0.128000" />
                <float name="Param1" value="0.000000" />
                <float name="Param2" value="0.000000" />
                <texture name="Texture1" value="data/g1.jpg" />
                <texture name="Texture2" value="" />
                <texture name="Texture3" value="" />
                <texture name="Texture4" value="" />
                <bool name="Wireframe" value="false" />
                <bool name="GouraudShading" value="true" />
                <bool name="Lighting" value="true" />
                <bool name="ZWriteEnable" value="true" />
                <int name="ZBuffer" value="1" />
                <bool name="BackfaceCulling" value="true" />
                <bool name="FogEnable" value="false" />
                <bool name="NormalizeNormals" value="true" />
                <bool name="BilinearFilter1" value="true" />
                <bool name="BilinearFilter2" value="true" />
                <bool name="BilinearFilter3" value="true" />
                <bool name="BilinearFilter4" value="true" />
                <bool name="TrilinearFilter1" value="false" />
                <bool name="TrilinearFilter2" value="false" />
                <bool name="TrilinearFilter3" value="false" />
                <bool name="TrilinearFilter4" value="false" />
                <bool name="AnisotropicFilter1" value="false" />
                <bool name="AnisotropicFilter2" value="false" />
                <bool name="AnisotropicFilter3" value="false" />
                <bool name="AnisotropicFilter4" value="false" />
                <enum name="TextureWrap1" value="texture_clamp_repeat" />
                <enum name="TextureWrap2" value="texture_clamp_repeat" />
                <enum name="TextureWrap3" value="texture_clamp_repeat" />
                <enum name="TextureWrap4" value="texture_clamp_repeat" />
            </attributes>
        </materials>
    </node>
 
That *.irr file have a lot of other models of the same ms3d format loaded, with the same textures attributes, etc ,etc : all of them looks correct in game.

Just this one by some reasson only works on win32 as expected and not on linux/amigaos4.

EDIT: at least i found value changing of which made some effect : that is "scale". Originally its 300.000000 in all 3 places, and once i start to reduce that value, the more i reduce it, the more floor i can see. Once i reduce it to minimum, i can see then original floor's color, like fog not overwrite it anymore that much. It looks, like there is simply some problem with the UVs. Maybe fog is calculated just per vertex and then interpolated and because its so big, something gets fucked.. But then , why it works for win32 ? :)
CuteAlien
Admin
Posts: 9729
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: migration from irrlicht 1.4.1 to 1.8.4

Post by CuteAlien »

That floor is just a normal model? Not floorscenenode? And a simple solid material?
Try if it has to do with light by disabling lighting by setting Lighting to "false". Doesn't look too much like it, but in combination with strong ambient light it might give you that effect if something is broken.

You can also experiment with AutomaticCulling = "false" to ensure it doesn't clip the polygon on some view-angles (so the gray would be background and not polygon, thought it wouldn't explain the strange colors when looking down). And very unlikely - but checking BackfaceCulling "false" for a quick test at least won't hurt. And so on - play with colors, filters, texture-wrapping and see if anything changes. You can even replace octree with some static node (octree's might clip wrong).

edit: Another idea - maybe the bitfield flags in SMaterial are causing troubles. Stuff like "bool Lighting:1;" - maybe try for a test replacing those like "bool Lighting;".
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
kas1e
Posts: 212
Joined: Sun Jan 21, 2018 8:39 am

Re: migration from irrlicht 1.4.1 to 1.8.4

Post by kas1e »

@CuteAlien
That floor is just a normal model? Not floorscenenode? And a simple solid material?
At least when i load it to 09.MeshViewer it have "solid" and i can load it as usuall mesh via "open model" and the same with set "Octree SceneNode" flag. Its the same on both amigaos4 and linux , so seems model itself are fine.

Now, that what i tried:

1). set lighting to "false" : things changes a bit: now i can see more offteen floor, i.e. when i move head down a little, when move left-ritght a little. But if i tried to move in all direction more than just a bit, bug still there.
2). instead of <node type="octTree"> , tried <node type="mesh"> : no changes
3). set "AutomaticCulling" to "false" instead of "box" : no changes
4). set "BackfaceCulling" to "false" instead of "true" : no changes
5). replace "bool Lighting:1;" in irrlicht's include SMaterial.h on "bool Lighting;" : no changes

Now what else i tried:

1). set FogEnable to "true" instead of original "false" : no changes
2). tried <enum name="Type" value="trans_alphach" /> instead of "solid" : no changes

Visually i can see how game's "fog" overwrite floor more than it expected and not on the necessary place. So, only visual change i found is when lighting is disabled, but that only show the problem more visibly, just without lighting.

See it on video: https://www.youtube.com/watch?v=fBHBTWkpBss
CuteAlien
Admin
Posts: 9729
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: migration from irrlicht 1.4.1 to 1.8.4

Post by CuteAlien »

OK, very strange. Next candidate are mipmaps. With 1.8 you should have a parameter UseMipMaps (a boolean). Or hardcode to disable them in the material. Thought not sure why they would enable/disable on rotation, it would explain the problem otherwise pretty well if your mipmaps are all gray and so every time it starts flipping to those things get messed up.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
kas1e
Posts: 212
Joined: Sun Jan 21, 2018 8:39 am

Re: migration from irrlicht 1.4.1 to 1.8.4

Post by kas1e »

Its just looks like some switched axes (because fog should't change depending on camera rotation, it should change only when camera position changes)..
kas1e
Posts: 212
Joined: Sun Jan 21, 2018 8:39 am

Re: migration from irrlicht 1.4.1 to 1.8.4

Post by kas1e »

Is it enough for mipmap disabling just replace "bool UseMipMaps:1;" on "bool UseMipMaps;" in Irrlicht's include ? If so, tried as well, nope, same :) In 1.4.1 there the same issue anyway, so probably not relate to mipmaps.
What is puzzling me most : why fine on win32, and didn't on linux and amigaos4. Ok the latter can be buggy because obscure, but linux ? Its like some floats got messed for axes.
CuteAlien
Admin
Posts: 9729
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: migration from irrlicht 1.4.1 to 1.8.4

Post by CuteAlien »

kas1e wrote:Is it enough for mipmap disabling just replace "bool UseMipMaps:1;" on "bool UseMipMaps;" in Irrlicht's include ? If so, tried as well, nope, same :) In 1.4.1 there the same issue anyway, so probably not relate to mipmaps.
No the :1 has nothing to do with values. This tells the compiler to try only using a single bit for a bool (usually it's size is same as int).
You have to set it explicitely to false either per code or per xml.
kas1e wrote: What is puzzling me most : why fine on win32, and didn't on linux and amigaos4. Ok the latter can be buggy because obscure, but linux ? Its like some floats got messed for axes.
Mipmaps can be a driver problem. Also OpenGL has 2 different mipmap implementations (one basically legacy between GL 1.4 and 3.0 and the other from 3.0 on). And it might only support one of them and chose the wrong one for example.

edit: If it's about Fog - just disable fog for testing.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
kas1e
Posts: 212
Joined: Sun Jan 21, 2018 8:39 am

Re: migration from irrlicht 1.4.1 to 1.8.4

Post by kas1e »

Adding to that mesh <bool name="UseMipMaps" value="false" /> , didn't change things too ..

Disabling fog for just this mesh didn't help : the same.

But then i tried to disable fully fog in game itself : and then, floor there !

The code which is related to fog-update in the game looks like this:

Code: Select all

 
//! update map
void CLevel::update(int delta)
{
  
  //dynamic fog
    float start = 250.0 + 100.0*sin((float)m_pGame->getTime()/3000.0);
    float end = 1500.0 + 300.0*sin((float)m_pGame->getTime()/2000.0);
    #ifdef __irrlicht_1_8_4__
    m_pGame->getDriver()->setFog(SColor(0,100,101,105), video::EFT_FOG_LINEAR, start, end, 0, true, false);
    #else
    m_pGame->getDriver()->setFog(SColor(0,100,101,105), true, start, end, 0, true);
    #endif
  
    //update timer
    m_nTimeSinceLastSound += delta;
    
    int rt = matika.getRandom(0, 15000) + 25000;
 
 
    //sound FX
    if(m_nTimeSinceLastSound > rt)
    {
        #ifndef NOIRRKLANG
        int r = matika.getRandom(0, 1);
        
        char tmp[64];
        sprintf(tmp, "./data/sounds/CrowCalls%d.wav", r);
        
        m_pGame->getSoundEngine()->play2D(tmp, false);
        #endif
        
        m_nTimeSinceLastSound = 0;
    }
}
 

Then, in the void CLevel::processMap() it do node->setMaterialFlag(EMF_FOG_ENABLE, true); .

So once i comment out those those 2 lines, floor is here and visibly fully.

I do not know, maybe that sin(float) with getTime() somehow make things wrong ? Maybe there something wrong even for win32, just win32 as usuall auto-fix things ?
Or maybe getTime() realisation for win32 and linux (and so amigaos4 , it share same posix code in irrlicht) differs somehow ?

ps. i also send you in PM link on that .cpp where those 2 parts for fog placed, so you can see yourself how it all structured.

EDIT:

I printf "start" and "end" values on win32 and on amigaos4 to compare, and that what i have:
 
start on win32 (and didn't move):
 
start = 201.321335 | end = 1283.089600
start = 200.972321 | end = 1284.336914
start = 200.827118 | end = 1284.859009
start = 200.682068 | end = 1285.382324
start = 200.537155 | end = 1285.906982
 
start on amigaos4 (and didn't move):
 
 
start = 151.215775 | end = 1657.127930
start = 150.106888 | end = 1726.323730
start = 150.210571 | end = 1731.748169
start = 150.337982 | end = 1736.622437
start = 150.495331 | end = 1741.336792
 
 
Numbers surely different at begining, but looks sane enough. Maybe that difference enough to broke things like that .. but then, they should be different on each run probabaly because of getTime() (imho).
CuteAlien
Admin
Posts: 9729
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: migration from irrlicht 1.4.1 to 1.8.4

Post by CuteAlien »

getTime() returns milliseconds since program start I think.

About fog... unfortunately yet another thing I never worked with myself. I just tried reading up on it a bit and it seems OpenGL directly has fog functions and basically those are used. Why disabling fog for a mesh makes no difference is a riddle - it definitely should make a difference. Maybe your node material is not identical to the mesh material?

Fog might be driver specific. Especially the rangeFog flag seems to use a nvidia extension. And in your case - it might be that some of your drivers don't support pixel-fog, but always use vertices for calculations. That would also explain why scaling changes it so much.

You could set a breakpoint in COpenGLDriver::setFog and compare how it steps through there.

Maybe IRR_EXT_fog_coord is not available on some platforms? I guess that case should be handled in Irrlicht (we could set coordinates manually with glFogCoord instead of automatic calculations from GL_FRAGMENT_DEPTH, thought not sure where to do that).

Code in COpenGLDriver::setFog looks pretty simple, so stepping through is probably worth it for comparison. Only other code I found is the glEnable and glDisable for GL_FOG based on the material setting.

edit: Just made a quick test on Linux by adding fog to demo and setting or not setting the IRR_EXT_fog_coord stuff made no difference at all as far as I could see. So not sure what that is really about.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
kas1e
Posts: 212
Joined: Sun Jan 21, 2018 8:39 am

Re: migration from irrlicht 1.4.1 to 1.8.4

Post by kas1e »

Fog might be driver specific. Especially the rangeFog flag seems to use a nvidia extension. And in your case - it might be that some of your drivers don't support pixel-fog, but always use vertices for calculations. That would also explain why scaling changes it so much.

You could set a breakpoint in COpenGLDriver::setFog and compare how it steps through there.
Probabaly that the way to go for me currently, to see if there is differences in handling of fog inside of setFog() for win32 and others. If there will be difference, then that will be good, at least something :)
Post Reply