Screen coordinates of BSP polygon vertexes
Posted: Sun May 20, 2018 7:53 am
I'm having a hell of a hard time trying to do this on a BSP polygon:
- Get the on-screen vertex coordinates which are nearest and farthest from the screen plane;
- Calculate their midpoint (mid = near + 0.5 * (far - near), for each axis);
- Display the crosshair over it (setting cl_crossx to mid[0] and cl_crossy to mid[1], properly offset from the screen center).
The thing is, it gets screwed up right at the first step. The other two are fine. Sometimes it does work, but if I rotate the camera or walk a bit, it gets screwed up. It only works properly in a very few non-predictable angles & positions.
The x86 Assembly code is already removed from my engine, so there's no conflict there.
What I've done is, I've replaced the float nearzi with a vec3_t vertexnear and added a vec3_t vertexaway in both edges and surfaces, as well as replacing the float r_nearzi global with a vec3_t r_vertexnear and vec3_t r_vertexaway combo. So, every time the nearzi is calculated, the onscreen x and y coordinates (which the engine calls u and v) are stored in vertexnear along with the zi component. The coordinates of the farthest vertex are stored in a similar way.
And the problem is that despite the zi value being consistent at all times (both near and far away), the x and y coordinates of both vertexes jumps around randomly when I try to read them. It's driving me fucking nuts. I've double-checked the code multiple times and there's nothing outside of my code that could change the x and y coordinates.
- Get the on-screen vertex coordinates which are nearest and farthest from the screen plane;
- Calculate their midpoint (mid = near + 0.5 * (far - near), for each axis);
- Display the crosshair over it (setting cl_crossx to mid[0] and cl_crossy to mid[1], properly offset from the screen center).
The thing is, it gets screwed up right at the first step. The other two are fine. Sometimes it does work, but if I rotate the camera or walk a bit, it gets screwed up. It only works properly in a very few non-predictable angles & positions.
The x86 Assembly code is already removed from my engine, so there's no conflict there.
What I've done is, I've replaced the float nearzi with a vec3_t vertexnear and added a vec3_t vertexaway in both edges and surfaces, as well as replacing the float r_nearzi global with a vec3_t r_vertexnear and vec3_t r_vertexaway combo. So, every time the nearzi is calculated, the onscreen x and y coordinates (which the engine calls u and v) are stored in vertexnear along with the zi component. The coordinates of the farthest vertex are stored in a similar way.
And the problem is that despite the zi value being consistent at all times (both near and far away), the x and y coordinates of both vertexes jumps around randomly when I try to read them. It's driving me fucking nuts. I've double-checked the code multiple times and there's nothing outside of my code that could change the x and y coordinates.