Sign in to follow this  
Commodore.64

D3D10: Non 32-Pixel-Wide Textures Corrupted

Recommended Posts

Commodore.64    100
[b]Quick Summary:[/b]
In my D3D10 application, only textures that have widths that are multiples of 32 (ex: 640 pixels wide, 480 pixels wide, 544 pixels wide, etc) are displayed correctly. All other textures are corrupted.

[b]Details:[/b]
This has been driving me nuts for weeks. I've written my own real-time video and image processing framework that sits atop D3D10 (yay pixel shaders). Everything was working great... until I tried processing some video that wasn't 720p or 1080p. After a bunch of debugging, I was able to rule out bad data sources and isolated the problem to my actual D3D rendering code. And after even more debugging, I was able to isolate the problem further: my textures only work right if they're multiples of 32 pixels wide. Otherwise, the scanlines are getting corrupted.

I ended up stripping the application down to the bare minimum - all it does is show a textured quad. And yet, the problem [i]still[/i] persists. I've spent weeks on this, and other then creating a stripped-down minimal application that reproduces the problem, I've made no progress.

Any suggestions on what I'm doing wrong?


[i]example of an correctly rendered texture (320 pixels wide)[color="#ffffff"]___[/color][/i][i][color="#ffffff"]___[/color][/i][i][color="#ffffff"]___[/color][/i][i]example of a corrupted texture (324 pixels wide)[/i]
[img]http://cl.ly/2y3q1W422f1g3h421E3T/moz-screenshot-2.png[/img][i][color="#ffffff"]___[/color][/i][img]http://cl.ly/082Q0N3m2O37310a0Y0U/moz-screenshot-1.png[/img]

Share this post


Link to post
Share on other sites
Erik Rufelt    5901
Textures can have padding, to make each row the same number of bytes. This can require you to write one row at a time, if your source data doesn't have the same padding.
Something like this instead of the memcpy you use now:
[source]
char *dst = (char*)mappedTexture.pData;
for(UINT i=0;i<height;++i)
memcpy(dst + i*mappedTexture.RowPitch, pBitmap+i*width*sizeof(UINT), width * sizeof(UINT));
[/source]

Share this post


Link to post
Share on other sites
Commodore.64    100
[quote name='Erik Rufelt' timestamp='1307282278' post='4819744']
Textures can have padding, to make each row the same number of bytes. This can require you to write one row at a time, if your source data doesn't have the same padding.
Something like this instead of the memcpy you use now:
[source]
char *dst = (char*)mappedTexture.pData;
for(UINT i=0;i<height;++i)
memcpy(dst + i*mappedTexture.RowPitch, pBitmap+i*width*sizeof(UINT), width * sizeof(UINT));
[/source]
[/quote]
Well, I feel like a right idiot. That cleared things right up! I don't know how I didn't pay attention to row pitch. Or how that didn't just jump screaming out at me given the scanline-level corruption. :/

A bit disappointing, though - looks like I'm going to have to do more bit twiddling throughout my application to compensate for the pitch. And for realtime HD video manipulation, that sort of bit twiddling can get expensive CPU side...

But I digress. Thank you [i][b]soooo[/b][/i] much Erik!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this