• Create Account

## Full Screen Quad with Texture, looks off

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

7 replies to this topic

### #1VanillaSnake  Members

Posted 29 July 2014 - 03:00 AM

I'm trying to convert my software rasterizer from ddraw to dx10. I like to at some point use the pixel shader to draw some elements while I do other elements on cpu. So I decided to just create a texture, lock it and draw directly on it, then use a quad to display it. It does work, and all my programs that I wrote under ddraw run just fine, most old functions have this declaration function(DWORD* video_mem, int lpitch32) so all I do is replace the locked texture memory into vid ram, and the stride of the texture into lptich32. Easy enough. The problem comes in when I try to do something like a dotted line, for example if I try to plot a pixel every 5 pixels.

for (int x = 0, x1 = 0; x < 50;x++, x1+=5)

{

texture_buffer[x1 + y1*lpitch32] = COLOR_MAGENTA;

}

what I get is a line, but some pixels appear to be either merged with others or too far apart. I don't know what's causing it. To give you a run down of my setup, I create a texture the size of my back buffer, which is the same size as my screen. I create a quad with (-1,-1) to (1,1) coords, I leave it in clip-space and don't use any additional transforms in the vertex shader. My pixel shader just samples the texture. The sampler state filter is set to mip-min-mag or something like that. I thought it might be the filtering, but I didn't find an option how to specify no filter.

If needed ill post a picture of what I'm getting and just let me know which code you want me to show you.

Edited by VanillaSnake, 29 July 2014 - 03:01 AM.

You didn't come into this world. You came out of it, like a wave from the ocean. You are not a stranger here. -Alan Watts

Time flies like an arrow; fruit flies like a banana. - Old Wise Eastern tribesman saying

### #2mhagain  Members

Posted 29 July 2014 - 04:18 AM

I create a texture the size of my back buffer, which is the same size as my screen

It sounds like these are not actually the same size.  If you're using a windowed mode, you may have miscalculated by including the non-client area in the size, for example.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

### #3VanillaSnake  Members

Posted 30 July 2014 - 12:11 AM

Window creation, SCREEN_HEIGHT and WIDTH are defines in a common header file. As you can see I correct the window size after it's created to account for the border, so the client area of my window is exactly the dimensions that I specify

if (!(hwnd = CreateWindowEx(NULL, // extended style

TEXT(WINDOW_CLASS_NAME), // class

TEXT("DirectX 32-Bit Software Rasterizer v3"), // title

WS_OVERLAPPED | WS_VISIBLE,

0, 0, // initial x,y

SCREEN_WIDTH, SCREEN_HEIGHT, // initial width, height

NULL, // handle to parent

hinstance,// instance of this application

NULL))) // extra creation parms

{

softrest7_obj.mainWindow = 0;

return 0;

}

//the next function is RasterizerInit() which calls this

RECT requestedDimensions = { 0, 0, SCREEN_WIDTH, SCREEN_HEIGHT };
//misnamed function, it could actually resize the window in addition to moving it
MoveWindow(softObjPtr->mainWindow, 0, 0, requestedDimensions.right - requestedDimensions.left, requestedDimensions.bottom - requestedDimensions.top, FALSE);



During the same RasterizerInit() I create the swap chain and device with these settings

//setup swap chain ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

ZeroMemory(&softObjPtr->D3D10SwapChainDesc, sizeof(DXGI_SWAP_CHAIN_DESC));

//set buffer dimensions and format

softObjPtr->D3D10SwapChainDesc.BufferCount = 2;

softObjPtr->D3D10SwapChainDesc.BufferDesc.Width = SCREEN_WIDTH;

softObjPtr->D3D10SwapChainDesc.BufferDesc.Height = SCREEN_HEIGHT;

softObjPtr->D3D10SwapChainDesc.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT;

softObjPtr->D3D10SwapChainDesc.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;

Texture creation

D3D10_TEXTURE2D_DESC desc;

ZeroMemory(&desc, sizeof(desc));

desc.Width = SCREEN_HEIGHT;

desc.Height = SCREEN_HEIGHT;

desc.MipLevels = 1;

desc.ArraySize = 1;

desc.Format = softObjPtr->D3D10SwapChainDesc.BufferDesc.Format;

desc.SampleDesc.Count = 1;

desc.Usage = D3D10_USAGE_DYNAMIC;

desc.CPUAccessFlags = D3D10_CPU_ACCESS_WRITE;

HRESULT hr;

if (FAILED(hr = softObjPtr->pD3D10Device->CreateTexture2D(&desc, 0, &softObjPtr->texture)))

{

return;

}

Also just to show you the kinds of effects it produces in more detail:

this is the line produced by code in my previous post, each pixel is plotted every 5 screen pixels (click on image to see better)

this is the normal output when I draw a drop by drawing every pixel

same drop only now skip 2 pixels, supposed to be a neat grid, but turns into a jumble

this is weird, because if I skip 3 pixels then it draw it as expected, in a neat grid

Edited by VanillaSnake, 30 July 2014 - 12:16 AM.

You didn't come into this world. You came out of it, like a wave from the ocean. You are not a stranger here. -Alan Watts

Time flies like an arrow; fruit flies like a banana. - Old Wise Eastern tribesman saying

### #4VanillaSnake  Members

Posted 30 July 2014 - 08:32 PM

Shameless bump, anyone??

You didn't come into this world. You came out of it, like a wave from the ocean. You are not a stranger here. -Alan Watts

Time flies like an arrow; fruit flies like a banana. - Old Wise Eastern tribesman saying

### #5Buckeye  GDNet+

Posted 31 July 2014 - 08:07 AM

In post #3 above, your code is a bit confusing. It appears you create a window (hwnd, SCREEN_WIDTH x SCREEN+HEIGHT) which you may or may not use(??), set softrest7_obj.mainWindow to 0 on an error, change the size of another window (softObjPtr->mainWindow) based on an adjusted RECT, and create your backbuffer SCREEN_WIDTH x SCREEN_HEIGHT.

IF you're presenting the backbuffer to softObjPtr->mainWindow, though your approach is rather unconventional, it appears things should be correct dimensionally. You didn't post your code for rendering to the texture, nor for rendering the quad. That would help.

For clarity to yourself and others, you might consider creating the mainwindow directly with the desired size, then use the size of the client area (rather than constants) to size your backbuffer. That also allows changing the window size later, ensuring all dimensions are consistent and as expected.

I.e.,

RECT reqSize = { ... };
mainWindow = CreateWindowEx( ... reqSize.right, reqSize.bottom ... );
...
RECT clientRect;
GetClientRect( mainWindow, &clientRect );
...
BufferDesc.Width = clientRect.right;
BufferDesc.Height = clientRect.bottom;
...
// texture
desc.Width = BufferDesc.Width;
desc.Height = BufferDesc.Height;


Also, ensure your viewport is set to the proper rectangle.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

### #6VanillaSnake  Members

Posted 01 August 2014 - 01:18 AM

In post #3 above, your code is a bit confusing. It appears you create a window (hwnd, SCREEN_WIDTH x SCREEN+HEIGHT) which you may or may not use(??), set softrest7_obj.mainWindow to 0 on an error, change the size of another window (softObjPtr->mainWindow) based on an adjusted RECT, and create your backbuffer SCREEN_WIDTH x SCREEN_HEIGHT.

IF you're presenting the backbuffer to softObjPtr->mainWindow, though your approach is rather unconventional, it appears things should be correct dimensionally. You didn't post your code for rendering to the texture, nor for rendering the quad. That would help.

For clarity to yourself and others, you might consider creating the mainwindow directly with the desired size, then use the size of the client area (rather than constants) to size your backbuffer. That also allows changing the window size later, ensuring all dimensions are consistent and as expected.

I.e.,

RECT reqSize = { ... };
mainWindow = CreateWindowEx( ... reqSize.right, reqSize.bottom ... );
...
RECT clientRect;
GetClientRect( mainWindow, &clientRect );
...
BufferDesc.Width = clientRect.right;
BufferDesc.Height = clientRect.bottom;
...
// texture
desc.Width = BufferDesc.Width;
desc.Height = BufferDesc.Height;


Also, ensure your viewport is set to the proper rectangle.

Thanks for the reply, I was sure this will go unanswered as it's a strange problem. Ok to explain the softrest7_obj and softObjPtr. I'm not using classes for my software rasterizer but use mostly c like functions. So I have a struct that contains initialization variables for my rasterizer. Before I used DX7 and direct draw so my struct was softrest7_obj and contained stuff like back buffer, interfaces, surface descs etx. Now I have softrast10_obj that contains dx10 interfaces, effect files etc so i can interface with the renderer from my app. So I pass a pointer to


void InitializeSoftwareRasterizer(SOFTWARERASTERIZER_DX10_OBJECTS* softObjPtr)

{

and it fills in all the interafaces, also in WinMain i set the softrast10_obj->mainWindow = hwnd; later on so it is the same window

But that's why you see it named different things. In window creation I forgot to change softrest7 to softrast10 and set the wrong window to null but that's not a big issue.

Next is the texture rendering, I did post the code for that in my first post, that for loop is between texture->map / unmap calls.

D3D10_MAPPED_TEXTURE2D mappedTex;

UINT lpitch32 = mappedTex.RowPitch >> 2; //in bytes, div by 4 to get num dwords

DWORD* texture_buffer = (DWORD*)mappedTex.pData;

ZeroMemory(texture_buffer, SCREEN_HEIGHT*mappedTex.RowPitch);

// SnowGameMain(texture_buffer, lpitch32, Time.deltaTime);

// OceanMain(texture_buffer, lpitch32, Time.deltaTime);

Main(texture_buffer, lpitch32);

softrest10_obj.texture->Unmap(D3D10CalcSubresource(0, 0, 1));

//lock vertex buffer for CPU use

//right now inside InitializeSoftwareRasterizer10(SOFTWARERASTERIZER_DX10_OBJECTS* softObjPtr)

float planeXOrig =  -1.0f, planeYOrig = -1.0f;
float planeWidth = 2.0f;
float planeHeight = 2.0f;

v[0] = DX10VERTEX(D3DXVECTOR3(planeXOrig, planeYOrig, 0), D3DXVECTOR4(1, 0, 0, 1), D3DXVECTOR2(0.0f, 1.0f));

v[1] = DX10VERTEX(D3DXVECTOR3(planeXOrig + planeWidth, planeYOrig, 0), D3DXVECTOR4(0, 1, 0, 1), D3DXVECTOR2(1.0f, 1.0f));

v[2] = DX10VERTEX(D3DXVECTOR3(planeXOrig + planeWidth, planeYOrig + planeHeight, 0), D3DXVECTOR4(0, 0, 1, 1), D3DXVECTOR2(1.0f, 0.0f));

v[3] = DX10VERTEX(D3DXVECTOR3(planeXOrig, planeYOrig + planeHeight, 0), D3DXVECTOR4(1, 0.5f, 0.7f, 1), D3DXVECTOR2(0.0f, 0.0f));

softObjPtr->pD3D10VertexBuffer->Unmap();

//initialize the INDEX BUFFER ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
int* i = NULL;

i[0] = 0;
i[1] = 1;
i[2] = 2;
i[3] = 0;
i[4] = 2;
i[5] = 3;

softObjPtr->pD3D10IndexBuffer->Unmap();



This part I'm not 100% certain about as it's something new to me, I read that if you make your quad go from (-1, -1) to (1, 1) and don't apply any transforms to it, it stays in clip space and therefore spans the whole screen, which is what I need, as before I tried to orthographically project it which was a hassle to line it up.

Also this is my viewport

//set view port aka region of render target ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

softObjPtr->D3D10Viewport.Width = SCREEN_WIDTH;

softObjPtr->D3D10Viewport.Height = SCREEN_HEIGHT;

softObjPtr->D3D10Viewport.MinDepth = 0.0f;

softObjPtr->D3D10Viewport.MaxDepth = 1.0f;

softObjPtr->D3D10Viewport.TopLeftX = 0;

softObjPtr->D3D10Viewport.TopLeftY = 0;

softObjPtr->pD3D10Device->RSSetViewports(1, &softObjPtr->D3D10Viewport);

I understand what you mean about the window resizing, but I like the global defines of screen dimensions. Since my window code has been untouched for a new months it's not really a problem but I do use SCREEN_WIDTH/HEIGHT often so carrying around the clientRect to multiple files will be cumbersome.

As far as I can see this stuff I posted won't really help you pinpoint the fault as it's mostly spot on, I've double and tripple checked everything, so I've resorted to doing low level trial and error things to determine the issue, this is what I have come up with: I wanted to see what would happen if used my old software blitter function to print a bitmap unto the texture. This function worked flawlessly in DirectDraw, but now it stumbles, the bitmap is skewed and the color is moved to one side. So I dove even deeper and just performed this basic test on the texture:

for(int y = offsetY, dy = 0; y < offsetY + image_height - 1; y++, dy++)
{
for(int x = offsetX*3, dx = 0; x < offsetX*3 + image_width*3; x+=3, dx++)
{
short red = source[x + y*source_width*3];
short green = source[x + y*source_width*3 + 1];
short blue = source[x + y*source_width*3 + 2];
short a = 255;
DWORD pixel = _RGBA32BIT(red, green, blue, a);

dest[(destPosX + dx) + (destPosY + dy)*destLPitch32] = pixel;
}



so to break it down, my bitmap is 24 bits, my texture is 32 bits, so I use UCHAR* to traverse the bitmap data and therefore have to manually increment each pixel moved by 3 bytes, during which I read in 3 bytes. I extract each r/g/b byte into a short and then recombine it using my macro

_RGBA32BIT ( (r & 255) + ((g & 255) << 8) + ((b & 255) << 16)  + ((a & 255) << 24) )

Since the <<dest>> is a DWORD ptr I traverse it ragular pixel indexes and it's own pitch.

The problem is that my square bitmap gets stretched horizontally when I do this. In order to fix that I restructured everything so I cast the texture into a UCHAR* as well and instead used this code to traverse it, this is same as above only more intuitive as now everything is a UCHAR

//establish starting points in memory

UCHAR* sourceStartMem = source + ( ( (offsetX + reg_offsetX) * 3) + ( (offsetY + reg_offsetY)*source_width * 3) );

UCHAR* destStartMem = (UCHAR*)(dest) + (x1 + y1*(destLPitch32 << 2));

int numColumns = (x2 - x1) + 1;

int numRows = (y2 - y1) + 1;

for (int row = 0; row < numRows; row++)

{

for (int column = 0; column < numColumns; column++)

{

UCHAR pixel[3];

pixel[0] = sourceStartMem[column * 3];

pixel[1] = sourceStartMem[column * 3 + 1];

pixel[2] = sourceStartMem[column * 3 + 2];

//NOTE - multiplying column by 3 works, texture becomes square, but it SHOULD BE 4, since the texture is 32bit!!!, making it 4 makes the //texture elongated horizonally

destStartMem[column * 3] =  pixel[0];

destStartMem[column * 3 + 1] = pixel[1];

destStartMem[column * 3 + 2] = pixel[2];

destStartMem[column * 3  + 3] = 255;

}

destStartMem += destLPitch32 << 2; // multiply by 4 to get the 32bit lpitch back into bytes

sourceStartMem += source_width * 3;
}

You can ignore the starting memory and offsets, as this fragment is a part of a bigger function where I have to clip the bitmap the import fragment is the for loop. I copy each byte to the appropriate byte on the destination texture and I fill in the 4th byte as 255 for the alpha. The interesting thing is that this works well, the texture is now square, albeit still misscolored. But read the little not i wrote in code, if I multiply the column by 4 which is the correct way since the texture is 4 bytes per pixel the result is the same as the previous code, the texture gets stretched!!! I don't understand why that is happening but I think it's related to the stripes and the mispositioned dots that I was referring to in the original post. So I think this is the problem with the way I lay the pixels into memory, the only thing is why doesn't it just carry over smoothly from DirectDraw, the surface format I used there was 32bit RGBX, this texture is 32bit RGBA so I thought I just have to fill in the last byte to get it to covert, but something else must be at play as well. Here are some pics, first is the stretched bitmap when I use DWORD ptr to address the texture, next is the correctly square bitmap when I use UCHAR ptr to address the texture, and the little blue circle is what the bitmap is supposed to look like had it been drawn correctly:

#### Attached Thumbnails

Edited by VanillaSnake, 01 August 2014 - 01:47 AM.

You didn't come into this world. You came out of it, like a wave from the ocean. You are not a stranger here. -Alan Watts

Time flies like an arrow; fruit flies like a banana. - Old Wise Eastern tribesman saying

### #7Buckeye  GDNet+

Posted 01 August 2014 - 09:59 AM

You have a lot of moving parts, and you're probably trying to debug several problems at one time. Just FYI, I'll look at a piece or two of your posted code, but testing and debugging interactions between bunches of custom code... no. You'll have to do the legwork to find the problem(s).

Best to take one thing at a time, and make sure it's correct - don't assume it's correct unless you check that actual values are what you expect. I.e., follow the data step-by-step until you find something inconsistent with your expectations. Breakpoints and actual values are your friend.

Suggestions:

1. Create your window. The client area will be used for Present and the backbuffer will be stretched/shrunk to the client size. If you want to eliminate those Present changes, create your backbuffer from the window client size and check at least once (by actual value) that you've done what you think you've done. If you want to create a texture the size of the backbuffer, use the backbuffer width and height to do so. Check that.

I.e., have you compared backbuffer size (obtained from the backbuffer by actual value) to all the size settings that assume consistent sizes? In general, it's best to use the actual parameters for objects. E.g., use the (actual) backbuffer width/height for anything you assume will be the same size.

2. Your quad is comprised of 2 triangles, both with counter-clockwise winding order. If you're using default cull mode settings, they should be rendered clockwise. Do you have culling turned off? Is backface culling set to clockwise? For clarity, that needs to be straightened out.

3. A potentially useless exercise: you use a variety of Windows specific data types - UINT, DWORD, UCHAR, etc. - which are all typedefs, several of which you use for the same purpose and assume are the same size or in a specific ratio of sizes. Not knowing what headers you may be using, just for fun, you might want to check for consistency using sizeof(...) to confirm your assumptions.

To avoid chasing (possible) multiple problems, as mentioned, debug one thing at a time. E.g., you should consider using a known texture to test that your quad rendering is okay. Only then, add in further unknowns like pixel-by-pixel drawing, bitmap generation, etc.

EDIT: You appear to be doing error-checking in general, which is good. As posted, though, it's "On Error just return now." Assuming a particular function or routine returns in any case, how do you determine and announce that there's an error?

EDIT2: Consider using point (vs linear) sampling for testing purposes.

Edited by Buckeye, 01 August 2014 - 10:08 AM.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

### #8VanillaSnake  Members

Posted 03 August 2014 - 11:18 PM

Thank you so much Buckeye, I took your suggestion and changed the SCREEN_WIDTH and HEIGHT to client rect and it worked beautifully. And thanks mhagain, as he suggested it right away. I guess somehow the sizes did end up being different. Just for clarity if anyone else is having this issue this is my final code:

//INSIDE WinMain

RECT requestClientSize;
requestClientSize.left = 0;
requestClientSize.top = 0;
requestClientSize.right = SCREEN_WIDTH - 1;
requestClientSize.bottom = SCREEN_HEIGHT - 1;

if (!RegisterClassEx(&winclass))
return(0);

// create the window
if (!(hwnd = CreateWindowEx(NULL,                  // extended style
TEXT(WINDOW_CLASS_NAME),     // class
TEXT("DirectX 32-Bit Software Rasterizer v1"), // title
WS_TILED | WS_VISIBLE,
0, 0,<span> </span>  // initial x,y
requestClientSize.right, requestClientSize.bottom,  // initial width, height
NULL,<span> </span>  // handle to parent
NULL,<span> </span>  // handle to menu
hinstance,// instance of this application
NULL)))<span> </span>// extra creation parms
{
softrest10_obj.mainWindow = 0;
return 0;
}

// save main window handle
softrest7_obj.mainWindow = hwnd;
softrest10_obj.mainWindow = hwnd;

GetClientRect(hwnd, &softrest10_obj.clientRect);

//inside RasterizerInit

//setup swap chain ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
ZeroMemory(&softObjPtr->D3D10SwapChainDesc, sizeof(DXGI_SWAP_CHAIN_DESC));

//set buffer dimensions and format
softObjPtr->D3D10SwapChainDesc.BufferCount = 2;
softObjPtr->D3D10SwapChainDesc.BufferDesc.Width = softObjPtr->clientRect.right;
softObjPtr->D3D10SwapChainDesc.BufferDesc.Height = softObjPtr->clientRect.bottom;
softObjPtr->D3D10SwapChainDesc.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT;
softObjPtr->D3D10SwapChainDesc.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;

/......

//set view port aka region of render target ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
softObjPtr->D3D10Viewport.Width = softObjPtr->D3D10SwapChainDesc.BufferDesc.Width;
softObjPtr->D3D10Viewport.Height = softObjPtr->D3D10SwapChainDesc.BufferDesc.Height;
softObjPtr->D3D10Viewport.MinDepth = 0.0f;
softObjPtr->D3D10Viewport.MaxDepth = 1.0f;
softObjPtr->D3D10Viewport.TopLeftX = 0;
softObjPtr->D3D10Viewport.TopLeftY = 0;

//........

//create our texture (or load it) ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
D3D10_TEXTURE2D_DESC desc;
ZeroMemory(&desc, sizeof(desc));
desc.Width = softObjPtr->D3D10SwapChainDesc.BufferDesc.Width;
desc.Height = softObjPtr->D3D10SwapChainDesc.BufferDesc.Height;
desc.MipLevels = 1;
desc.ArraySize = 1;
desc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;//softObjPtr->D3D10SwapChainDesc.BufferDesc.Format;
desc.SampleDesc.Count = 1;
desc.Usage = D3D10_USAGE_DYNAMIC;
desc.CPUAccessFlags = D3D10_CPU_ACCESS_WRITE;



Now it's running as it should be! Can't describe how happy I am Thanks again

#### Attached Thumbnails

You didn't come into this world. You came out of it, like a wave from the ocean. You are not a stranger here. -Alan Watts

Time flies like an arrow; fruit flies like a banana. - Old Wise Eastern tribesman saying

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.