RealisticWater node with V1.6

[Chet]

Taking the plunge to move to v1.6 and getting compile errors on realisticwater node.
Can someone point me to what changed to cause this?

Code: Select all

no matching function for call to `irr::video::IVideoDriver::addRenderTargetTexture(irr::core::dimension2di&)' 

And of course how to fix.

EDIT: Actually seems a fair number of errors moving to 1.6 (guess why I put it off) peeled thru a few but now(commented out realistic water for now) I have an access violation(segmentation fault) when I try to run. The examples I tried seem to run fine and I am not really doing much different.
EDIT2: ok all fixed except the water node

[vitek]

There are lots of changes from core::dimension2d<s32> to core::dimension2d<u32>.

Travis

[GameDude]

I don't wanna overtake this guy's thread, but I was just wondering why there was a change with s32 to u32?

[olivehehe_03]

The only place I've noticed it changed is in irr:createDevice which now takes a core::dimension2d<u32> and it seems to make sense if you consider there's no real advantage to using a signed variable to set resolution when there's no need for it to be negative. I assume it's the same alot of the other places it's been changed, that it was swapped to unsigned because it didn't need to be negative

[DavidJE13]

all texture dimensions are now unsigned, which makes sense (a signed dimension is pretty pointless - negative most often mean an error). This means constructor, dimension sizing, and creating render texture targets (which is what the water node is doing) are effected.

so as vitek said, change all dimension2di (and dimension2d<s32>) to dimension2du and you'll be fine.

Something I'd like to know is why there's no dimension2du = dimesion2di assignment, which would have avoided all these bugs... (though maybe not in the most efficient way)

[DtD]

Prolly my fault: http://irrlicht.sourceforge.net/phpBB2/ ... highlight=
It is mostly as a "clarification" thing.

As for assigning dimension2du = dimesion2di idea, that would cause tons of problems. While it might help Irrlicht, it would break other game code, and it would just create another confusion.

dimension2du = dimensions 2d Unsigned
dimension2di = dimensions 2d (Signed) Integer

~DtD

[DavidJE13]

sorry, wasn't clear

I meant why isn't there a constructor for dimension2du which takes a dimension2di, thus allowing code like;

Code: Select all

dimension2du a = dimension2di( 3, 3 );

which would prevent all these problems, and is a logical thing to have anyway.

[vitek]

There is no such assignment because there are many cases where it doens't make sense. What would you expect the result of the following to be?

Code: Select all

const core::dimension2d<s32> di(-1, -1000)
const core::dimension2d<u32> du(di);

printf ("du.X = %u du.Y = %u\n", du.X, du.Y);

Would you expect the conversion to generate a warning about truncation of a signed value? If such a warning happened, would you expect the problem be fixed in Irrlicht? Assume that someone fixed the warning in Irrlicht code. Now someone else uses it and their code compiles cleanly but has a subtle error introduced by this conversion. What should happen now?

Also, consider that allowing conversion from one template type to another opens the door for other conversions. You want the conversion from core::dimension2d<s32> to core::dimension2d<u32>, but what about the other way around? What about implicit conversion between core::dimension2d<f32> and core::dimension2d<u8>? Is that desireable? Without some interesting template tricks, it is not easy to limit conversions that users might not want.

The library maintainers have no way to determine if these conversions are beneficial to the user. It is _usually_ best to force the user to explicitly say what he wants instead of allowing something to happen silently. Especially if the allowing it silently has negative side effects.

Travis