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!
viewmodel position shenanigans
-
- Posts: 22
- Joined: Mon Apr 28, 2014 8:34 pm
- Location: San Carlos, CA
- Contact:
Re: viewmodel position shenanigans
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).Johnny Law wrote: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?
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.
Re: viewmodel position shenanigans
Sajt's unreleased GoldQuake also made this optional as v_fudgeweapon IIRC.mankrip wrote:Makaqu is the only engine I knew that made it optional
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.
i should not be here
Re: viewmodel position shenanigans
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!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.
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
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.
Re: viewmodel position shenanigans
Not for me.qbism wrote:Isn't the old fudge screwed up depending on how FOV/vrect is calculated?
i should not be here
Re: viewmodel position shenanigans
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]);
}
}
Re: viewmodel position shenanigans
Engoo's FOV calculations using HOR+ MH, in my humble opinion, are how the calculations should be done.qbism wrote:Isn't the old fudge screwed up depending on how FOV/vrect is calculated?
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.
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: viewmodel position shenanigans
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
neither should have an adverse effect on the weapon fudging
i should not be here
Re: viewmodel position shenanigans
Not for me either.leileilol wrote:Not for me.qbism wrote:Isn't the old fudge screwed up depending on how FOV/vrect is calculated?
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.
Re: viewmodel position shenanigans
cant say i ever had any problems with that codebit either
Productivity is a state of mind.