Marcel Overweel
2009-09-17 13:05:29 UTC
Hi all,
I was having problems with pixel-perfect collision detection...
(Oh no, not another pixel-perfect question! I hear you scream.)
.. and I solved it.
(you see, you didn't need to worry :))
But I don't understand why something is happening.
Using: .NET, C#
Microsoft.DirectX.Direct3D.Texture and
Microsoft.DirectX.Direct3D.Sprite
I have a windowed direct3d surface, 1024x768, 4 bytes per pixel
I load a texture from a smaller bmp which is 640x640 in size.
This bitmap contains blocks with sprite images.
I tried to do pixel checking against a background image using
LockRectangle and a double x/y loop, but somehow every sprite
got mangled. It seemed like no pixel was were it should be
except for the pixels on the first scanline.
The pixel tests on the background bitmap didn't have that problem.
Width=1024, 4 bytes per pixel, so each scanline was 4096 bytes.
Now it seems that the 640x640 bitmap is resized (not scaled) to
1024 by something. And because the background bitmap had the
exact same size as the device, at first, I didn't see that anything
could be wrong with the algorithm.
I guess this resized texture will take up more memory than is required.
Can this resizing 'feature' be turned off?
I've looked into the parameters of the sprite, texture and the
TextureLoader.LoadFromFile method, but I can't find anything to
change this behaviour.
And why is it happening in the first place?
regards,
Marcel
I was having problems with pixel-perfect collision detection...
(Oh no, not another pixel-perfect question! I hear you scream.)
.. and I solved it.
(you see, you didn't need to worry :))
But I don't understand why something is happening.
Using: .NET, C#
Microsoft.DirectX.Direct3D.Texture and
Microsoft.DirectX.Direct3D.Sprite
I have a windowed direct3d surface, 1024x768, 4 bytes per pixel
I load a texture from a smaller bmp which is 640x640 in size.
This bitmap contains blocks with sprite images.
I tried to do pixel checking against a background image using
LockRectangle and a double x/y loop, but somehow every sprite
got mangled. It seemed like no pixel was were it should be
except for the pixels on the first scanline.
The pixel tests on the background bitmap didn't have that problem.
Width=1024, 4 bytes per pixel, so each scanline was 4096 bytes.
Now it seems that the 640x640 bitmap is resized (not scaled) to
1024 by something. And because the background bitmap had the
exact same size as the device, at first, I didn't see that anything
could be wrong with the algorithm.
I guess this resized texture will take up more memory than is required.
Can this resizing 'feature' be turned off?
I've looked into the parameters of the sprite, texture and the
TextureLoader.LoadFromFile method, but I can't find anything to
change this behaviour.
And why is it happening in the first place?
regards,
Marcel