migration from irrlicht 1.4.1 to 1.8.4

[kas1e]

@CuteAlien
Thanks!

We (with the author) have already working build over 1.8.4, but it as expected gives some errors here and there. Especially in animation parts: all character animations are off. The author explains that this kind of issue he has years ago when tried to migrate to Irrlicht 1.6.x, where seems something was changed in the lib regarding animations and how they loop, and it breaks everything compiled previously. Also seems collisions broken in some parts (i can't move close to some parts to which I can with 1.5.2).

So, at first, i tried to just port 1.5.2, but in comparison with even 1.6.x (Taking aside 1.8.4) it's just damn broken much: there seems weren't big-endian support for loading from .bsp (so examples such as quake3 loader map fail with grey screen), SDL renderer also was broken very much.

In other words, we probably have just 2 ways :

1). 1.5.2 build and backport (somehow) .bsp loading + SDL driver from 1.8.4 / 1.9.x
2). 1.8.4. build, but put there back animation from 1.5.2

Rewriting of game's code itself there looks like a more time-consuming part (much more), so probably i need to choose something from...

[CuteAlien]

I can't say much about 1.5 or 1.6, that's too long ago. Between 1.7 and 1.8 there was a big change in quaternions which can affect animations if you used them. To test you can compile your app with IRR_TEST_BROKEN_QUATERNION_USE enabled in quaternion.h - if it has compile errors you have to change those lines to adapt to 1.8.

Otherwise - if you can post the broken animations or send them to me then I can take a look if I see any problems. As usual I can't do anything without a test-case.

[kas1e]

@CuteAlien
I just go the easy route and use 1.5.2, it was a matter of some small fix to make it works in BSP loading on PPC.

Now, what I found is another strange error, which happens and on 1.5.2 and on 1.8.4 on PPC, but not on Win32.

There is relevant part of simple code:

Code: Select all

 
            _cpsplash = _driver->getTexture("textures/cpsplash.png");
            p = core::position2di(width / 2 - _cpsplash->getSize().Width / 2, height / 2 - _cpsplash->getSize().Height / 2);
            rect = core::rect<s32>(0, 0, _cpsplash->getSize().Width, _cpsplash->getSize().Height);
            _driver->draw2DImage(_cpsplash, p, rect, NULL, video::SColor(255, 255, 255, 255), true);
 

Now, an image is a normal .png image, 32 bits, size 403x570. There original image: http://kas1e.mikendezign.com/aos4/irrli ... splash.png
And now, how it looks like when this part of code draw it on my setup: http://kas1e.mikendezign.com/aos4/irrli ... enshot.jpg

And that and on 1.5.2 irrlicht, and on 1.8.4

On win32 the same compiled code looks like this: http://kas1e.mikendezign.com/aos4/irrli ... _win32.jpg

I go via printf debugging , and find out, that _cpsplash->getSize().Width and _cpsplash->getSize().Height seems to return incorrect values at me : _cpsplash->getSize().Width = 512 and _cpsplash->getSize().Height = 1024. While an image is 403 x 570.

Seems something wrong in terms of endian in that part somewhere?

And that the same and for .png, and for .jpg, etc. For example, if I tried .jpg of 1909x720x24, then it shows me that width 2048 and height 1024

[Mayto]

Hey!
I've sent you the solution by mail, but to save CuteAlien some time:
Nothing little/big endian here, on some hardware the textures are converted to power of two textures on loading. So it really is an issue in my code, you can solve it by using getOriginalSize() instead of getSize().