Download at normal location:

http://quakeone.com/markv

Changes
1) Removed all the internal testing commands except "dir" (c0burn).
2) DX8 build: equivalent .alpha appearance for .mdl (gunter)
3) sv_gameplayfix_setmodelrealbox 0 improved for Malice (dwere)
4) Sprites like E1M4 bubbles are now lerped (gunter).
5) QMB bubbles should behave like normal bubbles. (gunter).
6) Autosaves are named auto_save_0.sav to 2
7) GL/DX8 version can do -dedicated again ok.

/Typing "version" in the console will show as build 1008.

@metlslime - the more sprite examples the better. ;-)

@gunter - Pay close attention to sprites and if you could, could you give the WinQuake build a look too. I don't expect problems, but without a lot of live testing, I'm always suspicious of any change.

@dwere - This Malice multi-part model on d8 map is a great compatibility test case. First example I know of where FitzQuake bounding boxes cause unwanted culling. It is extremely rare and due to that, hard to find any examples at all. Conversely, Mark V WinQuake adopted FitzQuake bounding boxes as part of first version because it solved a glitch in the X-Men mod where items disappeared if you stood in the right place.

sv_gameplayfix_setmodelrealbox ...
0 - WinQuake (-16 xyz to 16 xyz)
1 - FitzQuake (measure model, default)

For Malice, set sv_gameplayfix_setmodelrealbox 0 before loading a map or save game and everything should be great with any multipart models.

Next update will contain:
1) Alpha channel support for 2D replacement textures, current support is alpha mask only (yes/no).
2) Rewire QMB to be more consistent with particles and be able to turn precise particle behaviors off. (+ alpha channel issue with txgamma) 

4) Sprites like E1M4 bubbles are now lerped (gunter).
5) QMB bubbles should behave like normal bubbles. (gunter).


Uhhh, the first thing was never a problem. It was ONLY the qmb bubbles that were being weird. All other sprites were always fine and smooth-moving. So I don't know what you fixed, but you might wanna un-fix it to be safe, heh.


The second things is definitely improved. The qmb bubbles now move smoothly, BUT the "sometimes invisible" issue still remains. I tested on the actual server and in the previously-recorded demos I made. So, if you watch bubble3.dem now with qmb bubbles, they will move smoothly. But with bubble1.dem you will see no bubbles at all....

This is a tricky one. All I know for sure is that if the level has been running for a while, the qmb bubbles are no longer being drawn. Resetting the level brings them back.... I'm going to try this locally by leaving Quake running for a while to see if it is just an issue when connected to a server.


Hm, things now render transparently no matter what the gl_overbright_models setting is, BUT now gl_fullbrights affects them the same way:

gl_fullbright 1 = most weapons opaque (not axe) unless using custom textures (must be as metlslime said, and the custom textures don't contain fullbright pixels). Illusionary ent guy is also opaque.

gl_fullbrighs 0 = everything transparent, including illusionary guy.



Also, toggling external_textures does not affect sprites (like the bubble and light ball sprites in id1\progs\) until level change. 

Mmmkay, verified: after running a map for 35-40 minutes, qmb bubbles become invisible.

Tested on e1m1 and reproduced. Go stand by the mega health and jump in the water and drown a little bit. Watch your QMB bubbles pop out and float above you.

Now sit there and idle for 40 minutes... You don't need to do anything else in Quake. Now jump in the water and drown a little more, and you won't see any bubbles unless you disable the qmb effects.

Oh, you don't wanna sit there for 40 minutes to test this? No problem! Just set host_timescale 100 or 1000 and run the clock up to around 40:00 and you get the same result!

Isn't that weird?

Ah, it's easier to test by going to e1m4 in single player, noclip, notarget and go stare at the bubbles underwater. Mess with your timescale.... I have found that the qmb bubbles go away like clockwork at: 34:08


QMB Bubbles: "This level is taking too long! I'm outta here!" 

34'08" = 2048 seconds, or 8*256. Sounds like a pretty significant number to me. Does it give you guys a clue? 

Ooo, good catch. I never would have considered that.

Hmm, I have no idea what the engine code looks like, but just making a complete guess, perhaps if there is some property of the qmb bubbles being set by:

time / 8

then once time gets to 2048 or higher, that calculation produces a number of 256 or greater, and that might be "our of range" for some Quake calculations....

Like particle color generally ranges from 0-256, but it wraps around so that 256 is treated as 0, 257 as 1, etc. 

Temp Build before I continue trying to clear queue ...

http://quakeone.com/markv/mark_v_1009.zip

- DX8 .alpha fully addressed now?
- Removed sprite lerping, since it produced no rendering difference.

/Temporary middle point before build 1100 

@gunter - Live toggle of sprite textures --- would be too time consuming (15 hours), mostly because I never thought of sprites when writing the live external textures toggle. Maybe someday.

I'll see what is going on with 34:08 too, while I'm getting QMB pacified. 

The scr_showpos 1 crash on startup has returned....


Hm, I have to set either gl_overbright_models 1 OR gl_fullbrights 0 to get transparency.

And the transparency looks very different depending on which one I set. With gl_overbright_models 1, no matter the fullbright setting, things look much less transparent.

Hm, yeah, it's like the gl_overbright_models 1 effects is being drawn on top of the gl_fullbright 0 effect.


On the positive side, I like having all the exes in only one zip file to download, instead of separating them like on the Mark V web page ;) 

scr_showpos 1 crash on startup has returned

Are you sure? Can't reproduce. Does "version" say build 1009?

If you are getting it, what method are you using to set it? Did you add to command line or autoexec or config.cfg? 

I think you packaged an older version, build 1002.... 

The difference between different combinations overbright_models on/off or fullbrights on/off doesn't relate to the model drawing in 1009.

It is a difference in how the map itself is draw, and what draw method is being used for drawing the map.

And gl_fullbrights affects what rendering path is used for the map.

The .alpha entity looks the same, but what it is drawn over is slightly different. 

Ok, real Build 1009 in the zip (instead of 1002, however that happened).

http://quakeone.com/markv/mark_v_1009.zip 

DX transparency is all good now!
And consistent no matter what combinations of settings I use. 

Awesome. I wanted to permanently bury all the small items before reworking QMB some because it may be slightly complex. 

I just wish there was some way I could make use of transparency.... Such a cool effect, but mostly unused. 

{Fence texture based low-lying fog for graveyards. 

I think it's cpu related.

Also, the stuttering doesn't occur at relatively regular intervals like I first thought. Generally, the more action taking place the more laggy it gets. Sometimes, the game will launch in a laggy state and have to be restarted.

Also, I have it capped at a 60fps (72 felt like 15).

All software/hardware cpu power management settings, c-states, EIST, turbo mode, etc. are all disabled. Disabling OS core parking helped quell the stuttering, but it's not a total fix. This is on a 4790k at stock speeds. 

On your beastly machine, it's only input lag right? I might be able to do something about that if it is just input lag. 

Frag me --- that download I linked for the codec pack is 983 MB of bloatware + cruft + corporationary non-sense.

It wasn't like that a couple of years back.

Going to link a codec pack is **just the damn codec ***. 

input does lag somewhat when the stuttering occurs, but that isn't the main issue. visually, it looks like frame loss (like down to 10-20fps or so) but the fps counter doesn't budge. I've also experienced total loss of sound on one occasion, I don't know if it's related. 

And on this Windows 10 laptop I'm testing this out on, it doesn't even make the codec available as far as I can tell.

What nonsense. 

What does the Open GL version do? If the Open GL version doesn't have this kind of issue and the WinQuake one does, that tells me something.

Huge difference on how they update the screen.

On the Mac version of Mark V, it actually uses the Open GL method of drawing in the software renderer. 

no issues withe the gl version. Also, the stuttering occurs when viewing demos as well, this might rule out input being the culprit. 

Sounds like the buffer transfer of WinQuake is the culprit. What's your display resolution? 

1920x1080

I didn't mention this earlier because I have to do more testing, but the screen stretching may have an impact... or maybe it's more obvious when enabled, I'm not sure yet.