In one of my games, I have a minimap. the question that has been buzzing around in my mind for a while is "Why wont this function work correctly?" I did some experimenting and I narrowed my selection down to a memset function. Here are the lines of code.

...



D3DLOCKED_RECT sRect;
	sightTexture->LockRect(0, &sRect, NULL, NULL);
	BYTE *bytes = (BYTE*)sRect.pBits;
	memset(bytes, 0, sRect.Pitch*sRect.Pitch);
	
	
	float intensity = 1.3f;
	D3DXVECTOR2 center = D3DXVECTOR2(32.0f, 32.0f);
	
	for(int y=0;y<64;y++)
		for(int x=0;x<64;x++)
		{						
			float d = D3DXVec2Length(&(center - D3DXVECTOR2((float)x, (float)y)));
			int value = (int)(((32.0f - d) / 32.0f) * 255.0f * intensity);
			if(value < 0)value = 0;
			if(value > 255)value = 255;
			bytes[x + y * sRect.Pitch] = value;
		}
	sightTexture->UnlockRect(0);
              
              
 ...

Where is the code going wrong? 

I found this technique on an old programming website I used to use...

Without the memset function, only 1/3 of my minimap gets rendered...

I don't see enough code here. How many bytes per pixel are you using?

Well for a start, you don't appear to be locking the rect (it is commented out), so sRect contains garbage. That and you are memsetting with the pitch * pitch, which sounds unlikely?

It still passes an exception if I uncomment the lock function...

3 minutes ago, rjhwinner03 said:

It still passes an exception if I uncomment the lock function...

Well, yes, that will probably be using pitch * pitch as the size of the surface, which is incorrect, so you are memsetting off the edge of the surface and causing an exception.

https://docs.microsoft.com/en-us/windows/desktop/direct3d9/d3dlocked-rect

Pitch is the size of an x line in bytes. The correct number of bytes to memset (if you need to do this) would presumably be the pitch * the height of the texture.

The code runs, but I still get the issue that I would get if I commented out the memset function... 

I'm not too up to speed on D3D at the moment, but:

- Are you sure the texture is lockable?

- Have you tried checking the return value of LockRect()?

- Have you fixed the previously mentioned 'pitch * pitch' issue? (That might be working circumstantially, depending on the texture size and format, but it doesn't seem conceptually correct.)

- Are you sure the texture format is single-channel 8-bit?

As for the minimap only being partially rendered, I don't know that there's enough information here to diagnose that. It looks though like the texture in question is some sort of circular visibility region, so I can imagine that if the code you posted is incorrect, it might result in something like the behavior you describe.

All of this stuff worked like a charm in Windows XP through Windows 8... I had no errors... Windows 10 is and has been a big obstacle for me in the past and the present...

It seems to me that the same questions remain open (texture lockable? LockRect() return value? pitch * pitch? texture format?).

Regarding the change in development environment, although the problem could be related to Windows 10, I wouldn't assume that it is. I'm not saying this is necessarily the case here, but sometimes changes in environment can reveal problems that simply went unnoticed previously due to accident or circumstance.

Anyway, if you haven't solved it yet, maybe it would help take it a question at a time. So:

Have you fixed the 'pitch * pitch' issue? If not, is there any particular reason you're computing the size of the data that way?

Attach the debugger and put a breakpoint at the line with the memset. What are the contents of sRect?