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. 

Thanks for the shadow explanation, mh.

Gunter - I did stress that it seems to be in fullscreen borderless mode. It gives the impression of being so due to the appearance of a mouse cursor on the screen, that then goes away if I alt+enter. Once the game is definitely in fullscreen exclusive mode, alt+enter always triggers a switch to bordered window mode. Not sure if this was of any use to determine if what you describe in comment 991 is working correctly, mh.

Regarding the OpenGL performance issues I mentioned in comment 985 - it seems they actually started appearing from 125 on. I tried a few builds prior to that - 1001, 1016, 1017, 1019 (1019 being the last Windows OpenGL build I could see before 1025) - and they all performed well on ad_swampy. 1025 + 1028, the 2 Windows OpenGL builds I could see since 1019, both peform very poorly on the same map. 

So I'm testing LAN play at the moment!

It seems I have to connect using the connect command with IP addresses. I have tried using the 'local search' function but it doesn't seem to find the games being hosted.

I'm not an expert on LAN stuff so maybe I am missing something important? 

Also, I wanted mirrors. You can fake reflective water, a mirror teleport, you can do a lot of cool stuff... =~) So happy now. 

1) See post #8 in this thread http://celephais.net/board/view_thread.php?id=61375&start=8

Computer #1: In console: maxplayers 4; coop 1; map start
Computer #2: In console: connect lan // you're done!

2) @breezep - What are your computer specs? Like operating system, video card. I would guess that the DX8 build is a sure thing, but I would think all of them should work so this bugs me.

3) @rail - This bugs me just a little. I'll have to check and see what I changed since 1020 in the Open GL, but its not been anything deep. 

The 'dir' command seems to work fine, lists all the files inside the current game directory and its sub-folders.

The other commands you listed all seem to work fine too, though they only apply to the game directory itself, not its sub-folders (ie id1, but not id1/maps). So one can find *.pak but not *.bsp, for example. Not sure if this is as intended.

It's actually a potentially handy feature if you have a ton of maps inside a folder but can only remember a partial name for one. Quicker than scanning through the results of 'maps' command anyway. The ultimate would be a dir type command for Quaddicted files. =) 

Bloom

I just wanted to see what this would look like. Almost requires darkness and a base map with bright lights. Medieval wouldn't be a fit.

I was engine-mining and this wasn't what I was after, just incidental (what I was after is rather obscure and is likely on the verge of forgotten). It's been assimilated, although the code is not exactly efficient. 

involuntarily..... 

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.