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. 

Issues:

1. gamma and contrast appear to do nothing (No big deal in my case, cos I have a desktop workaround).

2. Toggling external textures in windowed mode crashes cleanly to desktop.

3. When I go fullscreen, it always reports that it has set Quake to my desktop resolution (1680x1050), and refuses to stretch out lower resolutions to full screen. Not sure if by design, but frankly, it's so fast that I'm not sure it matters.

Requests:

1. support for 6+ mouse buttons (seems limited to 5 right now). Not sure how mwheelup and mwheeldown factor in, so I might need up to 10?

2. MP3 emulation of CD music (Is it missing in Linux, or do I just need a workaround?)

3. "Restore" printing of console messages to Linux terminal too (minor, but would be nice). 

This is something that crops up from time to time. "How come HL/HL2 can do XYZ but Quake can't?"

On the surface it seems reasonable. Both HL and HL2 are ultimately derived from Quake.

The difference isn't technology. The difference is content.

If you're starting from scratch with entirely new content you get to be able to say things like "brush models don't exist" or "I only have one directional light and that's the only light that casts shadows" and whole classes of problems just go away.

If you're retrofitting new technology on existing content you often don't have that luxury.

As always, a best effort will be made, but Thou Shalt Not Break Existing Content. 

vid_hardwaregamma 0 should give you control over gamma/contrast. Use the "txgamma" console command to change gamma. I haven't taken the time to fully integrate it into the menu.

mp3 music. At the moment, no Linux music option. I've had my eye on a few different methods including what VideoLAN does to unlock mp3 hardware accelerated decoding on Linux already built into your processor (Intel, AMD, ..). Haven't had time to conduct experiments and evaluate choices.

/So the quick ones are out of the way ;-) 

I'll play with the GL_SetCanvas and see what happens. 

From what I've read, only the video decoding part of video playback is hardware accelerated, since it takes very little CPU power to decode mp3, but I am curious anyway. Some link dumps:
https://trac.ffmpeg.org/wiki/HWAccelIntro
https://www.remlab.net/op/vlc-vdpau.shtml
https://en.wikipedia.org/wiki/Video_Acceleration_API

Wonder if gstreamer would be an option? It's a big bloated API, but I think it handles sending audio to the OS mixer itself.. so maybe you could get away with no changes to the Quake sfx mixer. Wouldn't be great for Mac though as it's more of a Linux library. 

txgamma works!

IDK if this helps at all, but Darkplaces for linux has working MP3/CD audio. 

I tried doing "dir" just to see it...

YIKES. I'd say it's a bad idea to do a complete listing of every file contained in every subfolder in the current directory... (I have a lot of content folders in my fvf directory...).

Make it like DOS does. Only show the names of folders, and not a full directory listing of each of those subfolders.

...unless I Ask for "dir maps" ...which doesn't actually work....




Also, just thought, can that fugly fog fix (and other stuff) be applied to the DX8 build? 

Some, but not all, could be applied to DX8. I'm not sure there's any really huge need to, however. 

The "fugly fog fix" isn't a one-line-of-code thing.

It means implementing GL_COMBINE modes, close on 100 lines and a complete re-architecting of how texture environment modes work.

Then you get to do the one-line-of-code thing.

Given that the DX9 build will run on downlevel hardware I don't think it's a productive use of time. 

Then perhaps have this work so that whatever is set last take precedent. So if anisotropy is already set and then nearest is chosen it undoes anisotropy. And vice versa, that way you get a visual feedback back that you can't have your cake and eat it 

At least from my point of view that seems like an improper request.

Let's focus on the future.

There is only so much time in the day, let's use it wisely. 

/I was referring to the idea of updating DX8. 

iirc nearest+anistrophy is undefined in opengl, so fte only enables anisotropy with mag=linear so you know what you're going to get.
should probably force mip filters too... :s 

GL_EXT_texture_filter_anisotropic

GL actually does define GL_NEAREST + anisotropy, but it modifies the behaviour of GL_NEAREST from being a "crunchy pixel" mode to being a "select the type of anisotropic filtering used" mode.

The extension notes that such hardware actually does exist. Maybe it did back then but I'm not certain that it does any more.

Cross-checking this extension with FitzQuake's checks for anisotropic filtering, I'm not sure what the intent behind the latter is, but the extension notes that 2 is minimum value so it would be sufficient for FitzQuake to just check for 2.

Setting to 1 disables anisotropic filtering. I'm not sure how well-known that is; disabling anisotropic filtering is a value of 1, not 0. Setting to 0 will actually throw a GL_INVALID_VALUE.

D3DTEXTUREFILTERTYPE enumeration

Direct3D 9 doesn't clearly define how anisotropic filtering works at all. You need a bunch of trial and error to figure it out yourself.

It does state that you cannot set an anisotripic mip filter, but you also cannot set an anisotropic mag filter - the D3D debug runtimes will throw "unsupported mag filter" errors. So anisotropic is for min filter only.

Setting max anisotropy to any > 1 value without also setting the min filter will not give you anisotropic filtering.

Setting mag filter to point/nearest and min filter to anisotropic will actually give you a blurry mag filter.

What a mess.

Decision time

I'm going to do the same as Spike and only enable anisotropy with mag filter = linear. It's clear from upthread that expected behaviour is "if I ask for crunchy pixels I want to get crunchy pixels".

I think setting them in the order that commands are issued is just going to create a mess that will eventually explode in your face. I do understand the visual feedback element, but that only applies if you're entering commands manually in the console. Whatever is chosen must also give expected behaviour with config files. 

 

I get this error: video: ChoosePixelFormat failed 

The OpenGL build should also fail because this is common to both.

I'll override ChoosePixelFormat for DX9. 

FitzQuake's GL_SetCanvas (CANVAS_MENU) was leaving the viewport smaller than the full render target when doing the gamma/contrast pass. That's what caused it to be off-by-1 and that's why I saw it shifting while toggling the menus.

I've a nice body of fixes built up again now so may do another code dump soon.