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
Addendum 
Another reason for the subtle fog in custom Quake maps is to disguise the fact it's not spherical. Thick flat fog looks bad when turning the camera. 
Transparency In WinQuake 
I've done some more testing in Mark V WinQuake and turns out the water/teleporter transparency (r_wateralpha) actually works, via dithering. I suppose the same effect could be applied to the fake fog layer in ad_necrokeep. It just seems like the engine has no support for alpha channel in textures, e.g. various trees and vines in AD and Jam 8 are broken, with solid white where they should be transparent. 
 
Put these guys in the maps folder and you'll have transparent water on the stock id1 maps

External .vis files for original Quake maps

They should work in DarkPlaces as well.

The original Quake maps don't treat water as transparent.

Alpha masked/alpha transparency doesn't work in the WinQuake version for brush models at this time (tried it maybe 4 different times, something I'm not understanding about the WinQuake depth buffer or draw process prevents me from getting the job done in this case.).

It actually works for .mdl models, but few maps use that although it might be visible in Arcane Dimensions in some cases. 
Baker 
Alpha masked/alpha transparency doesn't work in the WinQuake version for brush models at this time (tried it maybe 4 different times, something I'm not understanding about the WinQuake depth buffer or draw process prevents me from getting the job done in this case.).

The BSP renderer sorts depth by edge at the spans level, rather than at the pixel level. To avoid this, I've tried partially reinitializing the BSP renderer upon rendering each alphamasked BSP surface, but this resulted in massive slowdowns. Now I only reinitialize it once for each BSP entity containing alphamasked surfaces. Qbism did something similar in Super8, IIRC.

Quake's spans-related code needs a lot of work. It's non-intuitive and has bugs such as this.

I don't fully understand it yet either, but I'm sure the reinitialization overhead can be eliminated almost completely. I should only manage to do so after fully rewriting it, though. 
@mk 
Thanks for the link. Looks like a good read.

I had determined that some sort of reset was required, but either I did it in the wrong place or performed it incorrectly. Or the third possibility of something I am not considering and wasn't on my radar.

Some day in the future I'll make another attempt. Last time I almost got "serious" (I was piece by piece reimplementing qbism super8 in WinQuake until I isolated what I didn't understand), but then something more shiny to me pulled me away (probably something Spike did in Spiked Quakespasm like single port server).

Network code to me > everything else ;-) 
 
One more thing, does WinQuake Mark V support any kind of HUD scaling? Integers like 2x, 3x etc would look quite good even in software rendering I'd wager. The usual scr_*scale commands don't seem to work. 
 
In the video menu, stretch is as close as it comes, emulating 320x240 or 640x480 as best it can depending on your current display mode.

It isn't exactly the same thing as scaling the HUD, and for most people it is probably "good enough" -- although as a purist I don't feel it is good enough.

But since it would be quite time consuming and effort to implementing true scaling (aka FitzQuake) in the software rendering with the appropriate alpha masking support, such a thought sits somewhere closer towards to the back of list rather than the front.

Keep in mind a trule scaling solution needs to handle all 2D graphics like the menu, scoreboard, etc. otherwise it would be quite silly. 
 
Hmm, seems like the original renderer is pretty limited.

For the record, I've tried Qbism, and it does have HUD scaling and alpha channel support for textures, but I get heavy FPS drops in Arcane Dimensions, when there are any alpha channel textures in my line of sight.

Could we do this another way around and emulate the original paletted 8 bit look in OpenGL? In particular the lighting color map. 
Crash To Desktop 
....on trigger_changelevel - is this a known issue or could it be my map?

https://drive.google.com/file/d/0B-xkqcrQhLm7Z3RVeVZZUFdwVlE/view?usp=sharing

It's happened multiple times and on demo playback as well. 
@iniyap 
I know exactly how do it. It isn't a question of that at all. The question is, of the things I can do, would I find that interesting enough to want to do before the 25 things that do interest me. If you understand.

Ask Spike or mh or ericw or metlslime or qbism or mankrip, part of an engine coding for a leisure activity is wanting to do the task.

@dumptruck_ds .. don't know. If it progresses to become a released map, I'll make a mental note of it after it is confirmed it doesn't crash any other engine. 
@iriyap 
paletted look with gl = fte with r_softwarebanding 1 (or just use the softwarey preset). 
@Baker 
re: the map. tested on Quakespasm-admod last night and it was fine. I will do some further tests with other clients this evening and report back but for now at least that engine behaves as intended.

My trigger change level is made up of some weird shapes as you can sort of see in the screenshot. Not sure if that could be a cause or not. 
Baker 
it seems the tool_inspector is broken on your latest release v36

also i've got a new video card gtx1070, and noticed a very weird video gliches with the fog enabled

there's no such gliches if i'm using quakespasm engine tho 
There Ain't No Gliches Either If I'm Using Dx_9 Engine 
*glitches 
 
@spy 
Yeah, Pritchard reported the tool inspector issue a while back and then a couple of others later on.

I saw the glitching in your video. Could you give me "viewpos" coordinates and map name (or as an alternative the demo which gets me the same information).

I'm guessing since it only happens in certain frame, it occurs when a lavaball pops into view.

Quakespasm and Mark V and Mark V D3D all draw very differently, so the different behavior isn't unsurprising.

I'll make a note to try to recreate the next time I have my hands on a NVidia card machine. Since NVidia updates the drivers all the time, it is a possibility that this is a driver issue that will go away in a future driver update, but I'm not going to make that assumption.

Thanks for the high detail issue report. 
Yeah, After I'm Getting The New Card 
i've updated nvidia driver to the latest version

this glitch is only happens when the fog is enabled, disabling the fog removes the problem
would you mind if i'll send the map
to your mail? 
 
Spy, you know I think you are awesome.

I am email free! And I love it!

If it needs to be done privately, I guess you could send a private message at QuakeOne.com. 
Baker 
i cannot reach you at QuakeOne.com

btw, fitz08, has the very same issue 
 
I deleted some private messages over there, you can try again (but really since they upgraded the forum there, I don't know if that was problem or not) or upload to Quaketastic.

My gut instinct is that I think this is a driver issue that will magically disappear at some point once nvidia does an driver update or 2 on your machine.

They probably introduced some sort of stencil bug they introduced since ...

1) It doesn't happen in Quakespasm which doesn't use stencil by default.

2) It doesn't happen in the Direct3D version.

3) Didn't happen on your previous machine, no one else has reported a glitch like that. 
 
Hello, it's me again. :)
I've tried out a few older versions of Mark V, and the problem is still the same.

Now I'm starting to think that it's definitely up to my hardware. Certainly my GPU, because the drivers are so poor. Yes, the latest ones are from years ago.

In the near future, I might install modded drivers to see if it helps. Intel GMA 965 is a special snowflake among the 9xx series, haha. 
@Admer 
You might try the sdl_mark_v_gl.exe in this beta ...

http://quakeone.com/markv/builds/1025_mark_v_beta.zip

Will it work? Who knows!

Had several beta testers with really, really bad/old computers, some which can't run Open GL but the Direct3D works and getting terrific fps.

Worth a shot anyway. 
 
Yes, the Intel 965 is pretty damn special - it was Intel's first hardware T&L part, the drivers are absolute cack and the hardware itself is actually slower than the prior (software T&L) generation.

As far as I'm concerned: weirdness, crashing, general bad stuff - that's expected behaviour under OpenGL with this part. 
 
I've tried out the SDL .exe, and just as I thought...

There's no hope. My GPU is the lottery in terms of incompatibility. :P
I'm not giving up yet, though.

I'll just wait until I build my new PC by the end of this year. Modern hardware will definitely handle it better. :) 
1036 Is Giving Me Problems 
Wonder if anyone else is having issues running it. I'm testing a map so haven't had time to really document things but it seems to stutter quite a bit after running for a few minutes. Can't even finish a play-thru.

Before I dive into reporting wondering if anyone else is experiencing the same behavior?

SO far it's just the main mark_v.exe

dx8, dx9 and winquake are behaving. 
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.