# Generating a checkered pattern via dynamic textures in D3D9

This topic is 1433 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I haven't been on here in awhile, anyways, I need some assistance with creating a checkered pattern texture to use as a default texture when textures can't be loaded from disk. I am using this code:

D3DLOCKED_RECT lockRect;

for (unsigned int i = 1; i <= d3dText->Width / 64; ++i)
{
for (unsigned int j = 1; j <= d3dText->Height / 64; ++j)
{
BYTE* data = (BYTE*)lockRect.pBits;
int index = i * lockRect.Pitch / 4 + j;

if ((i + j % 2) == 1)
{
data[index++] = 255;
data[index++] = 0;
data[index++] = 0;
data[index++] = 255;
}
else
{
data[index++] = 255;
data[index++] = 255;
data[index++] = 255;
data[index++] = 255;
}
}
}
d3dText->UnlockRect(0);


the texture is dynamic and everything but when I try to save it for debugging purposes, the texture's just......white. Nothing wrong with that but I need a checkered pattern to use as a default texture.

##### Share on other sites

Just a guess at your algorithm , but, instead of (i + j % 2), try ((i + j) % 2) ??

As you have it posted, (i + j%2) will == 1 only when i==1 and j is a multiple of 2. The precedence of the mod operator (%) is higher than the addition operator. (i + j % 2) means: calculate j%2 and add the value of i.

Edited by Buckeye

##### Share on other sites

Well, that didn't work......dang it. guess I'll wait a bit more for a good answer.

##### Share on other sites

Both your for loops should start at zero, and be 'less than' width/height, not 'less than or equal too'. Your pre-increments (++i) should both be post-increments (i++).

What size is your texture, and how many 'checks' do you want on it.

Edited by mark ds

##### Share on other sites

Sorry to double post but I figured it out....

I just needed to do this:

	D3DLOCKED_RECT lockRect;

BYTE* data = (BYTE*)lockRect.pBits;
for (unsigned int i = 0; i < d3dText->Width ; ++i)
{
for (unsigned int j = 0; j < d3dText->Height  ; ++j)
{

int index = i * lockRect.Pitch / 4 + j;

if ((i / 32 + j / 32 ) % 2 == 0)
{
*data++ = 255;
*data++ = 0;
*data++ = 0;
*data++ = 255;
}
else
{
*data++ = 255;
*data++ = 255;
*data++ = 255;
*data++ = 255;
}
}
}
d3dText->UnlockRect(0);


move the BYTE* data variable out of the for-loops..... stupid me.

##### Share on other sites

Your pre-increments (++i) should both be post-increments (i++).

I am really curious. Why?? As that's the loop increment, how can it possibly matter (except pre-increment may be slightly faster)?

##### Share on other sites

Because 'i' is used within the loop, not just outide of it. Therefore pre/post incrementing matters. In the example given above,  'index' is based on 'i'., meaning 'i' is totally dependent of when it is incremented!

##### Share on other sites
Wat.

Whether you chose to post-increment or to pre-increment has nothing to do with how i is used. Variables declared in the init-expression, are scoped to the loop's body -- no expression can magically change their scope. Perhaps you are confusing sequence points with the old VC6 bug that allowed you to do the following?
for ( int idx = 0; idx < 5; idx+=1 )
;

for ( idx = 0; idx < 5; idx+=1 ) // Bad, VC6! Bad!!
;


##### Share on other sites

Because 'i' is used within the loop, not just outide of it. Therefore pre/post incrementing matters. In the example given above,  'index' is based on 'i'., meaning 'i' is totally dependent of when it is incremented!

That's incorrect. First, i isn't defined outside the loop.

Consider the following:

int i=1;
++i;
// At this point in the code, i==2
int j = 1;
j++;
// At this point in the code, j==2


For standalone statements (such as the two above and a loop increment statement), ++i; and i++; both result in the value of i being one greater than prior to those statements.

Edited by Buckeye

##### Share on other sites

I agree pre- or post- increment doesn't matter in regards to the output here.

I've always defaulted to using pre-increment in for C++ loops as I understand a temp variable is needed for a post-increment operator "under the hood", though I'd imagine any optimizing compiler worth it's salt should be able to produce just as efficient assembly either way.

1. 1
2. 2
3. 3
Rutin
16
4. 4
JoeJ
13
5. 5

• 9
• 9
• 14
• 10
• 25
• ### Forum Statistics

• Total Topics
632646
• Total Posts
3007635
• ### Who's Online (See full list)

There are no registered users currently online

×