viewmodel position shenanigans

[Johnny Law]

I'm looking at a few more reQuiem issues, and again I'm at least partially trying to figure out why things are being done the way they currently are before I commit to changin' stuff. I'll probably pop another two or three topics into the forum this weekend just to see if anyone is in the mood to drop pearls of wisdom. Feel free to ignore if you're not.

==========

This one is about the Z position of the weapon viewmodel.

In reQuiem, the viewmodel is riding pretty low on the screen...

I checked the original WinQuake/QuakeWorld code, and in V_CalcRefdef it increments the viewmodel's Z position by a little bit. Also the increment amount depends on the viewsize. reQuiem on the other hand has this code commented out, so the Z position isn't incremented at all.

Survey of some other code:

* Engoo does the "standard" incrementing.
* FMV does it only if r_viewmodelhackpos is set.
* Super8 has it commented out, but also does a significant increment if cl_nobob is set.
* QuakeSpasm has removed the incrementing.

So I guess reQuiem isn't completely the odd man out, and it looks similar to QuakeSpasm when in a 4:3 resolution. However when playing with a larger conwidth to accomodate widescreen, the reQuiem viewmodel sinks even lower (like original GLQuake behavior), while QuakeSpasm's viewmodel stays put.

==========

Couple of questions then!

1) What's up with all the different approaches to adjusting (or not) the Z position of the viewmodel? Is there some old discussion or accepted wisdom around that?

2) Possibly related to #1: is there a compact way of saying why QuakeSpasm's viewmodel is immune to changes in the conwidth/conheight ratio, beyond (for example) just "R_DrawAliasModel has been rewritten"? I'll dig into that sooner or later but a kick in the right direction wouldn't hurt.

Cheers!

[mankrip]

1) What's up with all the different approaches to adjusting (or not) the Z position of the viewmodel? Is there some old discussion or accepted wisdom around that?

For some weird reason that feature is often removed with no option to turn it back on. Makaqu is the only engine I knew that made it optional (I haven't played Fitzquake Mark V to compare).

Super8 had inherited that option from Makaqu, but from what you said, it seems that it has since been removed from Super8.

Unfortunately, a few people (including me) likes that feature, since it's one of the most unique features of Quake, so we get the short end of the stick when it comes to viewmodels in custom engines.

[leileilol]

Makaqu is the only engine I knew that made it optional

Sajt's unreleased GoldQuake also made this optional as v_fudgeweapon IIRC.

I like to leave it in since some mods are designed for the fudged position, like certain sniper rifles that have their scope directly over the crosshair at viewsize 100. Also it's the only way you'll see the whole barrels of v_shot2. The little things like these is why I left it alone as much as I could, as I see it important for 'vanilla behavior'

I also don't like the non-shrinking of the vrect when sbars are on the screen, this is common behavior of most GL engines and really hides an unfudged gun to the point you'd only see the bit of the top of the barrel of vshot. That's "refactoring cleaning up dead legacy cruft" for you, expecting you to reimplement these little things in CSQC if you want them.

[qbism]

Isn't the old fudge screwed up depending on how FOV/vrect is calculated?

super8 still has the scr_ofsx,y,z cvars but overrides x and z in SCR_AdjustFOV: psych!

Code: Select all

    scr_ofsx.value = (pow(scr_fov.value, 2)-scr_fov.value*70)/2000 -3; //qb: compensate view model position
    scr_ofsz.value = (pow(scr_fov.value, 2)-scr_fov.value*70)/2000 -1;//qb: compensate view model position


The adjustments work fairly well, but obviously not good behavior to a user or modder setting these and seeing no change. Not sure if this should just be removed or combine user + auto adjustment. Auto is nice for helping to compensate for FOV.

If any mods need to compensate for some weird (or improperly centered!) viewmodel then position should be set relative to the cvars. Again, so that user settings are not wiped out.

[leileilol]

Isn't the old fudge screwed up depending on how FOV/vrect is calculated?

Not for me.

[r00k]

in R_DrawAliasModel, I use this

Code: Select all

      if ((ent == &cl.viewent) && (cl_gun_fovscale.value) && (scr_fov.value != 0))
      {         
         if (scr_fov.value <= 90)
            scale = 1.0f;
         else
            scale = 1.0f / tan(DEG2RAD(scr_fov.value/2));//Phoenix
         glTranslatef(paliashdr->scale_origin[0]*scale, paliashdr->scale_origin[1], paliashdr->scale_origin[2]);
         glScalef(paliashdr->scale[0] * scale, paliashdr->scale[1], paliashdr->scale[2]);         
      }
      else
      {
         if ((ent == &cl.viewent) && (r_drawviewmodelsize.value > 0))
         {            
            scale = 0.5 + bound(0, r_drawviewmodelsize.value, 1) / 2;
            glTranslatef(paliashdr->scale_origin[0]*scale, paliashdr->scale_origin[1], paliashdr->scale_origin[2]);
            glScalef(paliashdr->scale[0] * scale, paliashdr->scale[1], paliashdr->scale[2]);
         }
         else
         {      
            glTranslatef (paliashdr->scale_origin[0], paliashdr->scale_origin[1], paliashdr->scale_origin[2]);
            glScalef (paliashdr->scale[0], paliashdr->scale[1], paliashdr->scale[2]);      
         }
      }


[Baker]

Isn't the old fudge screwed up depending on how FOV/vrect is calculated?

Engoo's FOV calculations using HOR+ MH, in my humble opinion, are how the calculations should be done.

I'd argue with the gun fudging, but I can see it both ways.

The MH version of HOR+ accurately renders regardless of resolution or viewsize without even the most mild fisheye effect --- at least as far I can notice and I'm picky about that.

I haven't use the above methods yet in an engine update, but the above is super-perfect in my opinion.

[leileilol]

the MH HORZ+ calculation has issues with scaled status bars that shrink the refdef further. I prefer Horz+ Qspasm

neither should have an adverse effect on the weapon fudging

[mankrip]

Isn't the old fudge screwed up depending on how FOV/vrect is calculated?

Not for me.

Not for me either.

By the way, even though Id Software themselves used the word "fudge" for this feature, it actually makes the weapon behave more naturally, because the player is holding the weapons in front of his torso, not in front of his face. So, it's natural for the weapons' rotation axis to be lower than the rotation axis of the view.

[revelator]

cant say i ever had any problems with that codebit either