Zini
13-11-2007 14:35:00
While searching for the other bug, I had a look at Widget::overTransparentPixel.
The values I am getting don't look wrong. With the first check the smallest value is 0, which should be ok. You test here on <= 0. But shouldn't it be <0 instead?
The second test gives low values between -1 and 0. That is because you are subtracting -1
This argument
doesn't sound valid. And you are still deliberately moving below 0 here.
Did you notice, that you are doing calculations with floating point numbers here and that they are not guaranteed to be accurate anyway? In this case that means you can always slide a bit beyond the limits of the texture.
Before calling
you need to make sure that xpos and ypos are valid with something like this:
The values I am getting don't look wrong. With the first check the smallest value is 0, which should be ok. You test here on <= 0. But shouldn't it be <0 instead?
if (pt.x <= 0 || pt.y <= 0)
The second test gives low values between -1 and 0. That is because you are subtracting -1
const Ogre::Real xpos = (relX * mWidgetImage->getWidth()) - 1;
const Ogre::Real ypos = (relY * mWidgetImage->getHeight()) - 1;
This argument
// Reason I subtract 1 from width and height: Cannot access pixel 10 in an image of width 10. 0-9..
doesn't sound valid. And you are still deliberately moving below 0 here.
Did you notice, that you are doing calculations with floating point numbers here and that they are not guaranteed to be accurate anyway? In this case that means you can always slide a bit beyond the limits of the texture.
Before calling
mWidgetImage->getColourAt(xpos,ypos,0);
you need to make sure that xpos and ypos are valid with something like this:
if (xpos < 0 )
xpos = 0;
else if (xpos >=mWidgetImage->getWidth())
xpos = mWidgetImage->getWidth()-1;
