Remember when Fitz was a "faithful to the original 1996 Quake" engine? 

I was engine-mining and this wasn't what I was after, just incidental

I would stay away from engine-mines that contain bloom. Apparently such places are known for motion-blur cave-ins, and also contain noxious quantities of chromatic aberration gas that can cause explosions of film grain and vignetting.

I hear, however, that there are mines out there with much better health and safety rules that contain copious deposits of framerate independent physics. 

http://www.quaketastic.com/files/tools/windows/engines/Direct3D9-Wrapper-2017-01-15.zip

Several fixes and improvements, including:

* GL_NEAREST takes priority over anisotropic filtering.

* Off-by-1 crap with gamma != 1 in the menus is fixed.

* Performance improvements in texture loading and mipmap generation. 

You could always have lite and "ultra" version. 

Are all features born equally?

FitzQuake has fog, coloured light, external textures, interpolation, skyboxes; none of which were in 1996 Quake.

FitzQuake was never claimed to be "faithful to 1996".

http://www.celephais.net/fitzquake/

My primary focus is fixing a lot of the rendering bugs which made glquake inferior to the software renderer. My secondary focus is adding conveniences for mappers and general users. I am also slowly adding support for new modding or mapping features such as skyboxes, fog, and colored light. 

I did make an assumption that the engine goal was to modernise while retaining the original games feel. I assume that Baker would try not add too much bloat 

Almost done integrating the latest DX9 ... 

I'm trying to get my head around something in the shadow volume code.

I can reproduce test cases where they do and where they don't leak through geometry.

What I need to figure out is: is this happening because the volume isn't projected far enough (only 512 units) or is it happening because the draw order is significant?

If the latter then shadow volumes may be about to become about 2 billion times more robust. 

One of my goals is acquire key features from great engines of the past ...

The authors contributions to Quake lives on ...

And the unmaintained binary form of their work can rest in peace.

There have been several dozen brilliant engine authors who have made great contributions, often adopted by other engines.

Engine developers tend to have awareness of this kind of thing.

Maybe it is extended form of developer courtesy saying thanks to them.

Perhaps similar to how the best mappers are very aware of great mapping innovators of the past. 

Build 1029 - DX9 enhancements only

mh tuning of DX9 ...

- "Crunchy pixels" gl_texturemode GL_NEAREST should just work now.
- Should resolve a PixelFormat issue in some situations (breezeep)
- Faster mipmap generation for some setups (gunter)
- vid_hardwaregamma 0 (dx9 shader gamma) scrunched pixels fix. 

I quite liked how pre-1029 dx9 builds provided smoothed console text with 'gl_texturemode linear_mipmap_linear' and gl_texture_anisotropy set to any value above 1. It ensured improved legibility. Is the loss of this smoothing simply an unavoidable consequence of ensuring gl_nearest works as expected?

1028 - https://imgur.com/DZBpFVQ
1029 - https://imgur.com/wHUWGo9 

Looking good. Previous issues are indeed resolved (distorted text fixed, longer loading times gone).

The following issue still remains, and did not appear until DX9 1.26

borderless full-screen windowed mode (at your desktop res) only works if that mode was set before starting up (set from a previous run, or by command line) [**let me refer this this as Situation A]

Attempting to change to that mode after starting Quake (even just by toggling alt-enter twice) produces a bordered window, which obviously doesn't cover the full screen.

Ah, I see this also happens in the Windows version, but that has probably always been the case for that version, and that applies even if the setting was made before startup.



**Hm. and it looks like alt-tabbing away from Situation A is touchy.... Sometimes it seems to freeze up, and Quake never comes back (not even any menu sounds)... and I have to close it by right-clicking it in the taskbar. It doesn't happen every time I alt-tab, but it seems like about a 50% chance of it happening.

Alt-tabbing in true fullscreen works fine, as does it when using the bordered window. But alt-tabbing in Situation A seems to behave as if it's full screen -- the Quake window seems to minimize, whereas alt-tabbing from a bordered fullscreen window leaves the window behind whatever I have given focus.



THERAILMCCOY, try alt-tabbing a few times when you start up in the borderless window, just to see if this also affects you. 

@gunter - Glad to see loading times for you are fast again.

@railmccoy - In your 1028 screenshot, Mark V at least with automatic 2D scaling enabled shouldn't allow "smooth text" (I'd be a little surprised if the Open GL version behaved the same). The super-crisp text like in the 1029 screenshot is how text in Mark V is intended to be with automatic scaling.

I suspect viewport MH's fixes caused that to go away.

Although it sounds like you thought of the smooth text in your 1028 as a feature, although my intent was integer-only scaling ;-)

/If you are not using automatic 2D scaling, then the above wouldn't necessarily apply. 

/Forgot to add: source uploaded to usual folder where the download lives. Wanted to check all the builds before uploading to ensure they still compiled. 

Pre-1029 it seems to smooth text regardless of the value scr_scaleauto is set to - 0, 1 or 2.

scr_scaleauto 0 - https://i.imgur.com/GpbB9P6.jpg
scr_scaleauto 1 - https://i.imgur.com/ei9oAMk.jpg

All my scr_ settings are included in the above images. Also, yes, I've only seen this in dx9, it never appeared in dx8 or OpenGL. It did sort of feel like a feature, yeh, in fact I think I've seen cvars in other Quake engines for controlling the smoothness of console text.

Gunter - I can't reproduce alt-tab issues in the scenario you describe. 

@rail - yeah, I get that and I've had smooth text in other engine projects. But wasn't intended here as I hope to at some point in the future have integral scaling in the WinQuake build (but it's rather low priority, especially since Mark V WinQuake's stretch mode in video options to some extent provides a similar flexibility).

mh closed the book on that with the latest DX9 fixes in 1029. 

The other flavors of Mark V are good, hope I'm not reporting something that is known or ongoing ;) 

Arcane Dimensions start.bsp - alpha masked vines screenshot
DX8 screenshot start.bsp, which has no combine
DX9 screenshot start.bsp

Arcane Dimensions 1.50 download link:
https://www.quaddicted.com/filebase/ad_v1_50final.zip

1) c:/quake/dx9_mark_v.exe -nocombine (perfect!)
2) c:/quake/dx9_mark_v.exe -nomtex (perfect!)

3) c:/quake/dx9_mark_v.exe (doesn't look right ...)

If I type r_fullbright 1 in the console they become proper masked textures.

Typing fog 0 or gl_overbright 0 or gl_fullbrights 0 appears to have no impact.
-----

So it looks related to combine + multi-texture + lightmaps.

It's a very complicated case. 

Just an alphamasked test image:

http://imgur.com/a/XmcXl 

Yeah -nocombine/-nomtex fixed it. 

The one thing that always annoyed me about QMB -- which has effects for many things --- the Enforcers had no laser effect.

YouTube - Laser Effect in upcoming build

Modelled a bit after AMFQuake, which is a forgotten engine. 

Alpha masked textures must have always been there in prior versions. Or at least I don't understand how the latest wrapper changes could affect it. It sounds like a combine alpha mode is not set up correctly. Combine RGB is, that would be immediately obvious.

Sharp text actually goes back to original GLQuake, and was retained in Quake II. I believe the reason is technical rather than aesthetic: adjacent characters would bleed into each other with bilerping. Nonetheless, it was a very deliberate feature of the original code. 

My gut instinct on this is that it is probably not a wrapper issue.

I'd make the assumption that it isn't a wrapper issue until there is evidence that it is a wrapper issue.

I couldn't say with any level of confidence that the engine is hitting those draw functions in the same state every time, because there is no state manager.

Nor could I say for sure that everything that should be set, is being set.

Remember in prior time when the DX8 wrapper was new and you tested it on TyrQuake and discovered there was glPopMatrix with no push in the code (or something to that effect)?

Is something like that happening here? It is possible. I always assume something "not known to be under quality control" should be assumed to not be under quality control. 

It's possible that the bug is outside the wrapper although I'm not 100% clear on that owing to the following:

* I only see comparison screnshots with DX8 which didn't have combine.

* I only fixed the wrapper bug where combine wasn't reported for PS2.0 hardware quite recently.

So I consider there being some likelihood that it is in the wrapper. If -nocombine fixes it and if it's related to alpha masking, then alpha combine modes seem a possible first port of call to me.

Does anybody have a good test map for these? Preferably something that doesn't require BSP2 or a custom progs? 

Here is a bsp that'll load in Fitz 0.85 without a progs.

http://quakeone.com/markv/media/start_ad.zip

You'll have to noclip up the vines.

I played around with the function in Mark V's gl_world.c:R_DrawBrushModel_DrawSequentialPoly ... if (gl_overbright.value)
if (renderer.gl_texture_env_combine && renderer.gl_mtexable) section ...

And made a number of attempts to explicitly set everything and it looks like somehow D3D isn't honoring the GL_ALPHA_TEST on first texture in the combine.