Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 02 Nov 2009
Offline Last Active May 24 2015 01:49 AM

#5171905 Creating readable mipmaps in D3D11

Posted by on 06 August 2014 - 10:32 AM

Hello MJP


Indeed i forgot about that, but in this case it was not the source of the problem. Even with the correct row pitch it still showed up wrong. Turns out that squish converted the first layer correctly to S3TC but then it did wrong conversions. Switched to libtxc_dxtn and got it all working now!




#5167187 Mipmaps not used with multiplied texture coordinates

Posted by on 16 July 2014 - 11:42 AM

Hello all


Turns out i made a little boo boo in my engine. For constant buffers i was adressing registers b0-n but in the shader i have assigned them to register c0-n. So thats why it didnt take the 1/1/1/1 from the buffer even if it was present :)




#5143091 Windows Text Cursor Hotspot offset

Posted by on 29 March 2014 - 12:08 PM

Hello Buckeye


For me as a normal user i would suspect that the hotspot of the cursor is exactly where the vertical bar of the text cursor is. Everything else does not make any sense to me as thats the location you are clicking. Yet however if you take the 8 pixel offset you get from the icon info for the x-hotspot and go to that position in the cursors bitmap you land 2 pixels left of the vertical bar. That means on windows 7 if you want to get the effective location the user intended to click youd have to add 2 pixel to the value you get in WM_MOUSEMOVE or similar messages. If you dont do so youll drive the user nuts as he would have to click 2 pixels more left than he wants to click.


The use case i had problem implementing was:
The user clicks into the textbox and the caret of the textbox should move to the closest letter at the click position. Due to this 2 pixel offset to the left visually you had to click into the next letter to get the caret to the one you actually wanted.


So, yes, i say its not where i want it and i stay by my opinion: Its just plain wrong how it is right now.




#5080762 Data clipped before Output Merger

Posted by on 26 July 2013 - 10:00 AM

Hello everyone


Thanks for your answers, im not using PIX as it doesnt work on windows 8 with d3d11 (im not using 11.1) (known bug). Sadly NVIDIA NSight doesnt come for VS13 yet (i think they sent a newsletter that its for VS12 now, but not sure).


About the actual problem:
Seems the graphics debugger in visual studio is not really showing the real data, it much rather reads my mind and displays what id actually like to see :D. The matrices were not transposed and thus obviously the results were not right. Nevertheless the graphics debugger showed the resulting triangle exactly as it would look in projection space, weird...

However, now everything works, thanks a lot for all your hints and replies!




#5016669 Running application with PIX -> shutdown

Posted by on 02 January 2013 - 06:47 AM

Hello everyone

Im currently encountering some issues with PIX. If i run my application without PIX it starts without any problems but if i run it with PIX it runs a little while und before the window shows the process already exits. If i use a replayable thats what i get:

So i can see that the last call was IDXGISwapChain::GetBuffer after that theres an error. So i went to my code which looks like that:

void GxDevice::initBuffers()
	ID3D11Texture2D* targetBuffer = nullptr;
	mSwapChain->GetBuffer(0, __uuidof(ID3D11Texture2D), (LPVOID*)&targetBuffer);

	D3D11_RENDER_TARGET_VIEW_DESC rtvDesc;	memset(&rtvDesc, 0, sizeof(rtvDesc));
	rtvDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;
	rtvDesc.ViewDimension = D3D11_RTV_DIMENSION_TEXTURE2D;
	rtvDesc.Texture2D.MipSlice = 0;

	res = mDevice->CreateRenderTargetView(targetBuffer, &rtvDesc, &mRenderView);


So first i added a messagebox before CreateRenderTargetView and it gets hit by PIX. If i move it after CreateRenderTargetView it doesnt get hit.

Then i remembered that i have a little feature in my application that if the binary is built in debug mode and no debugger is attached it attaches a fork of itself to the process as debugger and prints all important debug events to a file. So i turned on that feature and started it again with PIX. What i get now is the following output:

With the obviously interesting line:
D3D11 CORRUPTION: ID3D11Device::CreateRenderTargetView: First parameter is corrupt! [ MISCELLANEOUS CORRUPTION #13: CORRUPTED_PARAMETER1]

So that means targetBuffer seems to be corrupt when using PIX (i dont get that message in the output if i run the application without PIX).

Anyone got an idea why this could happen?

Any help is appreciated,


Ive just seen that this is a known issue with PIX on windows 8... darn it, thats annoying, windows 8 is in such an unfinished state....

#5015904 assembly on gpu instruction question

Posted by on 30 December 2012 - 06:17 PM

Hello noatom


It performs a scaling:





#4997141 Unprojecting screen coordinates invalid result

Posted by on 04 November 2012 - 05:22 AM

Sure, i made some screenshots from my tablet. Im sorry the font seems to be screwed up a bit, i hope its still readable, as i directly wrote into the screenshots! The big arrow always points to the location where my finger pressed. All the results come from the version with gluUnProject.

Posted Image
Posted Image
Posted Image
Posted Image
Posted Image

#4997042 Unprojecting screen coordinates invalid result

Posted by on 03 November 2012 - 07:04 PM

Hello everyone

On my tablet i render my scene to a depth buffer and read a pixel from it to determine my current position.

- I visualized the depth buffer -> all is fine, vertex shader:
[source lang="cpp"]varying float camDistance;void main() { vec4 tmpPos = vec4(vPosition0.xyz, 1.0); vec4 posCamSpace = matProj * matView * tmpPos; camDistance = (posCamSpace.z - 0.1) / (800.0 - 0.1); gl_Position = posCamSpace;}[/source]

i hardcoded the values just to be sure!

- I visualized the depth read from the buffer -> It is correct for the nearest points and for the points far away, thats the code i use:
[source lang="java"] ibuff.position(0); GLES20.glReadPixels((int)touchPos.x, (int)touchPos.y, 1, 1, GLES20.GL_RGBA, GLES20.GL_UNSIGNED_BYTE, ibuff); ibuff.position(0); int color = ibuff.getInt() & 0x000000FF; float depth = color / 256.0f;[/source]

- When i check my coordinates i see that it uses nearly the position of the camera for all 3 components and when i move my finger shifts the coorect coordinates but like 0.001 per pixel like so it seems that it unprojects the point no matter what depth i enter to the near plane.

- If I use depth 1 every time unprojection is done nicely and works like a charm if i move my finger, all coordinates are correct and change correct.

I used gluUnProject to unproject my values as well as my own implementation. With gluUnProject:
[source lang="java"] GLU.gluUnProject(touchPos.x, touchPos.y, depth, getActiveCamera().getMatView().getFloats(), 0, PerspectiveMatrix.getFloats(), 0, viewport, 0, coords, 0);[/source]

touchPos.y of course is transformed with the viewport (touchPos.y = viewport[3] - touchPos.y).

Thats my own implementation:
[source lang="java"] public static Vector3 unproject(Vector3 v, Matrix invView, Matrix invProj, int[] viewport) { Matrix matCombo = Matrix.multiply(invView, invProj); float vx = viewport[0]; float vy = viewport[1]; float vw = viewport[2]; float vh = viewport[3]; float[] rhsVec = { ((2 * (v.x - vx)) / vw) - 1, ((2 * (v.y - vy)) / vh) - 1, 2 * v.z - 1, 1 }; float[] result = new float[4]; android.opengl.Matrix.multiplyMV(result, 0, matCombo.getFloats(), 0, rhsVec, 0); float d = 1 / result[3]; return new Vector3(result[0] * d, result[1] * d, result[2] * d); }[/source]

What did i forget? I used gluUnProject on my Desktop with glReadPixels (but GL_DEPTH_COMPONENT which is not available on OpenGL ES) and it worked there!

Thank you for any help

#4996858 Textures are grainy and pixels move when moving the camera

Posted by on 03 November 2012 - 08:25 AM

Hey Corvwyn

What filters are you using for sampling? Min/Mip and Mag?

Seems like the textures are rendered on a high resolution with small pixel coverage resulting in changes on small movement.