Direct 3D 9.0c Quake
Moderator: InsideQC Admins
by MeTcHsteekle » Wed Jan 21, 2009 11:21 pm
heh Hondo Bondo's SPDM SuperDuper Quake: Duke Nukem Vs. the Whole World actually started in DirectQ, i mean as in, i was on the start map [a great leap forward compared to most other engines] but then a monster spawned in [most likely one with skin that is too large, or maybe too many verts] and crashed it [stopped workin'], cant wait and see if i will be able to play it in this engine
bah
- MeTcHsteekle
- Posts: 399
- Joined: Thu May 15, 2008 10:46 pm
- Location: its a secret
by mh » Thu Jan 22, 2009 9:18 pm
Not quite, more a case that it's a fix for widescreen monitors. The objective is to get the same vertical fov as a 4:3 resoltion (so that the top and bottom of the view don't get chopped off), which results in the horizontal fov becoming larger.
Regular GLQuake sets fovx to the fov cvar, then calculates fovy from that. This version (1) calculates fovy as if the resolution was 640 x 480 (and taking the fov cvar into account), then (2) recalculates a new fovx from the result using the correct resolution.
Hope that made sense, it's kinda hard to explain.
Regular GLQuake sets fovx to the fov cvar, then calculates fovy from that. This version (1) calculates fovy as if the resolution was 640 x 480 (and taking the fov cvar into account), then (2) recalculates a new fovx from the result using the correct resolution.
Hope that made sense, it's kinda hard to explain.
-
mh - Posts: 2292
- Joined: Sat Jan 12, 2008 1:38 am
by Tomaz » Thu Jan 22, 2009 9:29 pm
You got MSN or ICQ or IRC something? if so then please PM me your contact info. I wanna discuss this further but do it "faster" than typing posts in a forum.
Just to point out though, you recalculating fov_x does nothing but make a different frustum for clipping. Its never used when setting up the real screen. Only fov_y and the aspect is used there.
From this i draw the conclusion that the window in glQuake goes "wrong" because width and height is involved in the calculation of fovY which gives it the wrng value ( and has always done even in iD's code ) where as the formula i use calculates the proper fovY not careing what size the window is.
Just to point out though, you recalculating fov_x does nothing but make a different frustum for clipping. Its never used when setting up the real screen. Only fov_y and the aspect is used there.
From this i draw the conclusion that the window in glQuake goes "wrong" because width and height is involved in the calculation of fovY which gives it the wrng value ( and has always done even in iD's code ) where as the formula i use calculates the proper fovY not careing what size the window is.
- Tomaz
- Posts: 67
- Joined: Fri Nov 05, 2004 8:21 pm
by mh » Thu Jan 22, 2009 11:42 pm
It keeps fov y constant for different values of scr_viewsize, yeah. This lets us remove the hack in V_CalcRefdef, and also just plain looks better.
The fov x calclation, yeah it does calculate a different frustum, but that's needed otherwise we get this:
The fov x calclation, yeah it does calculate a different frustum, but that's needed otherwise we get this:
-
mh - Posts: 2292
- Joined: Sat Jan 12, 2008 1:38 am
by MeTcHsteekle » Fri Jan 23, 2009 12:32 am
CLIPPING..!!!... NOOOOOOOOO!!!!!!!!
[indescribable sound/scene of a person going through a large meat/organ grinder]
[indescribable sound/scene of a person going through a large meat/organ grinder]
bah
- MeTcHsteekle
- Posts: 399
- Joined: Thu May 15, 2008 10:46 pm
- Location: its a secret
Who is online
Users browsing this forum: No registered users and 1 guest