The new shadows look really cool, especially on rotating items.

Anyway, it doesn't look that cool in certain situations such as this (regarding the casting location of the shadows).

However, I think that problem already existed with the old shadow system, so I guess we have to file it under visual glitch. 

Heh, yeah that's what I said above about where they leak through geometry.

In order to solve that you'd need to start casting shadows from all brush and world geometry, and next thing you know you've got a full-blown real-time lighting engine.

Personally I always run Quake without shadows anyway, on the basis that no shadows are better than bad shadows. This just offers shadows that are bad in a different way. 

A blob like in quake 3 

Still has all the flaws of standard GLQuake shadows. 

Because you have anisotropic filtering set to higher than 1.
OK, I set it to 1. Fixed the blurriness but now my liquids umm... scintillate? (don't know the exact word for it) in the distance, a bit like old TV static. I suppose this is an either/or situation? 

ow my liquids umm... scintillate? (don't know the exact word for it) in the distance

Original FitzQuake doesn't mipmap water textures and this is inherited from that.

On the one hand that replicates the behaviour of software Quake. It also makes the render-to-framebuffer waterwarp easier because you only need to render a single miplevel instead of the full chain.

On the other hand it causes sparklies in the distance. 

'Scintillating water!'

Put it on the back of the box.

No issues with fullscreen alt-tab and r_oldwater 0 now. Gonna play around with the new builds now and see if there's anything else to report. 

Bendy shadows are neato! (and ghost shadows are amusing) 

Mirror freezeup = fixed!
Window clamping resolution glitch = fixed!
New shadows = neat!
Old stencil shadows = now working too.
fugly fog = less fugly!

Fantastic work, mh!


Issues that still exist:

Delay upon first starting a game still happens.

Using external textures and a skybox, no MP3s, all settings the same, upon first starting a new game (starting Quake fresh before each test), time between telling it to start the game in the menu and when the game actually starts:

DX8 = 3.16 seconds
Dx9 1.25 = 3.17 seconds
Dx9 1.26 = 7.17 seconds
Dx9 1.28 = 6.89 seconds

DX9 1.28 with no skybox = 6.45 seconds
DX9 1.28 no external textures = 2.87 seconds
DX9 1.28 no skybox + no textures = 2.42 seconds

DX9 1.25 no sky + no textures = .87 seconds

So the skybox causes a slight delay, but it's the external textures which are really causing the delay, as of version 1.26

The above tests are running id1. The delay gets worse when I'm running FvF, which may be loading other things like monster skins:

DX8 1.28 = 5.96 seconds
DX9 1.28 = 12.59 seconds

So it seems like it is taking very close to twice as long, which may be a clue, like maybe it's loading the textures twice....



Also still happening as of 1.26, when first setting a full-screen windowed mode that matches screen resolution, I'm instead getting a clamped, bordered window (1024x578) instead of the previous 1024x600 borderless window. But the text in the bordered window looks correct....

Upon restarting Quake after making that setting, I get the 1024x600 borderless windowed mode, but I can tell the menu text is distorted (using scr_conwidth 1.5 -- I previously showed screenshots of this effect).

I seem to be getting that distortion in any full-screen mode (this was happening as of 1.25, but not in any of the DX8 builds), which seems to indicate it's still not quite got its rendering resolution just right in full-screen mode.

Ah, I think it's only happening when it's a full-screen mode with height equal to my resolution (so 800x600 or 1024x600 full-screen modes). It seems like it's drawing at a resolution equal to the clamped window's screen height (578), even when that's not needed because it has the full-screen mode height (600 with no borders) to work with.... 

I may be tripping, but everything seems taller.

Thinner ogre legs are weirding me out. 

Old issue has popped up. Well, it was an old issue in DX8, but it was fixed in that. It exists as of DX9 1.25:

gl_fullbright 1 = most weapons opaque when using ring + transparent weapon models (but not axe) unless using custom textures (must be as metlslime said, and the custom textures don't contain fullbright pixels). Illusionary ent guy is also opaque.

gl_fullbrighs 0 = everything transparent, including illusionary guy.


Interestingly, I can see my shadow through the otherwise opaque illusonary ent guy IF I set r_shadows 3.


r_shadows 3 looks cool, and works fine when I'm running around a map by myself, but my little netbook cannot handle it when there are lots of other things casting shadows! Yikes, kills my FPS hard....

And it can make some weird effect, heh, like this:

http://imgur.com/a/8zbT5

But as the 2nd screenshot shows with standard shadows, weird shadows were always a thing in Quake! 

@fifth - If you have a chance, could you let us know if the 1028 build DX9 works ok now?

@jimbob - thanks for info. Awesome. "Thinner ogre legs are weirding me out" ... I'm assuminng you are talking ogre shadows with r_shadows 3, but if not could you post a screenshot?

@rail - nice to see r_oldwater issue is put to rest.

@gunter - I'm getting this too.

I type map "dm3" with r_viewmodel_ring 1 (it's in the menu by setting "Invisibility: Draw Weapon")

I grab the ring and the weapon is fully visible, instead of translucent.

Also in some cases, transparent entities are more transparent than in Open GL. Putting this e1m1 external .ent file in quakeid1maps, which turns the starting elevator into a transparent func_illusionary, it is close to fully invisible in DX9 but rather visible in Open GL.

That elevator example wasn't of enough interest by itself, but since Gunter pointed out the invisibility weapon draw, I thought now was a good time to mention it.

However, I didn't want to point it out until I had time to verify that the state of all the gl capabilities is correct --- i.e. I cannot be 100% that it couldn't be a Mark V mistake that shows no symptoms in Open GL. 

Shader gamma - stretch looking

What I think could be going on there relates to how 2D matrix calculations often need a 0.5 nudge for even numbers.

The menu canvas in that scenario should be 320 x 200. I don't see the "stretch effect" in the console at 640x480 in Mark V, but the stretch impact might be too minimal.

If I were to type vid_hardwaregamma 1, instead using display brightness adjustment and not the shader, the menu text appears normal. 

Comment you made elsewhere was insightful -- "It suits me as well to work on the rendering layer and let other people deal with the other stuff."

Since the inverse has been helpful for me, since I've been able to focus on an entirely different set of objectives, like concentrating on get some extra builds ironed out (linux, trying to address killpixel's now deceased issues with WinQuake, etc.)

The fact that waterwarp and shadows work on these other platforms like linux is awesome, clearly.

/Time for me to attack outstanding issues, Mac build and see if firewalled .bsp rotation support can be implemented for damage_inc/sock. 

Although I have no need to use it. Is there a reason why gl_texturemode is always linear? 

Baker and MH, you two are just incredibly passionate workers.

DX9 version is of interest to me because ShadowPlay(Nvidia recorder) can hook with it. Water warp is a great effect and I get smooth gameplay with the latest beta release. r_shadow 2 looks great, with 3 having strange issues like the shadows being cast on the geometry below.

Is there a reason why gl_texturemode is always linear?

From my brief test, I also noticed this! 

mh on how d3d filtering is different

Because you have anisotropic filtering set to higher than 1. Nothing I can do about that; D3D defines 3 texture filter modes: point, linear and anisotropic. If anisotropic filtering is higher than 1 then point filtering (the equivalent of GL_NEAREST) is ignored.

At some point, I'll add an FAQ or some way to convey that information because I can see that continually getting asked.

Shorter version: Disable anisotropic 

Ah, Baker identified the distorted text issue I was talking about above, when in fullscreen modes. If I go back to vid_hardwaregamma 1 then the text looks correct.

vid_hardwaregamma 0 makes it distorted again.


Note: though the help info says "2," "r_waterwarp 3" is the setting needed to revert it to the old GL style (the new waterwarp kills my FPS in GL, though it works great in DX).


@Baker: I remember gl_overbright_models would affect how transparent the illusonary ent guy appeared, but he is a player model.... That setting probably wouldn't affect the elevator. Well, I just know that you fixed what seemed to be the same issue for DX8 back in build 1009.


Random feature request: Many modern mice also have a left/right motion for their scroll wheels (and trackpads do too), used for sideways scrolling. You could make those actions bindable:

mwheelright
mwheelleft 

1. Alpha masked texture support is buggered in dx9 - https://postimg.org/image/my3kopu9t/

2. Getting really bad framerates in OpenGL. Noticed it most severely in final fight on ad_fenrir, where I dropped to 40s. Thought it might be just AD mod, but it's id1 too, as I was getting framerates of only 100 in areas with a wpoly count of 1000, which isn't normal (I usually cap at 72 obviously; just host_maxfps 250 to test). Input latency felt worse in both OpenGL and dx9. I can measure that again with a high fps camera if necessary, but I'm pretty sure about it.

3. Engine still seems to start fullscreen borderless in dx9.

4. On shadows - it's nice to have another method, and they do look a bit better than standard glQuake ones certainly, though I agree with others in that my tendency is to use no shadows rather than ones which frequently display in weird ways.

I'm aware that mh pointed out that blob shadows have the same issues as the ones currently present, but in some ways they are less conspicuous in their flaws, simply as a result of being smaller and not projecting as far. They also serve a useful gameplay purpose in aiding depth perception, especially when using rockets to fire at the floor. I don't remember those in Quake 3 having glaring flaws, and FTE has its own blob shadows that seem to work very nicely in my experience.

I'm also kind of curious about how games like HL2 did its shadows (the first game, not Episode 2 and later versions of the engine that added real-time shadows from flashlights etc). That game relied on lightmapping and yet had pretty good projected shadows for characters and props. They weren't flawless and did clip through [i]very[/i] thin walls in some circumstances, but they were generally very good.

5. Multisampling - I'd certainly defer to mh if he feels it's not worth the hassle in D3D. I did use it without issue in DirectQuake, though that is only a data point of 1. If you were to consider implementing it in OpenGL, I suppose the arguments for it vs using simply using very high resolution would be firstly, performance, and secondly the fact that not everyone will have a high res monitor to run 4k etc, with downscaling tending to produce a blurrier image. If you're going to support dx8, you may as well also cater to those who have older monitors.

I don't mind either way, just discussing the hypotheticals really. 

Maybe the solution to this is to have the engine reset gl_anisotropy to 0 or 1 if gl_nearest is activated for the DX9 version then, and maybe print something or notify the user. 

[@fifth - Yeah that is what I decided ... Beats writing up documentation no one will read, hence people would still be confused]

Mark V dir command - an obscure feature

In Mark V, the dir command will list all the files in the current Quake folder (recursively) and sum the sizes.

Examples:
1) dir
2) dir retro*.bsp // Find map beginning with retro
2) dir *.tga
3) dir "*.tga;*.png" // semi-colon requires quotes
4) dir a?*.* // ? is means any single character
5) dir *a*.* // Anything with an a in it
6) dir "<reject>*.dem;<accept>*.*" // list all files that are not demos

The above system is kind of a byproduct of the auto-completion system.

The auto-complete abilities need to be able to filter through lists of files with Gunter-like pickiness to match the ones that apply.

/End obscure feature 

I have started a list of Linux issues and feature requests (and observations?), available upon request :P

Don't want to just dump more stuff onto your pile, though. And it will probably mostly be stuff you know about already... 

THERAILMCCOY, I can only replicate the issue you are having (starting in borderless fullscreen window rather than true fullscreen) when I start with command line options like:

DX9_Mark_V -width 1024 -height 600


Normally if I exit the game when running a fullscreen mode, it starts up next time in that fullscreen mode....

If I use the above command line, it starts up in the borderless window mode every time (or a bordered window if I'm setting like 800 x 600).

-fullscreen command line option doesn't help (if that's valid).

But if I also add autoexec.cfg settings like you described (vid_width 1024; vid_height 600; vid_fullscreen 1; vid_restart) then it correctly sets me to true fullscreen mode... 

Dump away. I want to know what works well, what doesn't work well, etc.

I may not be able to act immediately, but when I know about things it helps plan. 

GL_NEAREST modes and anisotropic filtering

This is one of those cases where you have to balance correct behaviour vs expected behaviour. D3D doesn't allow you to have both set at the same time. Previously I had erred on the side of anisotropic filtering as the expected behaviour. I was wrong. If people set a GL_NEAREST mode it's because they want crunchy pixels, and anisotropic filtering be damned. I'm prepared to be pragmatic about this. I've a coupla things to test but if it turns out to be the case that GL_NEAREST needs to take priority, then so be it.

Multisampling

Some day I'm going to work through this and see what's reasonable to do. The fact that I haven't done so yet doesn't mean I'll never do so.

This is one of those "API differences" things. GL lets you throw some numbers at it and the driver does the right thing. D3D exposes more of the ugliness that actually lies beneath the covers. Get it wrong in D3D and the driver will crash.

I'm just saying that it's much more work than people probably realise.

Off-by-1 crap

In my own tests this only seems to happen in the menus. I set gamma to 0.7 and press ESC to toggle the menu. You can clearly see the rendered frame shifting.

This makes absolutely no sense whatsoever to me. I still suspect GL_SetCanvas though.

Borderless modes

The wrapper actually always starts up in a borderless mode and then switches to proper fullscreen as soon as Direct3D is initialized.

This was very deliberate and intentional.

This behaviour is required by DXGI on Vista+.

If anything goes wrong during startup you get to still have control over your desktop this way.

It plays nicer with other programs that may be using the graphics hardware.

This one is non-negotiable. If there are glitches as a result I'll make a best effort to fix them, but the behaviour itself is not going to change.