crosshair is misdrawn #53
Comments
neogeographica
changed the title
|
If I add this into Draw_Crosshair just before the glBegin: glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);...then the "wraparound" wigginess shown above will be fixed. I'm not an OpenGL guy so I'm not sure yet that's the right thing. Also there is some oddness going on in how the center and bounds of the crosshair are being calculated ... especially (but not only) in the case where crosshairimage is set. Although I haven't actually tried using crosshairimage. I might end up just adding the clamp code and then leaving the other stuff for later investigation. (P.S. It looks like we may actually want GL_CLAMP_TO_EDGE instead of GL_CLAMP, but that's an extension that doesn't show up in reQuiem's current GL.h header. Since it came in with OpenGL 1.2, almost certainly anything that can run reQuiem will support it. On the other hand, I tried using it and didn't see a difference compared to using GL_CLAMP.) |
|
And it turns out that the other crosshair shape problems -- looking like an arm is too short, or even misshapen arms (try crosshairsize 3) -- can be "solved" by declaring linear filtering for the crosshair. I tried specifying GL_LINEAR for both GL_TEXTURE_MIN_FILTER and GL_TEXTURE_MAG_FILTER on the crosshair, and the crosshair shape issues went away. Of course then I had a fuzzy crosshair, which is a different problem. But anyway that does seem to indicate that the remaining shape issues are from the nearest-pixel texture mapping. It's possible we could solve those with more attention to the definition of the crosshair bounding box. |
|
Quick pre-Monday-work update. :-) If I change ofs1 and ofs2 from 3.5/4.5 to 4.0/4.0, the crosshair shape issues go away. My understanding is that in an OpenGL 2D coordinate space like this one, when laying out the vertices of a quad, an integer position (like x=400 y=300) represents the upper-left corner of a pixel, not the center of a pixel. If that's the case then the 4.0/4.0 offsets really seem like the "mathematically correct" thing to do in any case. That makes me wonder where 3.5/4.5 came from though. I'll look into that more later and perhaps also experiment with crosshairimage. |
This has to do with issue #53. As near as I can tell, the original reQuiem code was working on a couple of assertions/assumptions. 1) The player's shots are a little off-center. 2) Crosshair images have equal height and width. #1 is true of course, hence why people fiddle with cl_crossx and maybe cl_crossy. It looks like JDH or maybe Joe of JoeQuake was trying to correct for this by shifting the crosshair right and down by a half pixel. Unfortunately shifting crosshair graphics by a half pixel makes them often look like garbage. (The half-pixel shift was only for the built-in 8x8 crosshair graphics. For user-specified crosshair images, which could be of any dimensions, I don't at all understand what the original code was trying to do. It gives the same result as the built-ins if the user-specified image is 8x8, but if it is larger then it is more and more off-center.) #2 isn't necessarily true, but it is true for the built-in crosshairs, and should be usually true for user-specified images. This is probably why the code was treating the distances "from top to center" and "from left to center" as one constant value, and then the distances "from right to center" and "from bottom to center" as a different constant value. And also why for user- specified crosshair images it was only looking at the image width as the basis for calculating both vertical and horizontal positions. ========== These changes shake things around in a few ways: - Crosshair images are not assumed to have equal height and width. - Crosshairs are placed dead-center on screen (as with original Quake). If the user is not happy with that then they can adjust cl_crossx/cl_crossy like grandpa used to do. - User-specified crosshair images will be centered, regardless of their size. I'm also clamping the crosshair graphic so that it doesn't "wraparound bleed", which might otherwise happen for certain image dimensions and certain cl_crossx/cl_crossy values. ========== I'm not sure my interpretation of the original code's behavior is correct, or that this fix is the right fix. It also might be preferable to (for example) go ahead and put in a bias of 1 pixel for the crosshair X position. Or default cl_crossx to 1, or something like that. I'm just committing this now in case Spirit or any other interested party wants to try it and give feedback.
|
Experimental changes on the crosshair_placement branch. See comments for eefeab6 |
|
Started a fishing thread at http://forums.inside3d.com/viewtopic.php?f=3&t=5528 |
|
Fishing thread may have hooked some results. |
I originally thought this only happened in 4:3 resolutions, but it's not limited to that. The problem shows up in certain combinations of resolution and crosshair size.
It looks like it is vertically mispositioned.
When the problem shows up, it looks like some of the top bit has "wrapped around" to the bottom of the character space. Below is 800x600 at crosshair size 1:
(This isn't related to any recent changes... original reQuiem release had this issue too.)
Even in 1920x1080 it looks a little wrong at crosshairsize 1, like some of the bottom arm is missing, but that could just be an artifact of the crosshair scaling.
The text was updated successfully, but these errors were encountered: