News | Forum | People | FAQ | Links | Search | Register | Log in
Mark V - Release 1.00
http://quakeone.com/markv/

* Nehahra support -- better and deeper link
* Mirror support, "mirror_" textures. video
* Quaddicted install via console (i.e. "install travail")
* Full external texture support DP naming convention
* Enhanced dev tools texturepointer video inspector video
* IPv6 support, enhanced server capabilities
* Enhance co-operative play (excels at this!)
* Software renderer version (WinQuake)
* "Find" information command (ex. type "find sky")

Thanks to the beta testers! NightFright, fifth, spy, gunter, pulsar, johnny law, dwere, qmaster, mfx, icaro, kinn, adib, onetruepurple, railmccoy

And thanks to the other developers who actively provided advice or assistance: Spike (!), mh, ericw, metlslime and the sw guys: mankrip and qbism.

/Mac version is not current yet ...; Linux will happen sometime in 2017
First | Previous | Next | Last
Mark V - Beta Build 1032 - Windows / Linux / Direct X 9 
Mark V 1032 Beta - Windows, Linux, DX9, DX8, Open GL, WinQuake

Source Code

Features Vs. Mark V 1.2

- Very fast "triple the fps" DirectX 9 build courtesy of MH
- WinQuake looking water warp in Open GL/DX9 (MH again)
- Volumetric shadows - r_shadows 3 (MH again)
- Sky speed up in Open GL/DX8/DX9 (Yeah, MH)

- Linux Open GL build (thanks to JimBob for testing, Spike for debug tips)
- Linux WinQuake build

- Resize on-the-fly windowed mode in all builds (except DX8). Yes, even Linux. Tried to make the Linux build fancy. May have succeeded.

- QMB enforcer lasers available video

- Improved performance on NVidia cards
- 2 Extra options in video menu for convenience.

- Other things, no doubt. But what were they? Scroll back in the thread ;-)

Hopefully resolved the remaining significant issues, like dwere's context creation failure message. Attempted to add texture gamma to DX9 and then ended up with a blank screen and plenty of wasted time, killing the opportunity to add true rotation and even get the Mac build running. :(

Engine coding sucks like that sometimes, but I won't pretend to not be irritated about missing a few items I very much wanted to get done.

/All feedback and any issues reported do get read.

Next update is likely in the spring. 
 
In DX9 only, models with fullbright pixels still can't handle transparency (like an illusionary player model, or the gun view models except axe). gl_fullbrights 0 makes them transparent again.


Hm, there is still a big difference in the water warp effect in the Winquake version as compared to DX & GL. The Windows one just doesn't warp as much, and is less noticeable. 
Waterwarp - Win Vs DX/GL 
Software Quake waterwarp is resolution-dependent. Run it at 320x200 and you'll see a very different effect to if you run it at higher res.

The waterwarp code I wrote is resolution-independent.

IMO the software Quake behaviour is undesirable.

More discussion, test cases, etc here: http://forums.insideqc.com/viewtopic.php?f=3&t=5827

You'll notice that my warp code reverses the X-axis direction but is otherwise good. That's something I intend to fix some day (the X-axis bit, not the otherwise good bit). 
 
Ah, I see. I agree about the undesirable part. 
1032 On OpenSUSE W/ KDE 
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. 
Mankrips Looks Better 
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. 
 
Would Be Interesting To See What The Hit Is 
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. 
MDLs Transparent To Sky Edges In GL? 
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. 
@dwere 
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. 
@Gunter 
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". 
@dwere 
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! 
@mh 
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. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.