If Mark V supports shaders, you may want to try Seven's new_torch model found here: http://quakeone.com/forums/quake-mod-releases/finished-works/11595-a.html
Looks great and works like a charm (at least in DP). 

Uh --- Mark V certainly does NOT support shaders. And certainly never will support them either.

Do you have the slightest clue what dwere was posting about? No?

Ok -- now get lost.

/You are nice guy, but my tolerance for incompetence in a technical thread is zero. Don't do it again. 

Sorry if I upset you Baker, I didn't mean to. *tiptoes out* 

I'm sorry I posted too intensely, I try not to do that, but there's no edit.

You are a good guy. 

I ran through an episode with the gl version and it performed flawlessly. It may be safe to say that this issue is winquake specific.

I'd like to draw your attention to another curiosity, not because I'd like it changed necessarily, just interested to know why it is:

I like to use a faithful q1 viewwmodel fix that tweaks some verts and alignments. As you can see in this comparison, the texture alignment appears to be off even though we know it isn't (in winquake). 

Yeah I doubted the entire Divx suite needed to be installed hah.

Anything you want me to test as far as my black capturedemo issue?

As far as the sound issue where there was noise...I think 11k has noise and 41k does not. But at 41k the sound is "airy" for lack of a better word. QS does not exhibit this behaviour but it looks like it uses different method for sound processing?

Unrelated but using your advanced demo playback features to watch retrojam5 demos is a godsend. Changes everything! 

As you can see in this comparison, the texture alignment appears to be off even though we know it isn't (in winquake).

Software Quake and GLQuake treat MDL texture coordinates slightly differently. This is a giant PITA for me, because a model tweaked for one set of engines will have broken alignments in another.

I rarely miss an opportunity to rant about it.

BTW, it's funny how even a stock id model works better in a GLQuake-like engine. 

software rendering uses affine interpolation when drawing mdls, because its simpler/faster.
whereas brush surfaces use proper perspective correction by recalculating the texture coords every 16 or 8 pixels (d_subdiv16).
(quake2 added perspective correction on its md2s. I believe this to be the reason why quake used bsp ammo boxes while quake2 was free to use md2s instead)

glquake has an 'gl_affinemodels 1' cvar setting that asks the driver to replicate software rendering's crappy interpolation. however its one of GL's 'hints', which means modern drivers just ignore it and always use proper perspective.

if you have glsl 130 (gl3), there is a 'noperspective' interpolation modifier which ensures the same appearance. 

I should probably add that I was talking about a different problem. So there are at least two ways for a model tweaked for GL to be screwed by software rendering. 

I get a very consistent crash when trying to switch back to DX Mark V after alt-tabbing away, when I am running full-screen with vid_hardwaregamma 0

It does not occur with the GL version, or when using vid_hardwaregamma 1

It also does not occur if I am just sitting in the console before loading a map.

It also crashes if I am running it in a window and I try to adjust my windows gamma settings under the same circumstances above. 

there are at least two ways for a model tweaked for GL to be screwed by software rendering.

That's both hilarious and sad :/

@spike - that is interesting. given quake's initial low resolutions and non-interpolated animations, they might as well have just used sprites. They would've been better looking and probably easier to do. I suppose they pushed the tech knowing that appropriate hardware was just around the corner. 

The skin application in GLQuake and WinQuake are different. See the argument in the Quakespasm thread (it's buried), the different viewpoints and the final consensus reached by the developer types and mappers.

@re: GL runs fine

Awesome! Provides me with a little bit more incentive to build a Windows "WinQuake rendered via Open GL" like the Mac WinQuake Mark V. 

WinQuake rendered via Open GL

that has a nice ring to it. aside from the mac version, is that a first of its kind in terms quake ports? 

As someone who is exceedingly detail oriented, I give myself an F-- on the DivX download.

I'm very upset that I didn't investigate the current download (I trusted them!).

That download is complete trash, I just assumed since I always used that page that the downloads were quality and not corporate bloatware.

I am sorry.

When I release Build 1010, I will be updating the Mark V page with 2 proven reliable codecs (Google WebM) and the *real* XVid minimal (fast as hell).

On a positive note --- 2 Windows 10 machines --- capturedemo runs with flying colors with a proper codec installed.

/Why do some machines --- using Quake 11025 sound hz sound terrible and need 44100 just to sound ok? While other machines original Quake 11025 sounds just fine? Peeve of the day. 

Not exactly, haha. Read the "Mac Version Based On Fruitz of Dojo" on the Mark V page.

They invented it ages ago (2002?). It's a wicked idea and I've always liked it. 

I'll check it out. 

I wrote engine tutorials on demo rewind once and made working examples. qbism used it as reference to add demo rewind in Super8.

In Mark V, I went a bit obsessive and redesigned the FitzQuake 0.85 animation interpolation on just the client side to be completely reversible.

/Let's just say I like demo rewind 

Can't reproduce. I used vid_hwgamma 0 and did several different things with ALT-TAB with maps running.

I use Alt-TAB and ALT-Enter all the time.

Does happen with clean install? What map is running? What mod is running? What does the Dr. Watson report say is complaint (if that applies in this case)?

I don't know too much about the internal wiring of the Direct3D wrapper.

Something to keep in mind, may or may not apply here, the Direct3D wrapper has been in use for ages in ProQuake (and it got a lot of use for "Open GL crashes/bad drivers"). I think I always kept the -gamma texture command line parameter allowing opt out of hardware gamma.

I'd recommend "developer 2" and then upload qconsole.log and maybe I'll see something. What I do know is this ... if vid_hardwaregamma 0 is in config.cfg and you start Mark V, Mark V never so much as touches system gamma even once.

Does this happen when you start game in id1 when there is already vid_hardwaregamma 0 in quake\id1\config.cfg. 

In windowed mode, with vid_hardwaregamma 0 and gamma set, I can't think of anything obvious.

Windowed. ALT-TAB little different than using the menu or pulling up the console except the loss of keyboard focus. On Windows in really rare situations. Do you have 2 copies of Mark V open? I could possibly see something as possible there, yet I've done that a hell of a lot.

Fullscreen. There are more potential things that could happen with ALT-TAB. Are you connected to fvf.servequake.com or running -FVF or can this happen with clean id1? As far as I can tell, in fullscreen mode it would always need to reload all the textures ... and this means recoloring all skins and external textures too. I've not had a problem thus far, not even connected to FVF an hour ago trying to cause a txgamma + DX8 + ALT-TAB crash and I was doing game -FVF for thoroughness.

/But you say this happens in windowed mode. It doesn't need to reload textures or recolor skins or anything in that scenario. 

This sounds like lost device handling somehow got broken.

In D3D terms, a "lost device" is what happens when you Alt-tab away from a fullscreen mode, but it can also happen under other circumstances (power-saving transitions, etc) and Microsoft don't document them all - primarily because it's actually impossible to (3rd-party software/drivers/etc may trigger a lost device for internal reasons of their own).

Changing Windows gamma while running in a windowed mode sounds like one of those other circumstances. Changing the screen resolution while in a windowed mode would be another.

The important take home is that naively detecting if an Alt-tab has happened is the wrong way to go about this. Instead you check the HRESULT from your Present call, if it's D3DERR_DEVICELOST you issue a bunch of TestCooperativeLevel calls until you get D3DERR_DEVICENOTRESET, then you release all default pool resources, Reset the device, then issue another bunch of TestCooperativeLevel calls until you get D3D_OK at which point the device is no longer lost and you can recreate the default pool resources.

Typically you'll get a crash if there is a default pool resource not released (more typically the Reset call will fail).

Hopefully that's sufficient info for Baker to troubleshoot. A good test to reproduce might be, like I said, try changing the Windows display resolution while running in a windowed mode. That should trigger a lost device, then trace through the code with breakpoints on the TestCooperativeLevel and Reset calls. 

MH: Hopefully that's sufficient info for Baker to troubleshoot.

Baker: Gunter ... MH say "don't play with Windows gamma control when DX8 version running."

He also say for best laptop maintenance, you should run laptop through dishwater once a year to clean keyboard. 

The drivers I have on Win 7 don't seem to care if I play with the gamma in Windows while DX8 is running. Fullscreen or windowed, vid_hardwaregamma or not. 

I even changed the video mode in Windows after ALT-TAB out of dx8 both in windowed and fullscreen -- it didn't care at all and continued on.

My DirectX drivers would be quite different on Windows 7 vs. Windows XP, I would imagine. 

Ok, more testing.

Started Mark V DX clean, no config.cfg, no external anything. It defaults to a 640x480 window, and the standard demo starts playing (though I find if I stop the demos this behavior doesn't change). Then I click away from the window and adjust my windows gamma = crash. Dr. Watson says "Access violation." If you can tell anything from this, the chain of things Dr. Watson lists are:

dx8_mark_v.exe - iglicd32.dll - igldev32.dll - uxtheme.dll - etc.

Last couple lines in qconsole.log:

Accessibility keys enabled
Hardware change detected ... Gamma system set

But those things happen as I switch focus away from the window.

Repeat experiment with GL version = no crash.

Repeat experiment on older WinXP laptop, and no crash, but I notice a difference -- on my Netbook I am using a system tray icon that lets me select a pre-saved scheme for my gamma (and probably other settings). When I apply that, the whole screen flashes black for a moment. My older WinXP laptop doesn't seem to "Reset" everything like that when I just adjust the gamma. And I find that if I actually go into the video control panel on my netbook, I can simply adjust the gamma slider without anything bad happening too....

So it's not really gamma, but when my display settings get... "reset."

I find I get the same screen flash + crash if I alter my color depth or resolution (yep!).

Doing all these things on my older Win XP laptop = no crash.



Now for alt-tab in full screen testing.... I'm finding that now any alt-tabbing of fullscreen DX (not the more specific circumstances I previously mentioned) is crashing it.


And once again my older WinXP laptop handles it fine, as does the GL version.


So it seems that my netbook is doing some kind of harder reset of the display settings perhaps? Along with that stuff mh said. 

Small chance that if you turn off Themes in Windows XP, may avoid the over-protectiveness.

http://www.pcauthorities.com/windows-xp/disable-themes-in-windows-xp/