So I've been tinkering around again and got the Direct3D9 version to work (with extra tinkering) I think I understand somewhat how the z and RHW values work (when the RHW is required eg; when no projection matrix is used)

The z value of a vertice defines the value used within the Z-Buffer, where 1.0f is as close to the camera as possible and 0.0f is as far away as possible. The RHW is typically calculated as 1.0f / z_dist_from_origin (origin is the camera position which in my case always remains 0,0,0)

For some reason, the original D3D renderer defines a value _ZSCALE as -16.0f and then divides it by the vertices z value, then the RHW value is processed where _AZSCALE is equal to 1.0f / 16.0f and RHW is equal to z * _AZSCALE

Also, by default Direct3D's co-ordinate origin is at the top-left of the window and you simply pass the width of the window as a float to a vertex and the vertex will be placed on the right hand side of the window, where as in OpenGl the origin is in the center of the window space, and a value of 1.0f for the x axis will place the vertex on the right side of the window, a value of -1.0f will place it on the left side of the window. For y it's the same, 1.0f will put the y position on the top side of the window and -1.0f will put it on the bottom side.


I'll post some of the data I dumped during a test of mine. I have to work with this data that I have without manipulating it too much ( I can modify it if absolutely necessary but I'd prefer not to)



Left-hand float is the X, the middle float is the Y and the Right-hand float is the Z. These are the same values used for the old D3D and the new D3D9 code.


EDIT:
I think I might be able to solve the origin problem with glFrustum... this will take some testing but the way i'm thinking of it is something along the lines of:


This should set the upper left corner as the origin (or the lower left corner, either one) and then the D3D data should work so long as z and w aren't treated differently from D3D's z and RHW. (again, seems not to be a difference between them other than OpenGl drops the 'rh' prefix.)


[Edited by - RexHunter99 on March 12, 2010 11:56:47 PM]

Ah! never mind folks... I got it working after I put glLoadIdentity() right after I cleared the Buffers, seems to work 100% the same as the D3D9 version so long as I leave the RHW value in OpenGL as 1.0f o-0

Not really solved the question at hand, but my problem is over for now so I guess this means this is solved somewhat.

Thanks to all who replied.

Sorry I didn't reply sooner. In the D3D world, the RHW (reciprocal homogenous W) is another way of saying, bypass the projection and modelview transform.

In the GL world, there is no such thing as a bypass. The solution is to set the projection and modelview matrices to identity.

In todays world of GPUs, in other words, a shader world, RHW is a dead concept. The vertex shader always processes ALL vertices.

Quote:Ah! never mind folks... I got it working after I put glLoadIdentity() right after I cleared the Buffers, seems to work 100% the same as the D3D9 version so long as I leave the RHW value in OpenGL as 1.0f o-0

That is the only solution. Also, as someone said, w is always 1 by default for vertices. It is the same for D3D.

But my D3D9 Renderer (it's the old D3D7 renderer just initializes D3D9 and calls that) uses RHW fine, infact it works just as it did 'back-in-the-day' it seems. I spent quite a bit of time fiddling around with the RHW in D3D9 in the end I had to inverse the old value to get a correctly working one for D3D9... so either you are wrong or I am doing something that is not done normally.

It will work with D3D9. The only thing I am saying that it is a dead concept. I haven't gotten into D3D10 but I wonder if they got rid of it. I know that you must do shaders with D3D10.