draw2DImage source rectangle

[Ulf]

How do you use the source rectangle when calling draw2DImage?

As an example, the fireball texture is 64*64 pixels and I want to pass in the whole image rectangle.
Should I use a rectangle as follows? (0 to 63)

Code: Select all

ITexture * fireballTexture = driver->getTexture("../media/fireball.bmp");
recti fireballTextureFrame(0,0, 63, 63);
driver->draw2DImage(fireballTexture, vector2di(0,0), fireballTextureFrame);


When you get the width of a rectangle, it returns the length from the upper left starting point to the lower right point. It's not the count of pixels if you were thinking in discrete values.
The rectangle above for example, would return a width of 63 and height of 63.

So, what do you get when you ask for the size of a texture?

Code: Select all

ITexture * fireballTexture = driver->getTexture("../media/fireball.bmp");
irr::core::dimension2di textureSize(fireballTexture->getSize());

Does it give you the width and height of the rectangle?
Or does it return the number of pixels across and down? Which would be width+1 and height+1 (if you were thinking like a rectangle).

This problem has messed up my calculations slightly until now.
I would like to fix it once and for all.

*EDIT*
Sorry for asking. It was easy to find out!

The size of a texture is the number of pixels.

So, now I can see it has messed up my calculations.
When I make a rect to represent the boundary of the texture, the rect size is the number of pixels minus 1, since the end points are considered as pixels.

Does anyone understand what I mean?

[Ulf]

This one thing is still annoying me.
Can anyone tell me the answer? I'll use an example.

If I have a texture that is 64*64 pixels, should the sourceRect = (0,0,64,64), or should it be (0,0,63,63).

I "think" I can see that it should be (0,0,64,64).
This didn't make sense to me before because I can't understand why you need the bounding rectangle to actually be larger by 1 pixel than it really is! Because 0-63 is actually 64 pixels...

If the answer is (0,0,64,64), then is it the last value (64) that does not have a pixel? i.e. the pixels are taken from 0-63, leaving 64 out?

This is driving me nuts.

It's a small problem but it is important.

**EDIT**
Now I'm certain again!! hehe.

The texture frame must be (0,0,64,64)

If I have 2 frames next to each other in one texture, both 64*64 for example, then should the 2 frames be (0,0,64,64) & (64,0,128,64)?

The frames overlap don't they? The first pixel on the 2nd frame should equal the last coordinate of the first frame? (since that one has no pixel)?

Am I understanding that correctly?

I don't have to leave gaps in the texture, do I? Damn, I feel like a looney.

**EDIT**
I assume the destRect works the same way as the sourceRect..?

[Lonesome Ducky]

I'm pretty sure it should be 0,0,64,64. Think about this:

Code: Select all

for (int x = 0; x < 64; x++)

It would go from 0-63

[Ulf]

I'm pretty sure it should be 0,0,64,64. Think about this:
Code:
for (int x = 0; x < 64; x++)

Thanks for the reply.

Yea, I understand. So is that why the extra coordinate?
So the person writing the loop can say x<64 instead of x<=63 ?


hehe.. just joking.. but ok. I just wanted confirmation from someone.

Thanks.

So I can assume the destRect is the same way...

Jesus Christ! I been doing it wrong the whole time.. No wonder I had so many weird problems with my rotation..

[CuteAlien]

Check the last post on this page (the one from bitplane). I think it explains the width/pixel issues: http://irrlicht.sourceforge.net/phpBB2/ ... light=rect

The trick is to realize when you talk about units and when it is about pixels. You're not the first to get irritated by this, but it actually makes some sense once you get used to it.

[Ulf]

Yea that helped. But then I read your comment after BitPlane and I am getting really confused again.

I have to do 2 isPointInside tests for each point? What....? Aaaaarrrrgggghhhhh..

hmmmm...

I just snapped a synapse...

I'll look into it more then I suppose...

[CuteAlien]

Just concentrate on Bitplanes drawing and forget about my comments back then. I was also fairly inexperienced with the engine back then and probably at least as confused as you are now :-)