Binaries still work on KDE without need for re-compilation.

The laser effect is neato -- kinda like they're being squeezed out of the gun. Would make for a decent "shooting star" effect. Might be nice if they could be toggled off for the player (like the FVF Laser Android class), while still being enabled for the enforcer. But not a big deal *shrug*

Winquake crashes (seg. fault) when I try to drag-expand the window too much. Appears it may be trying to snap to fullscreen (like a snap-to-edge behavior). That doesn't bother me, though, cos I likely won't be using Winquake, and that's an easy situation to avoid anyhow. Otherwise runs fine.

Anyhow, please ignore that until the spring. And thanks again for bringing Mark V to Linux. I will enjoy playing Quake with it in the meantime :) 

I had the same reaction as Gunter that the GL waterwarp effect has a surprisingly strong distortion. I guess I was used to running WinQuake at a non-minimum resolution back in the day.

It's not a big deal, but out of curiosity: how feasible is it to expose "warp amount" as a console variable? 

how feasible is it to expose "warp amount" as a console variable?

There are a few hard-coded numbers in it and I even have a comment on one of them: "tune it or cvarize it all you wish".

I'm actually working over this code at present fixing up a few issues with it, but I don't feel that I'll be the one adding cvars: it's really up to Baker, how or even if he wishes to expose this. 

Hm, yeah, the FvF Laser Android uses the same laser-firing function as enforcers do, but apples various flashing colored skins to the laser projectile.

The QMB effect now has every Android laser shot look just like the enforcer's laser.

And it really hits my FPS when firing the Super Spread Laser (8 simultaneous laser shots, heh).

It's too bad the effect color can't be made to match the laser skin color....
I suppose a quick hack (which I'm not at all sure how it would end up looking, since the Laser Android does use the standard laser color too) might be to only apply the QMB effect if the laser projectile is using its default skin 0.

Or I suppose have the effect only apply if launched by an enforcer, as JimBob suggested.

Though I always thought the laser android could use some kind of QMB-type effects too (when such things are enabled).... 

OK, I'm pretty much done working over the code. It's a shame I didn't get this in time for Baker's release, so you're just going to have to be patient until his time frees up again.

Picked up the latest vkQuake code adjusting the water warp for screen aspect. Yes, my water warp code was based off vkQuake.

Made it as close to consistent as I can get with Mankrip's tests at http://forums.insideqc.com/viewtopic.php?f=3&t=5827

Mankrip has criticised the vkQuake code before, but I think he's being unfair. vkQuake is actually 99% there; the only things it needs are a sign-flip ("(x - (sin (y" instead of "(x + (sin (y", likewise for y/x) and a tweak to the value of AMP (2/300 instead of 1/300).

This is not based on any rigorous code analysis, just tweaking values until it looks right, but it's close enough for me.

Mankrip's: http://www.quaketastic.com/files/misc/testing/waterwarptest_Retroquad_1280x960.png

Mine: http://www.quaketastic.com/files/misc/testing/waterwarptest_DirectFitz_1280x960.jpg

There's a bug where if you change resolution when underwater, water textures get turned to binary garbage. Don't bother reporting it - I'm aware of it. 

Oh my.... The Ninja also uses the laser model (skinned) for his throwing darts, heh... and now they look like laser effects in QMB. 

for some reason waterwarp in both opengl and directx seems to be down-ressed? is that correct? 

Yes, I downscaled it.

This is essentially the same kind of problem and same kind of tradeoff as we have with shader gamma. Because it needs to run as a post-process it's slower, so I downscaled it to compensate.

It's a no-win situation because if I didn't downscale it people would complain that it was slow.

My expectation is that cvars could be provided to tune the size, so that you could select downscaling or not, based on your own preferred tradeoffs (and hardware capabilities). But that's not my decision. 

For comparison, this one is full res: http://www.quaketastic.com/files/misc/testing/waterwarptest_DirectFitz_1280x960_noDownscale.jpg 

on my gtx 970 

Just kind of a note, anything that MH wants to do will end up being added to the engine when new builds happen again.

@gunter - if I would have known about the fullbright pixels + alpha, I could have coded a temp workaround.

Spring will be here before you know it. Time flies. 

@Baker: twas reported above in #977 and verified by you in #978 ;)

I might have mentioned it again, but I was waiting to see if it would be resolved along with other transparency issues that were being worked on.

It's not a big deal in any case.


I would request that you make the most recent zip package available on the site at quakeone.com/markv since that's where I always send people to download it. The link here will quickly get lost in the posts on this page.... I know it's "beta" but it's still the best version so far, containing numerous fixes.... I also like having all the platform versions in one zip file. 

Ok, I see you did link to here at the top of the page on Quakeone.com/markv ... though the link doesn't take me directly to the post to download it. A direct link to the zip file would be convenient. 

Is it me, or are monsters sort of transparent to the sky?

Like if I look up through a monster at a sky brush, I can see the edges where the architecture meets the sky.

http://imgur.com/a/hTQnc

Not sure if I have some setting enabled to make this happen. 

Hopefully resolved the remaining significant issues, like dwere's context creation failure message.

The message is still there, I'm afraid. 

Verified: you can see the sky (kind of) through monsters, starting DX9 1.28

You can also see shadows through monsters, if r_shadows 3 

@dwere ... Grrr. That's going to annoy the hell out of me for a couple of months. Sorry :(

@gunter ... I did an update to the page including the installer.

I am sort of mixed on doing that considering that dwere, as an example, has an issue and I'm a compatibility hawk and that's like a having a thorn in my boot.

On the other hand, the current build solves compatibility issues on the other side of the spectrum (killpixel, johnny law, pulsar's machine presumably).

/Grumpy cat face!

I'll read the comments every once in a while, all feedback gets read, this Func_Msgboard is awesome in how the layout is conducive to that. 

I suspect you're actually using an older build.

In all of this I'm assuming that you're using DX9. In the most recent code I provided a replacement ChoosePixelFormat that never fails. I need to cross-check the MarkV integration of course, but it seems you're describing something impossible. 

Shadows through monsters with r_shadows 3 is a known issue, that's part of what I meant when I said "it's not robust" and "shadows leak through geometry".

If it can be fixed it will. If it can't be fixed you'll have to take it in the spirit of Carmack's original comment on GLQuake's novelty features: "not very robust but cool to look at". 

Let me know if these work and/or what happens.

http://quakeone.com/markv/older/1033_dwere.zip (Open GL, WinQuake version).

If it solves your problem, I'll have a lot more piece of mind.

Let me know! 

He was using mark_v.exe --- the Open GL.

In the above 1033 dwere test, I did 2 things:
1) I requested a 32 bit Z-buffer and an 8-bit stencil to mirror what Mark V 1.20 did. In later versions, I changed to Z-buffer request to 24-bit with 8-bit stencil.

2) Mark V Open GL will route around an opengl32.dll living the Quake folder, largely to avoid the GOG.com crappy one and the fact that a opengl32.dll in the Quake folder is almost always some 1997 relic.

If that is what is going, the dwere build will do a messagebox saying that's what's up. 

Interesting screenshot. 

Hm. it gets more interesting....

If r_shadows 3, then you can no longer see the sky through monsters. But that's when you can see shadows through monsters. It's not just shadows leaking through anything -- you can see the shadows through the monsters at a distance, in a very similar way as you can see the sky through the monsters when not using r_shadows 3....

I would suspect a relation, since both these issues appear starting in DX9 1.28, when the new shadows were added.... 

Yeah. Really I think it's more like the sky is shading the monster, rather than the monster actually being transparent to the sky. Er. It's confusing. 

Shadows & sky is an understood problem.

Both have weird interactions with the depth/stencil buffer, and are therefore interacting with each other.

Fixing individual problems as they occur is not going to solve this, so everybody - please stop reporting bugs with it.

I know what the solution actually is, and it involves decoupling the shadow pass from the MDL passes so that the former can be done in isolation and without affecting other stuff, then figuring out the correct draw order placing for it (which will be one of two options).

If you look upthread you'll see that I already said this, but in a bit less detail.

Right now giving me the head space to actually do this is a lot more helpful than piling on the bug reports.