Sorry your browser is not supported!

Hopefully I can explain this well enough to be understood. :-(

I have an image of a capsule that I intend to use in a breakout type game. I've laid out an image that forms a grid whose cells are the same size as the capsule image. When I apply a sprite to the image and place it in the upper left corner of a cell it fits fine. But in order to keep down the number of sprites I need to maintain, I wrote a routine to copy the capsule image directly to the grid image. Though the size of the copy area appears to be equal to the size of the image, the image itself comes out slightly larger than the image area, if that makes any sense. The resulting image, as displayed on the screen, is too large to fit in the same rectangle that's equivalent to the image's width and height.

The code I'm using is below, minus the rather cumbersome code necessary to derive the pointers, which I assure you are correct.



xpos/ypos are the left/top coordinates on the destination image to which the source image is to be copied. srcWidth, srcHeight prove to be correct in a debug session, and I have to assume the srcPitch32 is correct otherwise the image would be skewed.

In the attached picture the larger appearing image isn't being clipped by by the grid. I'm aligning the image on the top/left and copying the image exactly the width and height of the image itself. But seems that the image is larger than itself. Is that really clear????

So does anyone have a clue I can go by as to why this is happening?

*double post*
*mouse dying...pity*

I can\'t run your code, but your problem looks/sounds like you are loading the image as a texture, and not an image. (Which is the default.)

dbLoadImage is overloaded; if you pass an extra integer with the value 1, it will load as an image, and I think that is the difference you spoke of some time ago with respect to where the image is loaded...GPU memory vs. system memory. (More of a suspicion, really.)

Anyway, with a flag of 0, or no flag, it will create mipmaps, and the power of two size restriction comes into play. (With the effect of either clipping or of creating blank space in non-power of 2 situations.)

Now, hopefully that makes sense, and is somewhat correct.

That thought occurred to me but it was just as I was falling asleep. Now that I'm half awake I'll look into loading it with the proper options a little later.

Many thanks.

@jinzai

Just to let you know, that fixed the problem. Once again, my thanks.