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
 
hlbsp has licensing issues from its toolchain, and the hull size issues makes it generally unusable for quake anyway.

besides, lit files and (same-size) replacements provide all the same advantages and with well-defined compat fallbacks, and without shamblers ending up half-inside walls, and retains overbrights, just with more files (unfortunately).

if really needed then the -bspxlit arg can be used to embed the lit files, and -notex can be used to force external/replacement textures using the same mechanism hlbsp uses for external textures (so should work in the same engines) including support for q1 or hl miptex from a texture wad. 
How To Make A Video In 45 Seconds Expending No Effort 
How To Make A Video In 45 Seconds Expending No Effort ...

0. Do once: Install XVID codec 11 MB. This isn't about the codec, this is about something that works quickly and doesn't come with ads/spyware.

1. Go to a map.
2. Type record thisdemo
3. Walk around for 30 seconds.
4. Type stop to end demo recording.
5. Type capturedemo thisdemo

Your are done. Where is thisdemo.avi? Type folder and it will be highlighted in Windows Explorer.

6. Optional: Drag and drop it on your YouTube page and upload it.

If you are in 640 x 480 windowed mode when typing capturedemo it will be faster than say fullscreen resolution @ 1400 x 900 because 640 x 480 has far less pixels to encode than 1400 x 900. 
 
"Anyone else using Windows 10 have issues with the engine? "

Not so much in MarkV; but QArack, and JoeQuake specifically take 10 to 15 seconds to initialize in win 10 for me. Where as both engines take under 5 seconds on my XP and win7 machines. Dunno. opengl 1.x emulation? 
@Baker 
I can confirm that startup on Windows 10 is extremely slow on my new tower. I have an Intel 7820 and 32Gbs of RAM. HD is a pretty decent raid from 10,000 RPM drives. Videocard is a Nivida GTX 780.

In Windows 7 - a much older machine startup is near instantaneous.

No audio issues as I have seen on my laptop thankfully.

Is there any way I can help observe/record the startup issue for you? 
@dumptruck 
1. Is it just the Direct X version?

2. Or is it also true for the WinQuake version also?

3. What about the SDL alternate build? download

It might help me triangulate in on something. 
@Baker 
I'll test this evening and post results. I probably should have done a proper test.

Also a question about Dx9 files you have linked? How do I determine if I need those? 
2x Post 
Sorry yes I was setting up TB2 and only played around with the DirectX version as well as QS and QSS. I'll copy over the SDL alternate and WinQuake versions this evening. 
 
> How do I determine if I need those?

Great question!

Mfx said he had the issue and said installing those files solved it, but I'm not seeing a description of the message other than "it didn't start up".

Posts 2106, 2109, 2110 -- "mfx - Thx, that download helped, works now." 
 
Yeah Mark V needs the DirectX 9 runtime support. I don't remember the error message but IIRC it's fairly obvious if that's why it's failing to start.

If you play other games on your computer there's a good chance you already have this installed. If not, it's harmless to install it. 
 
In the future, I may try to roll DX9 detection/installation into the installer form of the engine distribution.

There will of course always be the plain zips of the engine .exes. 
@Baker 
Report on Mark V Windows 10 delayed launch (and exit)

Mark V 1099r4 delay of 3-6 seconds launching and exit.

mark_v_sdl_gl_gcc - no delay
mark_v_winquake - no dleay
mark_v_winquake_gl - no delay

quakespasm .93.1 win64 - short delay launching and exiting (1-2 seconds)
quakespasm-spiked-win64 - short delay launching and exiting (1-2 seconds)

Mark V 1099r4 has the longest pause of all exes. 
@dumptruck 
So DirectX Mark V is 3-6 seconds slower starting/exiting. Quakespasm is 1-2 seconds slower starting/exiting.

But Mark V WinQuake, SDL and OpenGL are unaffected.

Trying to unravel that ...

It is possible that specifying a refresh rate on startup slows things down. Quakespasm does this. DirectX Mark V specifies a refresh rate that is the desktop default when requesting fullscreen mode. The Mark V WinQuake/SDL/OpenGL doesn't touch refresh rate.

If I am right ...

Does the following have a difference in start up times ...

a) c:/quake/mark_v.exe -window -width 800 - height 600 // DirectX
b) c:/quake/mark_v.exe -current // DirectX

If it relates to the refresh rate, according to the code it looks like in windowed mode that Mark V DirectX does not set a refresh rate, but for fullscreen mode it does.

/A guess. If this thought turns out not to lead anywhere and it may not, I have a couple of other thoughts but this best matches your test results ...

Let me know ... 
 
If a 6 second delay is a problem, my engine is fucked.

But yeah, it's always nice to eliminate unnecessary delays. 
 
A delay at startup does sound like it's changing the display mode for sure; that would certainly do it.

Some info on command-line params used and resolutions of the PCs being compared would help a little more here. 
Specs 
@baker I need to try this in windowed mode too. But I'll try what you posted above. Typically I stick to fullscreen.

One other thing that might help. Much of the time I am editing and using Necros' GUI to launch ericw's tools and in turn, MV. The tools compile quickly as expected, then there's the delay in launching MV. Then I review the compiled map. Now for whatever reason after I quit MV the cmd windows (which has been running in the bg as usual) stays up for about 3-4 seconds before closing.

I am 99% sure the delay in launching MV happens if I click a shortcut on the desktop without running any compilation so maybe unrelated?

@mh

Just remember this is Windows 10 now. My older machine is Win7 and had zero issues on start up and shut down with the same monitor and a very similar video card and same MV version. Also the same command line etc.

1920x1080 144Hz refresh forced by nvidia cp and that's my desktop res and refresh as well so I don't think it's mode switching.

I need to confirm but I'm pretty sure the delay happened before I set the refresh in nvidia to 144Hz

parms are +developer 1 and +gl_clear 1 +load map <map I am editing> (those were the same on other systems) 
 
It does seem to take a while to load for me too. QS is pretty instant 
 
Much of the time I am editing and using Necros' GUI to launch ericw's tools and in turn, MV.

Windows programs inherits the CPU affinity and the process priority of the process that launches them. If the launcher is e.g. a single-threaded 32-bit program running at low priority, maybe Mark V needs some extra time to adjust its process' properties. Just a guess. 
@Baker 
Home and testing this now. We're getting somewhere.

Does the following have a difference in start up times ...

a) c:/quake/mark_v.exe -window -width 800 - height 600 // DirectX
b) c:/quake/mark_v.exe -current // DirectX


No delay on the windowed setting above! Fires right up. Also I have QS and QSS in the same forectory of MarkV so they share config.cfg. I'm noticing if I switch between those two the delay in launching and closing them goes away. If I launch MV then QS or QSS afterward the delay on those two is back. Albiet shorter as I said above. 
 
Can you confirm there is never a delay for windowed mode?

If so, that would be convincing enough evidence to make a test "fix" for DX9 fullscreen mode.

/Probably throwing in a pq_moveup bug-fix that PoorChop spotted. 
Possible DX9 "No Delay" On Fullscreen Startup Fix? 
@dumptruck, fifth + anyone else who experiences a delay on DX9 Mark V startup:

Download: DX9 Mark V - July 11 potential slow startup fix

@dumptruck -- let me know! 
@Baker 
So this July 11 version no change.

Made 2 shortcuts on my desktop to this new exe.

Windowed mode launched 5 times in a row with almost no delay.

Using fullscreen (-current) re-introduced the delay.

I launched this 5 times as well - all the same. The I switched between the two shortcuts twice. Same results.

I tried this new exe on my older Win7 machine and it doesn't have the issue. Launches full screen with only a tiny delay. 
 
As I said, that is almost certainly a display mode change. Probably 2, switching away from your desktop mode then switching to whatever your selected mode is.

Check your console output log and you should see evidence of it. A bunch of vid_describemodes and vid_describecurrentmode commands can also help.

Yes. I'm aware of the fact that it happens on 10 vs 7, but the fact that it doesn't happen in windowed modes is additional evidence. 
@dumptruck 
Great! You might also check and see if the fix eliminates the need to set the refresh Hz in the Nvidia control panel for your 144hz display.

It may resolve that, then again it may not. 
 
/I think dumptruck has easily earned the June and July "Gunter Award For High Quality Beta Testing".

Nothing is less fun with engine coding than issues that require setups not easily available.

Thanks for the high quality beta testing that identified the source of this issue! 
@Baker 
Thanks I am no Gunter tho.

Did you misunderstand though? This did new release not fix the issue. :( 
When You State... 
"Full external texture support, DP naming convention."

Does Mark V use special effect textures as well? Gloss, normals etc? And what about shaders?

Just curious. 
Nvrmnd ^^^ 
I see you have a HD pack using qrp textures, I can derive the answer from that. Apologies 
 
@dumptruck -- my bad. I quickly scanned the post and only saw the "no delay" and "with only a tiny delay". Missed the part saying the problem still exists for fullscreen. Sorry ... guilty as charged!

I know I vastly prefer the DX9. Maybe mh will come up with some thoughts at some point. The inner workings of DX9 isn't in my knowledge set.

Odd that the OpenGL variants like the WinQuake-GL (WinQuake rendered through Open GL) and the SDL (which is also OpenGL) have no delay.

@damage - Just vanilla replacement texture support like ezQuake, JoeQuake, Qrack.

Mark V supports texture replacement from HUD to Quake models to conback and menu graphics. 
What's Delay 
thingy tho?

ps. sometimes i get the fps locking at 60 
@spy 
If sounds like you have an app running in the background that is forcing video sync.

All you can do is close the other app.

I've seen it happen before, but I can't remember what it was for me (Netflix?). 
 
As I've now said twice, it's a display mode change. Probably two. Seen it once, seen it a million times. I don't understand why dumptruck is being resistant to helping diagnose this further, though.

Traditionally Quake engines only track width, height and bpp when matching display modes. Some engines add refresh rate. A real display mode contains other values, however, and it's possible for two or more modes to exist which are the same so far as these traditional values are concerned but which are actually otherwise different.

Don't be surprised if Windows 10 adds additional modes that aren't in 7. It's a higher version of the driver model with extra capabilities.

What's happening is that dumptruck is running with -current but the engine is not starting in the current mode. It's starting in some other mode, which involves a display mode change, then switching to the current mode which involves another.

There's no delay when shutting down because it's already in the current mode and so doesn't need to switch back.

The other engines have a shorter delay at both startup and shutdown because they're doing a single mode change at each.

There's no delay running -windowed because it doesn't do a mode change at all.

In an ideal world that first mode would be a windowed one and all of this would go away - instant startups would be back. But when I tried to do this years ago I got HUGE pushback from the community. Yayy community.

Anyway, I asked dumptruck to check his console debug log which would tell us which mode it was starting in first, which could have been useful information. But once more he's being resistant to helping us to help him, so I guess that's where it's gonna end, unless he comes round.

@dumptruck - just to be clear.

I am NOT saying "you silly person, ha ha ha",

I AM saying "it's an engine bug. Help us to help you. Please" 
Come On Now Mh 
I'm not sure why you're bagging on the one guy who is downloading extra builds and running all sorts of tests on request. If he's overlooked something you asked him to do then you could make that clear. 
 
I've previously told him twice that it was a display mode change. He responded the first time to insist it wasn't, he ignored the second. I've previously asked for his console log and the output of some vid_describe commands. He ignored that too. So obviously I'm the bad guy here. Yayy Community. Again. 
@baker 
If sounds like you have an app running in the background that is forcing video sync.

yep, It frequently happens when i run the online widz etc

but
sometimes it happens just for no reason , switching to desktop and back to the game's solving the issue 
@dumptruck 
Looks like I need to experience the problem firsthand and see if I can get the problem.

It is possible something non-obvious is going on.

mh brings up bits per pixels and some other factors.

Mark V always tries to use what it thinks are the desktop "current" parameters with -current (ignoring all config settings), but maybe Windows 10 adds some additional parameters I didn't consider.

@mh - Eventually I'll get to the bottom of what is going on. The main issue to trying to find technical info on what Windows 10 updates changes/impacts has been difficult. 
 
THE FIRST DISPLAY MODE CHANGE

This is happening inside VID_Local_Vsync_Init where a call is made to sysplat.wglSwapIntervalEXT(0) - under OpenGL this is not a display mode change; under Direct3D it is.

Suggested solution: suppress this test if running under the D3D9 wrapper; you can safely assume that vsync control is always available in D3D9. This will shave 3 seconds off the startup time. 
 
Got it. I'll give that a try.

Thanks, mh! 
 
THE SECOND AND THIRD DISPLAY MODE CHANGES

In classic Fitz, at the end of VID_Init there is this block of code:

if (COM_CheckParm("-width") || COM_CheckParm("-height") ||
COM_CheckParm("-bpp") || COM_CheckParm("-window"))
{
vid_locked = true;
}


This needs to have "-current" added to the list of params checked, otherwise the engine will run the configs during startup and trigger two display mode changes (assuming a clean config, could be more). The first of these changes is slow, the second is fast (in my test the first went from fullscreen to windowed, the second just changed the size of a windowed mode).

In MarkV I think the equivalent is the video_override_commandline_params array, which is missing "bpp" from classic Fitz's list.

Fixing this up shaves a further 3 seconds off the startup time, and startup times are now instantaneous with no display mode changes happening. 
 
I'll examine that as well.

Yeah, bpp is gone (that's a relic from the 1990s when 65536 color mode was a thing). 
 
As a troubleshooting tip...

In context_t::PreReset I added the following at the start:

Con_Printf ("context_t::PreReset: %f\n", Sys_FloatTime ());

In context_t::PostReset I added the following at the end:

Con_Printf ("context_t::PostReset: %f\n", Sys_FloatTime ());

I was then able to track when display mode changes occurred and cross-reference that with whatever else was going on in the console during startup, as well as time how long each change took. Makes it very quick for hunting down this kind of thing. 
@mh 
I don't understand why dumptruck is being resistant to helping diagnose this further, though.

I need to read the rest of the thread above but I promise you I am not ignoring this situation. I can only test after work and family stuff kept me busy last night until pretty late.

Honesty, I didn't notice anything in the console and I was definitely paying attention the other night when I DID test.

So my desktop is set to 144. The game is set to 144 there's still a mode change in FS? I don't get that.

What I will ask is that someone let me know what I can look at in Windows to help troubleshoot. I am not stellar with troubleshooting the OS. 
2nd Post 
Sorry.

There's no delay when shutting down because it's already in the current mode and so doesn't need to switch back.

There IS a delay when shutting down but not 7 seconds. The game will close but the Mark V icon is still in the Quicklaunch bar and the system is unresponsive until it closes.

I will post console logs with the info mh is targeting as soon as I can. 
@dumptruck 
You don't need to do anything.

mh solved it. It's all on me now.

I want to wrap up the SnapTile editor (yeah, going with the name mankrip chose -- I can't do better) before doing a Mark V fix.

So give me a few days.

When I get close to completing something, I develop a one-track mind where I want to finish it. 
@Baker 
Thanks. And please no pressure on a timeline. Do your thing, happy to wait for your fine work. :) Excited to see this SnapTile project in action. 
Mark_v Takes 7 Full Seconds To Load 
Seems like a lot. Just tested it with latest build.
Windowed mode is instant.

Tried changing my refresh rates and this doesn't change the delay (I have a 144hz monitor).

Closing Mark_V takes 4 full seconds fullscreen and closes instantly when in windowed mode. 
@dumptruck 
Yeah, we tracked it down.

I owe you an apology for being a dickhead about this. On the other hand, MarkV will get better as a result. 
Mh 
No worries! Poor Baker though. Coding during the summer. ;) 
 
I'm only the idiot who wrote the code, Baker's the idiot who has to maintain it! 
Video: High Definition Pack With More Realistic Shadows 
High Definition Pack Video With More Realistic Shadows:

Watch Video

1) r_shadows 3
2) r_waterripple 3
3) QMB on, obviously
4) With HD Pack and Transparent Water .Vis/.Lits Pack

For illustration purposes. 
 
dumptruck_ds: Thanks I am no Gunter tho.

Hey, you're doing extensive testing and detailed reports to help squash obscure bugs AND getting mh miffed, so you're well on your way! 
 
Cool shadows. Any chance for lit liquids in the future? 
 
I can't remember if mh wrote a full fledged prototype or not and if the one or two small but important barriers were solved (i.e. detecting lit water and maybe something else).

I think if he did, it would eventually happen. 
 
I've solved the detection and posted the solution in some thread here or at InsideQC a long time ago.

The other problem was to compile the maps properly, but EricW solved that. 
Lit Liquids 
Wasn't there an issue with the surface warping making it look really bad? 
#2347 
Not in my engine.

And in hardware-accelerated engines it should be easy to combine warped textures with non-warped lighting through shaders. 
 
Detection: http://forums.insideqc.com/viewtopic.php?f=12&t=5835

And in hardware-accelerated engines it should be easy to combine warped textures with non-warped lighting through shaders.

This doesn't need shaders; hardware-accelerated Quake already uses two separate sets of texture coords for difuse and lightmap, so just warp the diffuse coords only but don't warp the lightmap coords.

The issue is that whatever way you slice it, it looks bad.

I do understand where the desire to do this comes from. You've built a map, you have a large water surface in it, the surrounding geometry is nicely lit and shadowed, and the fullbright water looks bad. And you're right, the fullbright water does look bad, but lit water actually looks worse.

The two big problems are (1) when the lighting on the water is sufficiently dark you can't see the warp effect at all i it just looks like a big dark spot, and (2) with translucent water enabled the water just disappears.

This is an example of taking a special case and wanting a general case solution for it, but not properly considering how that general case solution may or may not work outside of the original special case.

"Can I have lit water?" seems a reasonable request, but you also need to be thinking about lit laval, lit slime, lit teleports, how it interacts with translucent water, etc. 
 
I've already considered all of that years ago and Retroquad has individual cvars for each texture type. I usually keep r_portal_lit and r_lava_lit disabled in Retroquad, because the textures I'm using for them doesn't have glowmaps. But the slime texture I'm using does.

Your mistake is to think that you're the only one who thought about all that. No, you're not, you haven't even thought about liquid textures with glowmaps (QRP has them!), and the worst thing is that you're speculating from a purely theoretical standpoint while I'm speaking from experience.

Lit water does look fucking good. The Unreal engine already has lit water since 1998, and nobody ever complained about it because its maps were created with lit water in mind. Lit liquids in Quake is for NEW MAPS ONLY because the maps need a full recompile from the .map sources for this to work and the mapper must deliberately opt-in to enable it in the compiler.

Your issue is that you don't want mappers to have a chance. You don't want them to experiment and learn how to tweak the lighting in their maps to make lit liquids look good. You don't want them to have artistic freedom.

The "it looks bad" argument is not a technical argument, it's merely an uninformed opinion.

You are not a mapper. 
 
...and the worst thing is that you're speculating from a purely theoretical standpoint while I'm speaking from experience

I am actually also speaking from experience because I have also written this code and have also seen what lit water looks like.

Here's the Quaktastic folder where I uploaded a bunch of screenshots: http://www.quaketastic.com/?dir=files/screen_shots/LITWater

Check the date on them - over a year and a half ago.

Check some examples of exactly what I mean:

http://www.quaketastic.com/files/screen_shots/LITWater/e2m5_litwater.jpg

http://www.quaketastic.com/files/screen_shots/LITWater/e1m5_litwater.jpg

http://www.quaketastic.com/files/screen_shots/LITWater/e1m2_litwater.jpg

Your entire premise is based on the assumption that I don't know what I'm talking about, whereas I actually do. When I say "lit water actually looks worse" you had two options and you instantly reached for the negative one - yayy community. 
 
I am actually also speaking from experience because I have also written this code

No, you are speaking from MAPPING experience.

I've never made a full map but I often practice mapping to test and learn how new features like this could be used. 
#2352 
* not speaking 
 
Not only you used screenshots from other people's maps that were NOT designed for lit water, your E1M2 screenshot shows that you probably didn't recompile them using the latest versions of EricW's compilers, which properly lits the liquids from both sides. The lighting at the edges of the water should be similar to the lighting of the walls that crosses them. 
 
All your screenshots looks like they didn't use EricW's compilers. Completely missing backside lighting.

I'm on mobile and not at home now, but asap I'll post some screenshots of those maps properly recompiled. 
Hmm.. 
To me all three of those screenshots you chose mh look quite promising and easy to work around to get pretty lit water with some effort from the mapper (and yeah some compiler magic would obviously help).
Would be curious to see with some high alpha values, as you seem to say it looks ugly, but plenty of other games have lightmaped transparents that look fine. 
 
OK, I am going to put my money where my mouth is.

http://www.quaketastic.com/files/misc/Q1LitWater.zip

This package contains:

(1) A version of GLQuake modified to support lightmapped water.

(2) Source code for it.

(3) A version of e2m5 compiled, using EricW's tools, for lightmapped water.

So now everyone can see it. 
#2357 
Finally. We should let the mappers decide. Thanks for listening.

And to finish settling this, here are the comparison screenshots:

mh E1M2
Retroquad E1M2 (opaque)
Retroquad E1M2 (translucid)


mh E1M5
Retroquad E1M5 (opaque)
Retroquad E1M5 (translucid)


mh E2M5
Retroquad E2M5 (opaque)
Retroquad E2M5 (translucid)

My recompiled E1M5 and E2M5 maps used an older version of EricW's compilers that added improper dirtmapping to liquids, IIRC (which is why their water is a little darker on the edges). But my recompiled E1M2 map used a later version that fixed all issues. Anyway, see how different all of them are from yours. 
 
Since mh wrote a prototype for it (using GLQuake makes it essentially a tutorial for any engine developer), it rather likely that some future date it will added to Mark V.

Especially since ericw (and Spike too?) invested the time to make lit water in the ericw compile tools.

I don't have an opinion of lit water. It is the time investment by other developers which would be the reason to have interest in adding it from my point of view. 
 
Here's a screenshot of my recompiled E1M2 running in mh's GLQuake with opaque lit water support
Hey Poorchop 
I noticed that Poorchop mentioned mouseclicks not registering. I'm seeing that myself at the moment with a fresh Mark V install on latest Windows 10... sometimes it's the +mouse1 that doesn't register (and so it doesn't fire), sometimes the -mouse1 (and so it doesn't stop firing).

Happens with both mark_v and mark_v_winquake. Doesn't happen with latest quakespasm.

Anyway, just some corroboration. Let me know if I should test/try something. 
@johnny 
Hmmm.

1. Does the SDL alternate build do this as well? SDL build

This would tell me if it were something about the pure Windows code or the all operating systems code.

2. Also: What do you have mouse1 bound to? Attack? Jump? 
 
1. Not nearly as often. I was hoping I could say "never", but I do think it missed a couple of mousedowns during a map playthrough. (While in comparison, it would not be unusual for mark_v.exe to miss a mouse event in the course of even an individual fight.)

2. +attack 
 
One probably-irrelevant difference I noticed: the mark_v.exe FPS display is pegged at 72 (my host_maxfps), while the FPS display in the SDL build wandered between 67 and 70 on the same map. 
 
Yeah, the probably irrelevant difference is just that. The DX9 is better at hitting exactly the 72 because it is faster.

re: mouse - Looks like more to do with Windows 10. I'm glad you are able to replicate the issue PoorChop experienced, increases odds of conclusively solving it. 
First | Previous | Next | Last
Post A Reply:
Name:
Title:
Body:
message
question
exclamation
idea
flame
noflame
error
skull
beer
moon
pent
rocket
sheep
pacman
pig
cheese
worldcraft
gauntlet
crate
pitfall
pimp
smile
cool
sad
frown
oi
yay
tongue
evil
wink
neutral
q1
q2
q3
ut
hl
cs
doom
dkt
serious
cube
Website copyright © 2002-2018 John Fitzgibbons. All posts are copyright their respective authors.