migration from irrlicht 1.4.1 to 1.8.4

[CuteAlien]

We still got antialiasing as an option. Not quite sure what's available on Amiga. But those could be some options to play with:
glEnable/glDisable(GL_SAMPLE_ALPHA_TO_COVERAGE_ARB);
glEnable/glDisable(GL_MULTISAMPLE_ARB);

And there's also in CGLXManager (or whichever opengl context manager is used on AmigaOS) the stuff like
GLX_SAMPLE_BUFFERS, 1,
GLX_SAMPLES, Params.AntiAlias,

I fixed there actually something just a few weeks ago. Thought understanding the OpenGL documenation about this is a bit hard and I think the drivers also have some flexibility in interpreting it.
Note that changes in there can also affect the "Visual" which is chosen. Like the result of glXChooseVisual in CGLXManager (other gl context managers have similar concepts). That "Visual" is a combination of resolution, bit-depth and maybe some internal settings which the OS gives you to render on. And sometimes there are similar/near identical visuals which do have slightly different results. So this might also be one place where you could compare if you got the same result in 1.4 and 1.8.
(edit: On some systems you will even get that number as log-output already. Check your console-log for a message like: "Visual chosen" and check if the number after that is the same).

[kas1e]

Do you think it can be that irrlicht set GL_NEAREST and then on top antialiasing (so to have "original" image again) ?:)

[kas1e]

Found some interesting stuff : i just trace the binary where image looks clean (v1.4.1 irrlicht release) and one where it already didn't (some r1500), there is:

http://kas1e.mikendezign.com/aos4/irrli ... Params.txt : there image clean

http://kas1e.mikendezign.com/aos4/irrli ... Params.txt : there image already not clean

See, there difference in glTexParams, and as well its just really different. Strange !

What i can see, is that for first in non-working version, we have GL_TEXTURE_MAX_ANISOTROPY_EXT, param 1 everywhere (while in working version none).

Also i didn't see in non-working version, that anywhere they set GL_TEXTURE_MIN_FILTER, param GL_LINEAR: in non working version it sets to GL_NEAREST (so as it looks like).

Also in non-working version glTexImage2D do some block repeating two times, dunno for what.

And in end, in non working version we do set GL_TEXTURE_WRAP_S and GL_TEXTURE_WRAP_T to GL_REPEAT, while in working version we do set them to GL_CLAMP_TO_EDGE.

Lots of differences, and which one cause such issue .. And why only on amigaos4 & pandora and why it fine on win32 ..

Maybe that ANYSOTROPY_EXT thing may cause that ?

But realistically it looks like indeed GL_NEAREST set instead of GL_LINEAR.

[CuteAlien]

Sorry, I can't test this obviously. I can only repeat my recommendation - test what happens if you set that stuff in the draw2DImage functions directly before glDrawElements is called. If it behaves different when you set there to GL_NEAREST or GL_LINEAR we know it's that. If it makes no difference it's something else. Same with GL_CLAMP_TO_EDGE (unlikely as this doesn't happen at edges).

I doubt it's the anisotropy as that only matters if you have "depth" (different z-values).

[kas1e]

@CuteAlien
I think i found issue : that is NPOT vs POT thing. Seems that ogles2 on amigaos4 and on pandora give only limited NPOT support, which mean, that once NPOT textures happens, it then use some crude-scale algo to make them POT. On win32 and linux it works just because everything supported. At least from tests, once i made texture be not 1024x768, but 1024x1024, then all fine. Once its out of POT values , then some kind of distortion always present.

Through, that didn't explain why it works fine for me in 1.4.1 , but maybe some luck. Or maybe some gl-mode / filtering was enabled/disabled which make it works.

[CuteAlien]

I wonder why it worked before. Maybe had some scale up/down which was symetric before so you got back the original image? There is one patch-note in 1.5.1 about copyToScaling fixed, not sure what that was about.

I remember I even wrote a patch for it once 12 years ago (long before I was in the Irrlicht team) which allowed to use padding instead of scaling. But guess that no longer can be used without putting in some work (and lots of testing).

Phew, not something that was on my todo :-( Not sure what to do right now, as I'm already running short on time to get 1.9 still released until end of year and I run out of stuff to kick to post 1.9 release (next year I will have to do other projects again, so if I miss this chance it's likely going to take a lot longer again, not just a few weeks). I can put this on my list, but chance it'll make it into 1.9 is rather low. Sorry, I'm simply having to many open tasks already.

Workaround: Scale your images or pad them (padding them and then using draw-calls with the old size, which you likely will have to hard-code). If there's not many places this can work. If you have lots of UI to rework for this... uhm... don't know... more work?

[kas1e]

@CuteAline
I think i will go very easy route : ask amigaos4 ogles2 mantainers to add npot extensions (as in general they works , just there wasn't needs for extensions be added). So once they added, all should works as it. And if not, then after that we can discuss it futher, but at moment nothing to worry

as I'm already running short on time to get 1.9 still released until end of year and I run out of stuff to kick to post 1.9 release

Should i start to betatest all the examples and stuff in beta trunk, to compare if there is some regressions being made ? From top of head, i remember there was 2 regression : 1). speed on meshviewer drops (when you just load default dwarf) 2). There was visuall differences in that example which show a fire and rotated ball (do not remember the number). But i can made a proper retest and put the info in some "beta pre1.9.0" thread, what you think ?

[CuteAlien]

Sounds good in theory, thought it's really not yet in beta-state :-( (that's why I have so many todo's left...).

I just took another look at that patch I did for the NPOT stuff back then and it looks actually not too hard and likely not messing too much with existing stuff as it's only used when people set a specific global texture flag. I guess losing one more day won't matter much anymore at this point and it's a useful feature. I'll look if I can add it (it needs a second patch first, still have to look at that one).

[CuteAlien]

OK, sorry. Adding my patch turned out to be not so trivial, so giving up on it for now.
But interesting enough while trying that I found out I have introduced another bug 2 years ago because I misunderstood how draw2dImage works. I always thought source-rectangle was based on the texture - but it's based on the image used to create the texture.

And have a nice quick test now which probalby which shows that scaling is indeed not particularly nice. It's slightly better looking on D3D9 in my test-case than opengl, but both really not great:

Code: Select all

 
#include <irrlicht.h>
#include <iostream>
 
using namespace irr;
 
#ifdef _IRR_WINDOWS_
#pragma comment(lib, "Irrlicht.lib")
#endif
 
 
int main()
{
    video::E_DRIVER_TYPE driverType = video::EDT_OPENGL;
    //video::E_DRIVER_TYPE driverType = video::EDT_DIRECT3D9;
    IrrlichtDevice * device = createDevice(driverType, core::dimension2d<u32>(640, 480));
    if (device == 0)
        return 1; // could not create selected driver.
 
    video::IVideoDriver* driver = device->getVideoDriver();
    gui::IGUIEnvironment* env = device->getGUIEnvironment();
 
    video::IImage* imgLogo = driver->createImageFromFile("../../media/irrlichtlogo.jpg");
    
    video::ITexture * logo = driver->addTexture("logo", imgLogo);
    driver->disableFeature(video::EVDF_TEXTURE_NPOT, true);
    video::ITexture * logoScaled = driver->addTexture("logoscaled", imgLogo);
 
 
    // Create a texture with padding
    video::ITexture * logoPadded = 0;
    const core::dimension2du origDim = imgLogo->getDimension();
    const bool needSquare = false;
    const u32 maxTextureSize = core::min_(driver->getMaxTextureSize().Width, driver->getMaxTextureSize().Height);
    core::dimension2du dimOptimal = origDim.getOptimalSize(!driver->queryFeature(video::EVDF_TEXTURE_NPOT), needSquare, true, maxTextureSize);
    if ( dimOptimal != origDim)
    {
        video::IImage* imgLogo2 = driver->createImage(imgLogo->getColorFormat(), dimOptimal);
        memset(imgLogo2->getData(), 0, imgLogo2->getDataSizeFromFormat(imgLogo2->getColorFormat(), dimOptimal.Width, dimOptimal.Height));   // set to black
        core::vector2di pos((dimOptimal.Width-origDim.Width)/2, (dimOptimal.Height-origDim.Height)/2);
        imgLogo->copyTo(imgLogo2, pos, core::recti(0,0, origDim.Width, origDim.Height), 0);
 
        logoPadded =  driver->addTexture("logopadded", imgLogo2);
        imgLogo2->drop();
    }
 
    imgLogo->drop();
 
    gui::IGUIImage* uiLogo = env->addImage(core::recti(10, 200, 200, 290));
    uiLogo->setImage(logo);
    uiLogo->setScaleImage(true);
 
    gui::IGUIImage* uiLogoScaled = env->addImage(core::recti(10, 300, 200, 390));
    uiLogoScaled->setImage(logoScaled);
    uiLogoScaled->setScaleImage(true);
 
    while(device->run() && driver)
    {
        if (device->isWindowActive())
        {
            driver->beginScene(true, true, video::SColor(0,200,200,200));
 
            driver->draw2DImage(logo, core::position2d<int>(10, 10));
            driver->draw2DImage(logoScaled, core::position2d<int>(120, 10));
            driver->draw2DImage(logoPadded, core::position2d<int>(120, 50));
            driver->draw2DImage(logoScaled, core::recti(120, 100, logoScaled->getSize().Width+120, logoScaled->getSize().Height+100),
                    core::recti(0,0,logoScaled->getOriginalSize().Width,logoScaled->getOriginalSize().Height));
 
            env->drawAll();
 
            driver->endScene();
        }
    }
 
    device->drop();
 
    return 0;
}
 

But at least for this test-case even Irrlicht 1.4 looks bad (which didn't have disableFeature yet, I just changed engine back there for testing).

[CuteAlien]

I've changed latest svn trunk branch [r5994] to at least improve the scaling a bit.
edit: r5995 optimizes it a bit to get back to old speed

[kas1e]

Oh ! With your last fixes it start to looks much better. Not that pretty as with real npot support, but much better than before.

Through, there is still some issue left (which wasn't very visibly before, but seeing in now, i can see it was there all the time, just wasn't well visibly because of bad scaling) : some words have missed some lines of pixels. See it on new screenshot (see for example to of word "repeair" at left side of image):



With 1.4.1 everything clean and there no missing lines of pixels (strange yes why it works, maybe indeed some NPOT patch was applied, but then somehow disappear).
Maybe that just trade-off of not having real NPOT support, i mean, its expected to be like that because of scaling algo ?

[CuteAlien]

Missing lines also look like a scaling artifact.

I could think of one (somewhat ugly) workaround which may work, but depends on your code how _much_ work it would be.
In my code above I've added code for "padding". As your image here seems to be black at borders - you could create images which are padded with a black border. But you then you might have to modify the positions by the amount of padding.
edit: Btw, I forgot to mention, but you can run that code by copying it over one of the examples for a quick test.

[CuteAlien]

Just noting that 1.9 release once more will be delayed for unknown amount of time. Some TODO's turned out to be way harder than I had hoped for (especially figuring out the changes to transparent render passes / zwriting / blending). And still got enough todo's on my list for another 2-3 weeks fulltime coding (at least). Plus stuck on a new bug I added while fixing the FPS-camera (now impossible to click windows on X11 without them jumping around and fixing is tricky and I likely have to add focus-events first to Irrlicht, also something I had hoped to fix in a day, but didn't work out). edit: Just found out the WindowResizable changes we did for SDL also broke something on X11 (window icons are messed up now when calling setResizable(true)).

And now the free time I had (and used for Irrlicht) is over again, so ... no idea - let's hope I still find enough time to get it released by summer or so :-(

[kas1e]

@cutealien

Still alive ?:)

Tried to migrate one game from 1.5.2 to 1.8.4 and stumbed across some parts, maybe you can be of any help there if you have time ..

There is :

A lot of issues about collistionpoint changes:

Code: Select all

 
getSceneCollisionManager()->getCollisionPoint(line, _selector, vec, tri);
...
error: no matching function for call to ‘irr::scene::ISceneCollisionManager::getCollisionPoint(irr::core::line3df&, irr::scene::IMetaTriangleSelector*&, irr::core::vector3df&, irr::core::triangle3df&)’
     _smgr->getSceneCollisionManager()->getCollisionPoint(line, _selector, vec, tri);
 

This one I fix by just adding hitNode after "tri", and "scene::ISceneNode* hitNode;" at the beginning (so some unused stuff will be, just to make the compiler happy).


Then setfogs issues, like:

Code: Select all

 
_driver->setFog(video::SColor(0, 0, 0, 0), false, 0, 0, 0.f, true, false);
 error: no matching function for call to ‘irr::video::IVideoDriver::setFog(irr::video::SColor, bool, int, int, float, bool, bool)’
  _driver->setFog(video::SColor(0, 0, 0, 0), false, 0, 0, 0.f, true, false);
 

Fixed this by replacing the first false on video::EFT_FOG_LINEAR.


Then:

Code: Select all

 
_decalImage = _driver->createImage(video::ECF_A8R8G8B8, core::dimension2di(48, 48));
...
 error: no matching function for call to ‘irr::video::IVideoDriver::createImage(irr::video::ECOLOR_FORMAT, irr::core::dimension2di)’
   _decalImage = _driver->createImage(video::ECF_A8R8G8B8, core::dimension2di(48, 48));
 

That one I fix by changing dimension2di on dimension2du.


In the end have few issues with c_str, like these ones:

1. cout << _node->getMaterial(0).getTexture(0)->getName().c_str() << endl;
2. scene::IMeshSceneNode *mesh = _smgr->addMeshSceneNode(_smgr->getMesh(modelPath.c_str()));
3. mesh->setMaterialTexture(0, _driver->getTexture(texturePath.c_str()));


And another compilation issue:

1. if (strstr(_smgr->getMeshCache()->getMeshFilename(i), ".bsp"))

says error: no matching function for call to ‘strstr(const path&, const char [5])’

Also a bit of warning about deprecated addOctTreeSceneNode(), but I hope they harmless as it builds still anyway.

[CuteAlien]

Hey! Yeah I'm staying alive, staying alive, staying alaahaahaive.

Sounds like you solved first 3 issues yourself already :-)

Texture returns SNamedPath now instead of stringc. You could convert to core::stringc(), but better to use .getPath() or .getInternalName(). So like:
cout << _node->getMaterial(0).getTexture(0)->getName().getPath().c_str() << endl;
Previously you always got the result of getInternalName, which is a version of the name which is more or less a lower-case version of the name (so MyTexture.jpg and mytexture.jpg are the same internally as is the case with many filesystems). While getPath() returns the original filename.

For IMeshCache::getMeshFilename - seems that return c8* in the past and now path, so you could fix with adding a .c_str(). But better - replace it by IMeshCache::getMeshName().getPath().c_str(). (or getInternalName instead of getPath() - same as above).

Don't know problems with texturePath and modelPath - I need to see their definition.

addOctTreeSceneNode had a spelling error - it's addOctreeSceneNode now (one T gone). Does the same and if you plan to switch some day to trunk (or Irrlicht 1.9 one day...) I think you have to use the correct spelling by now as other one seems to be gone.