Hello, me again. So after doing some experimenting with an older Mark V build (1036), we've found that DirectInput is the culprit for causing the mouse registry issues. Build 1036 did not use DirectInput and there are no longer any mouse-click registry issues with it for me. I would stay on this older build but unfortunately it comes with some pretty bad framerate drops here and there, unlike the newest one.

If Mark V 2.0 is ever made, can there be an option to disable DirectInput and go with whatever control configuration was being used in build 1036? I would love for that to happen, as I love the performance of the latest Mark V, it's just the mouse registry stuff ruins it unfortunately.

Thanks for your work baker, hope you can help. 

Sadly, Baker disappeared some months ago. 

@mankrip yes, I see that from this thread lol. Oh well.

Anyway, good news. It turns out that if I run the latest version's Directx9 exe I no longer have issues with mouse registry. Runs great. This is my new favourite Quake port, even if it currently feels a bit buggier than Quakespasm. I had one crash with this. I exited E1M5 and it crashed to desktop. Hopefully that was just a one off. I really love this port and just wanna express my appreciation. The feel of the mouse is just godlike.

So yeah, cheers, please ignore post #2619 as DirectInput clearly isn't the cause of mouse reg issues, as somehow the directx9 version of the latest released does not have those issues for me. 

scourge of armagon music won't play unless you change the the volume slider. dissolution and vanilla work fine. 

ask otr or eddie to fix it 

Had this issue while trying to play Artistic's map for MapJamX, while using D3D9.

Any idea on how to fix this? 

I love the look of GL_NEAREST but there's horrible texture aliasing, which is improved by going to one of the mipmap_linear modes but then you lose the charming pixelated look.

Also, is it possible to add support for Antialiasing? I've tried forcing it in the Nvidia control panel seeing as this is a DX9 game, but it didn't work.
SMAA injector works, but it's only FXAA and makes the game blurry. 

getting me excited for a new build but it's just bots on google bumping up the thread :( 

it's driving me nuts... some kind soul go nudge Baker :( 

The crash can happen randomly when exiting levels. Curiously it happens often when exiting E1M5 Gloom Keep for some reason. Just giving feedback, hope it can be fixed. 

GL_NEAREST_MIPMAP_LINEAR should give the best result. 

GL_NEAREST_MIPMAP_LINEAR disables anisotropic filtering. The lack of anisotropic filtering is the main reason for the texture aliasing, since Quake's textures are low res enough to not get grainy when viewed from a perpendicular angle. 

Is that exclusive to just nearest+linear, or all nearest* modes? Asking because I'm otetty sure that with nearest+nearest, I can see a bug difference between anisotropy 1 and 16 on the far away surfaces (in Fitz/QS). 

Meant to say "I'm pretty" (duh). 

... I´m otetty glad you did the clarification :D 

That may be driver-dependent, but I've never seen NEAREST_MIPMAP_LINEAR getting anisotropic filtered.

The _MIPMAP_LINEAR thing, afaik, basically tells the GPU to use linear filtering when generating the mipmaps. So, it influences the quality of the data that's rendered, but not the rendering itself.

If you're noticing a difference when _MIPMAP_LINEAR is turned on, your GPU may be generating anisotropic mipmaps (ripmaps) for the textures. But I'm still skeptical about it using anisotropic filtering per se.

Anisotropic filtering is like a superset of trilinear filtering. While trilinear filtering filters across square mipmap levels (both coordinates at once), anisotropic filtering filters across each texel coordinate individually.

Now, the huge catch is, pretty much all GPUs requires bilinear filtering to be enabled if you want to use trilinear filtering (and anisotropic filtering)... But mathematically, bilinear filtering isn't required. Bilinear filtering only filters across the UV plane, regardless of mipmap level. You can still blend mipmap levels (including anisotropic ones) without blending UV coordinates.

Well, this video doesn't show it, but Retroquad can do trilinear filtering of mipmap levels without doing bilinear filtering of texel coordinates.

I also want to implement anisotropic mipmapping someday, and it won't require bilinear filtering either, but anisotropic filtering may require it. Anisotropic mipmaps can be trilinearly interpolated across mipmap levels with the same width/height aspect, but afaik, to do anisotropic interpolation on them, the blending across mipmap levels must be done in a subtexel scale. Or maybe not. I haven't got to that part yet.