crosshairs in reQuiem (JoeQuake)

[Johnny Law]

[Spike]

expect between 15-50 defects per 1000 lines of code, depending on language and programmer.

the 0.5 thing might be to work around an issue with the d3d wrapper that was popular at some point (d3d9 uses different texture coord origins or something).

the only way to center the aim point is to 1) use more precise angles for the client->server messages. 2) move the view offset down by 6qu. these two things combined should ensure that the projectile always hits the exact center of the screen.

the center of the screen is not a single pixel. crosshairs look better when they ARE a single pixel. this could be another reason for the 0.5

conwidth/conheight not matching physical coords is another bug. rescaling with nearest-sampling is nasty stuff.

using linear sampling will result in bleeding through to other chars in the charset. the only way around this is to nudge the texture coords in by half a texel to avoid it sampling outside. this is made more awkward if using mipmapping (another reason to not rescale).
GL_CLAMP_TO_EDGE is not an option with atlased images (ie: conchars).

I've no idea what the ofs stuff is about. it could be to counter other offsets elsewhere.

[Johnny Law]

[Baker]

[r00k]

[Johnny Law]

[qbism]

Coords 1,1 and 64,64 with center at 32.5,32.5.... That's a 63x63 image.

[Spike]

thing is, even if you move the crosshair down+right by half a pixel/texel, you still have no middle pixel! the crosshair is right in the middle of 4 adjacent pixels!
moving it by half a pixel either just doesn't do anything (if nearest sampling), or blurs it (linear sampling).
I'd say leave it up to the artists to decide the center point. they can make that pixel the top-left or the bottom-right of the central 4 if they want. its less faffing around that way.
unless of course if you're willing to chop off a single-pixel row+column at the edges of the screen. then you get a middle pixel that would warrent biasing the crosshair to effectively ignore a similar pixel row+column.
plus many engines support npot nowadays, which might be useful if your viewing area has an odd number of pixels...
otherwise its pretty pointless.

@r00k, your ML_Project looks like something I wrote...
your 'start[2] += 16;//Methinks the start gets reset after SV_RecursiveHullCheck....so this is required.' line is wrong. should be 6 (or viewheight-16) instead of 16.
QC spawns projectiles at origin+16 and the view is at origin+22.
which might help explain what all the other y maths stuff is about. its not working properly! fudge it!
naturally this does nothing to solve/explain the half-pixel thing.

[r00k]

[Spike]

the first +=16 is correct, the second should be +=6 instead. then it doesn't need the half-distance fudge part (which would approximate 16/2 instead of 22-16, I guess, either way incorrect).
someone is wrong on the internet! yeah, this is going offtopic. :s

[r00k]

i dont totally understand the whole math to it,

I added the +16 ,

as it wasnt there and without it didnt work....

so hey shes ugly but she does work....


The real question is why should i need a += 6 when i already modded start +=16 before the call to SV_RecursiveHullCheck ????

[Spike]

view is at origin+22. gun is at origin+16.
22-16 = 6.
more correct is to subtract 16 then add cl.viewheight or whereever that value is stored. then it works with non-default viewheights too.
assuming projectiles still fire from 16qu above the player's origin, anyway.