viewmodel position shenanigans

Discuss programming topics for the various GPL'd game engine sources.
Post Reply
Johnny Law
Posts: 22
Joined: Mon Apr 28, 2014 8:34 pm
Location: San Carlos, CA
Contact:

viewmodel position shenanigans

Post by 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
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: viewmodel position shenanigans

Post by mankrip »

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?
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.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
leileilol
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Re: viewmodel position shenanigans

Post by leileilol »

mankrip wrote: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.
i should not be here
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Re: viewmodel position shenanigans

Post by 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
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Re: viewmodel position shenanigans

Post by leileilol »

qbism wrote:Isn't the old fudge screwed up depending on how FOV/vrect is calculated?
Not for me.
i should not be here
r00k
Posts: 1111
Joined: Sat Nov 13, 2004 10:39 pm

Re: viewmodel position shenanigans

Post by 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
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: viewmodel position shenanigans

Post by Baker »

qbism wrote: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.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
leileilol
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Re: viewmodel position shenanigans

Post by 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
i should not be here
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: viewmodel position shenanigans

Post by mankrip »

leileilol wrote:
qbism wrote: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.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: viewmodel position shenanigans

Post by revelator »

cant say i ever had any problems with that codebit either :)
Productivity is a state of mind.
Post Reply