Direct 3D 9.0c Quake

[mh]

oh, and darkplaces and fitzquake both use "gl_texture_anisotropy" as the name of the cvar for anisotropic filtering... might be good to have consistency among engines where possible.

Actually this is quite important to me (one of the reasons I kept the other cvars as gl_*), I'll change it right away.

FOV - tell you what - I'll add a menu option for "compatible" or "correct". I don't think there's a 100% "right answer" to that one; some folks may not care too much for FOV but want their widescreen support done right, others may want consistent behaviour. Making it consistent with other engines will destroy the Y FOV correctness though (which would also be consistent )

I'm not sure if it's going to be easy to get a 100% accurate representation of fullbright pixels. Right now I'm using (light + fullbright) * texture, which more correctly approximates software but goes too far with overbrighting. At least it's consistent - many other engines use (light * texture) + fullbright, which is also wrong (you can get anything between 1 x and 3 x brightness on a fullbright with that). Maybe something like ((light - fullbright) * texture) + fullbright would get closer with native textures, although I worry about the luma maps that come with external texture packs (not too much though!) Whatever, getting as close as possible to software Quake is also very important too.

[MeTcHsteekle]

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

[mh]

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

I'll fix that.

Anyway, MODS ARE EVIL.

That's my announcement for the day.

I fixed the OpenQuartz problems; and I'm still shaking my head in disbelief at the apparent cause. It seems to be doing something too clever for it's own good in the Start map, but apparently there is a case where some inline brush models seem to share surfaces. I'm not certain what map editor allows this, probably something disgusting like Quark.

Long story short, because I add inline brush models to the main world render (i.e. the texturechains), at certain points I create a situation where the texturechain loops around on itself, becoming infinite. Hence the lock-ups.

Just ensuring that each brushmodel surf is only added once is the fix for now. Right now I don't care if I break something clever or special that was supposed to happen here (I probably will care when I simmer down a little).

This doesn't happen at all in ID1.

[metlslime]

FOV - tell you what - I'll add a menu option for "compatible" or "correct". I don't think there's a 100% "right answer" to that one; some folks may not care too much for FOV but want their widescreen support done right, others may want consistent behaviour. Making it consistent with other engines will destroy the Y FOV correctness though (which would also be consistent )

This is something i've had on my todo list for a while, partly because the best way to handle it isn't clear. FOV is defined as horizontal, but as we have both observed, it's more the vertical FOV that we want to remain consistent if playing quake at various aspect ratios. I had the idea of a "vfov" cvar, which if nonzero would override "fov." Even then, the question was whether vfov ~75 would be necessary to emulate fov 90, or whether "vfov 90" would actually mean "give me the vfov that i would usually have with fov 90 on a standard aspect ratio." Or, you could interpret vfov and fov as minimums, and use whichever one would yield the smaller total fov at the current aspect ratio.

I'm not sure if it's going to be easy to get a 100% accurate representation of fullbright pixels. Right now I'm using (light + fullbright) * texture, which more correctly approximates software but goes too far with overbrighting. At least it's consistent - many other engines use (light * texture) + fullbright, which is also wrong (you can get anything between 1 x and 3 x brightness on a fullbright with that). Maybe something like ((light - fullbright) * texture) + fullbright would get closer with native textures, although I worry about the luma maps that come with external texture packs (not too much though!) Whatever, getting as close as possible to software Quake is also very important too.

Fitzquake originally used alpha blending to do fullbrights, with the equation being lighting*texture *(1-alpha) + fullbright * alpha, which worked fine. In the upcoming version, to support the fact that everyone makes lumas with the assumtion of additive blending, i switched it so that fullbrights are additive blended, but with the original textures blacked out where there will be fullbrights added. If users disable/re-enable fullbrights, i simply reload all textures on the spot.

Using additive blending for fullbrights is also necessary for entity alpha to work correctly, if you need multiple passes.

[=peg=]

I fixed the OpenQuartz problems; and I'm still shaking my head in disbelief at the apparent cause. It seems to be doing something too clever for it's own good in the Start map, but apparently there is a case where some inline brush models seem to share surfaces. I'm not certain what map editor allows this, probably something disgusting like Quark.

don't blame the editor, blame the compiler tool..
i do use quark and i like it a lot.. but i use valve 220 map format to compile.. all the editor does is output a .map text file anyways..

i dunno if valve 220 format is related to the problem you encountered, but.. just saying the editor itself wont make brushes share faces

edit:
hmm come to think of it.. quark does allow the use of shared faces.. but i found out that that usually cripples the map on compiling.. so if i ever use them in the editor i always break em up again, after it served its purpose..
btw, let me know if you encountered any of these on my map, then i'll make sure to fix it

[Chip]

Actually, in QuArK, it's the other way around, faces share brushes. It's all for the purpose of consistent textures. Say you have a wall and you cut it to make a door. The wall brush would automatically split into at least 3 brushes. The texture will then be applied separately on these 3 brushes, and their intersection would create seams.

There is no other way to create this, other than, maybe, cutting the wall according to a strict grid (let's say 8 units), and then making the texture multiple of 8 and tilable). It's just too much work for small brushes.

Again, if the editor does share brushes, why wouldn't the compiler remove these shared brushes/faces but keep the texture coordinates? This would certainly work with DirectQ.

[mh]

This is something i've had on my todo list for a while, partly because the best way to handle it isn't clear. FOV is defined as horizontal, but as we have both observed, it's more the vertical FOV that we want to remain consistent if playing quake at various aspect ratios. I had the idea of a "vfov" cvar, which if nonzero would override "fov." Even then, the question was whether vfov ~75 would be necessary to emulate fov 90, or whether "vfov 90" would actually mean "give me the vfov that i would usually have with fov 90 on a standard aspect ratio." Or, you could interpret vfov and fov as minimums, and use whichever one would yield the smaller total fov at the current aspect ratio.

Looking back on one way I had it done before, the simplest way seems to be to only implement the widescreen fix if the FOV cvar is 90, otherwise fall back to default Q1 behaviour. This would suit those who didn't really care much for FOV but wanted widescreen to look right, as well as suit those who wanted a consistent result from their own preferred FOV.

[Tomaz]

Let me see if i understand this FOV thing correctly.
You now base your FOV on Y axis? So FOV 90 now means 90 on Y axis ( where it meant 90 on X axis in original quake )?

Easy fix i use in my D3D engine:

// Default fov is 90, if using that directly with D3DXMatrixPerspectiveFovLH we get a fov of
// 106.25 x 90
// By doing these calculation first we turn it into a fov of
// 90 x 73.74
// which matches how RenderWare worked and how most OpenGL games / demos work
tgFloat Temp1 = ( tgFloat )atan( tan( TG_DEG_TO_RAD( m_Fov ) * 0.5 ) * 0.75 );
tgFloat Temp2 = ( tgFloat )TG_RAD_TO_DEG( Temp1 ) * 2.0f;
tgFloat FovY = ( tgFloat )TG_DEG_TO_RAD( Temp2 );
tgFloat Aspect = ( tgFloat )m_Viewport.Width / ( tgFloat )m_Viewport.Height;

D3DXMatrixPerspectiveFovLH( ( D3DXMATRIX* )&m_Perspective, FovY, Aspect, m_NearClip, m_FarClip );

Basically this gives a FOV Y of 73.74 when feeding it FOV 90 which matches what FOV 90 in quake is, the benefit is that when going for a widescreen resolution, it "extends" the sides so you see more on the left / right side. Where in quake youd see teh same on left / right but see less in top / bottom.

So feel free to use this if this fixes anything.

// Edit:

Just tested your code and it appears that you dont get 73.74, the FovX formula looks wrong ( and it is the same as in glQuake ), one thing i saw different tho is that you also calculate a new FovX which results in it not being 90 anymore:

r_refdef.fov_x 85.909187
r_refdef.fov_y 68.038704

In glQuake it is:

r_refdef.fov_x 90.000000
r_refdef.fov_y 68.038696

This should give quite a different feel to the game, how someone feelt it was like FOV 120 i dont really understand tho.

Im confused, I'll be quiet for a while.

[mh]

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.

[Tomaz]

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.

[mh]

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.

Now I'm messed up. Can we leave discussing it for later when I can think more clearly?

Anyway, visual evidence indicates that my method extends the sides correctly too. Maybe it's a less direct way of doing it (I like the look of your method and probably will borrow it), but it works:

Normal 4:3 aspect


Widescreen aspect (1280 x 768)


And for comparison, the same widescreen aspect with the regular GLQuake fov calculation:

[Tomaz]

Yeah you fixed the widescreen issue by always feeding it 640 x 432, no matter the real resolution. This assumes the sbar is always visible tho. And on top of that I'm still quite sure the calculation of fovY that Quake has always done, is wrong.

[mh]

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:

[MeTcHsteekle]

CLIPPING..!!!... NOOOOOOOOO!!!!!!!!

[indescribable sound/scene of a person going through a large meat/organ grinder]

[mh]

[indescribable sound/scene of a person going through a large meat/organ grinder]

You been playing Zerstorer?