window size and client size are two different things. The difference is the frame border size. Frame buffer size is what you set it to be, hopefully the client dimensions. 

https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-getwindowrect

https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-getclientrect

apologies if that was trivial. I'd look also at the window space the mouse is pulling from and check for expected results. Usually when window size is chosen during creation, the actual client size given back is smaller depending on the window style and (os). You carry on not noticing the handful of pixel and just give your frame buffer the window size. All seems fine until we dial into something accurate.  Or is it the other way around...  I'd have to check.

Nice looking project.

6 hours ago, GoliathForge said:

You carry on not noticing the handful of pixel and just give your frame buffer the window size. All seems fine until we dial into something accurate.  Or is it the other way around...  I'd have to check.

you are right but the problem is ambiguous output in my case,which is depending on the type of processor program is running on.

i tried hard coding the cursor position and client dimensions and it still gives correct output for the nvidia gpu and deflected one on for intel(integrated) gpu.

now i will try to re-transform the generated 3d ray points in the world to the client space manually  and find the deflection but i don't know will it give me a hint about how to deal the deflection intel gpu?????????

This how i am generating projection matrix..

These are extensions used for drawing with openGL..

Here is my draw command..

This is all i have and i am doing as in name of renderer. I know it needs to be optimized but for now its doing.

As mentioned above i am not using any other extensions rather than those up there.

Sorry if i am doing some lame mistake. Which is giving me hard time and annoying all of you.?

I am using Windows 10.

i worked up my whole day in this issue and found that the mathematical calculation are same on both the graphics processing unit

as in the below image.

i hard corded the click in the top left corner and printed the output as shown in the below code snipet

but when i was doing the test i found that both the graphics processor drawing the exact scene with different ratio or with some offset as shown in the image below . (Of course with same camera position and target)

as everyone can see that the model on the top of the screen in right window is drawn inside the window while in the left window the model is out of the window and cut by it.

i don't know why it matters because i am doing rayCast  with bullet physics on my 3d world data and their is no inclusion of any type of rendering pipeline functionalities rather than getting the cursor pos but as i told before the cursor position comes out pretty much the same every time for both gpus  there is no defect. And the main thing the calculation for ray is also based on cpu processing as shown above. If anybody wants my shaders info then here it is basic.frag,basic.vert. 

( on the other hand i don't think its giving some clue since calculation of the ray points are same for both the gpus and so output ray points too, and the thing is if i got the ray points same then why does it matters that on which gpu i am running the program because the 3d world data is independent of gpu program (as i think)."The most annoying thing in debugging is ambiguous output? " )

This is pretty much all i got from todays research. Hope this data give some clue someone. 

did you check what variables(values) you were using when the projection matrix is first built. Did you try to use the window popup style during window creation to remove the possibility of  wrong window dimension input. (window/client rect) The y offset looks like the size of the title bar height.

edit: building projection question, is m_window_width and m_window_height set to the window size or the client window size?

I know you said ambiguous output already, so it's the last time I'll suggest a early math input error.

The window size ,same as I give in the glfwcreatewindow after I retrieve frame buffer size and set it in camera height And width. 

right, but glfw might be adjusting the client rectangle behind the scenes when it does your viewport setting callback. Maybe building projection from the larger window size. 

test: glfwWindowHint(GLFW_DECORATED, false); // no frame borders or title bar before window creation

this will take the guess work out of what I'm thinking, so we can eliminate window size possibilities.

ref: https://www.glfw.org/docs/3.0/window.html

16 minutes ago, GoliathForge said:

test: glfwWindowHint(GLFW_DECORATED, false); // no frame borders or title bar before window creation

really it worked thank you very much??, /*but what could have gone wrong because i don't want my window stuck to the corner is this client area messed up.*/ (i should have shown some dignity by not asking that question after you helped me this much, i will try it to do by digging more.)

once again thank you very much.

nothing wrong. glfw was just trying to be helpful and somewhere along the way you didn't listen or ask(glfw). Now that you know there are two rectangles to keep watch on, retrace window creation and render pipeline setup for when the error occurs.

The quick fix might be to call glfwGetFramebufferSize() just before you build your projection and use those returned values instead of your member held dimensions and get rid of the test flat decoration(window style?)