Hey there!

I have been writing a game with a friend of mine since a few days.
While I was implementing the graphics part of it, a problem has occured to me I have never experienced.

I am issuing a drawcall in directx and everything is set up:
 - Vertex Buffer
 - Input Layout
 - Primitive Layout
 - Vertex Shader and its constant buffer(which contains the render target size / 2)
 - Pixel Shader with a sampler state and a srv of a white texture
 - Rasterizer State & Blend State 
 - Viewport
 - Not to mention, a rtv is bound to the output merger too

Directx11's debug messages doesn't show anything wrong. The graphics debugger doesn't describe the draw call at all, it doesn't even fetch the input vertices/geometry (while it exists in the vertex buffer) and the pixel shader stage was not run. Upon debugging the shaders, the vertices are run through the vertex shader like it is supposed to and produces the expected results.

Code for the creation of rasterizer state, sampler state & blend state: https://pastebin.com/aeFWWkPu
Code of the vertex shader: https://pastebin.com/9z9e81Sp
Code of the pixel shader: https://pastebin.com/jMvWihV8
Here is the event timeline of the instance: https://pastebin.com/xetJbzNp
Here is a picture of the pipeline where the draw call is processed through: https://i.imgur.com/czxQEHH.png
Here are the vertices: https://i.imgur.com/C5z3oIT.png

Does anybody know what the cause of the problem is or has experienced a similiar problem?
Thanks!

Easiest way to figure it out would be to take a capture with RenderDoc, upload it and share that.

RenderDoc doesn't work for me. It only captures one draw call, as I already tried debugging it.
It says it can't figure out when a frame starts and when a frame ends within the application, so it just records 1 ClearRenderTargetView call.
I also can't use its In-Application API, as it did not compile in x64 for what ever reason.

I can share a visual studio integrated graphics debugger session, as that does work: DOWNLOAD

Sorry!

When calling IASetVertexBuffers, you set the stride of your vertex to be 0 bytes. That means every vertex rendered will advance 0 bytes through the vertex buffer and therefore have identical position/colour/UV as every other vertex.

You were right. Laughable how I did that mistake. The visual studio graphics debugger now shows the geometry, altough it still is not running through the pixel shader stage. DOWNLOAD

Thanks alot!!!

2 hours ago, L3mur said:

I also can't use its In-Application API, as it did not compile in x64 for what ever reason.

That sounds strange. Are you getting a compile error from the header file?

Also keep in mind that the way the API works is you have to manually load renderdoc.dll with LoadLibrary, and then get a pointer to the exported RENDERDOC_GetAPI function using GetProcAddress. From there you can get the other functions. I've seen some people make the mistake of trying to link to that function, which doesn't work since there's no import lib (which wouldn't be helpful anyway, since renderdoc.dll is only injected into your exe when run from RenderDoc).

1 hour ago, L3mur said:

You were right. Laughable how I did that mistake. The visual studio graphics debugger now shows the geometry, altough it still is not running through the pixel shader stage. DOWNLOAD

Thanks alot!!!

Problem #1:

Your Vertex Shader calculates the y-coordinate for the two vertices as:

1) 1 + (0 / 300) = 1.0f (the top of the screen)
2) 1 + (200 / 300) = 1.666f (off the top of the screen)

The y-coordinate in clip space is -1 at the bottom and 1 at the top, you probably want "1 - (pos / halfSize.y)" instead.

Problem #2:

You clear your render target to magenta and your lines are magenta coloured.

Fix both problems and the line appears:

@Adam Miles
Thanks for pointing out the problems! I really would have not noticed those mistakes. ?

@MJP
I know that I have to dynamically bind the RenderDoc API. However, I was compiling the program in x64, and the RenderDoc Header file was only checking for the WIN32 Macro, which ofcourse wasn't existing within x64, so it didn't compile. Here is a screenshot: 

1 hour ago, L3mur said:

However, I was compiling the program in x64, and the RenderDoc Header file was only checking for the WIN32 Macro, which ofcourse wasn't existing within x64, so it didn't compile.

See https://github.com/baldurk/renderdoc/commit/4f872b8c8dea365fd92e4483e6f5ad9214bb6ca8.