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. 
 
I'm glad too, good to know that I'm not the only one experiencing this. 
 
For the people who want to test it, here are some of the ID1 maps I've recompiled with lit liquids:
http://www.quaketastic.com/files/misc/litwater_id1mapexamples.7z

I've tried to figure out how to implement lightmapped translucent liquids in mh's GLQuake code, but hardware rendering isn't my thing and I've got no time to learn it. 
 
If I get time I'll do a 2.0 build. It's not overly difficult, like you indicate, just a matter of knowing what to do. 
When You Wish Upon A Star... 
So these lit water and things are looking cool. I am also wondering about the possibility to implement sv_protocol 999 support in Mark V.

The map I'm working on needs it, and I get a hard crash with hunc_alloc error similar to TerShib when I try to force it.

Is there a chance to see this happen? I would love to be able to see how the map handles in Mark V. 
 
Version 2 with translucent water support: http://www.quaketastic.com/files/misc/Q1LitWater_2.zip 
 
HUGE thanks!

Initially I thought "well, I can just combine the texture & lighting like the translucent mirrors does before blending", but then I found out that GLQuake's mirrors doesn't use lightmaps either. No way for clueless me to hack it in. 
 
 
I have to be quite tiresome about this and confess that I'm still not a fan of the look. To me, the water no longer looks like water - it looks solid instead.

I'd also be of the opinion that light should go through translucent water.

But then, Quake's rendering was never really about being 100% realistic anyway. 
 
Well, it still looks better in Retroquad, mainly because of soft depth. But I'm confident that mappers will figure out good ways to use it.

And it should certainly be optional. 
Feature Request For The Future 
cl_autodemo is really invaluable. If you could append the map filename to the file they generate that would be super helpful. Or at least part of the name. Ppl ask me to play their maps often and I use autodemo for this. Would be great to know what map a given demo is for outside of the exe. I am constantly renaming files. 
 
Redfield -- A large coordinates protocol would be a next year most likely. It wouldn't be sv_protocol 999, which sports lots of brokeness (I should make a video sometime).

Dumptruck - Mark V autodemo was adapted loosely from Qrack autodemo which does exactly that. If I am able to determine the cause of the Poorchop/Johnny Law mouse issue, I would probably throw in a "cl_autodemo 2" that like, Qrack, does exactly what you want. 
Ooh Ooh, An Idea! 
play_autos mydemo

To play all of mydemo0, mydemo1, 2, 3, 4 etc. automatically in a row.
And if someone leaves out, mydemo3 for instance, it would just skip to mydemo4.



Protocol 999 opt in cvar pretty please please. With sugar and a cherry on top. I've got a few Orl-size maps I'm working on that have a 99.9% chance of needing 999. 
Baker 
Yes, would you make that video demonstrating 999's brokenness? Or at least briefly talk about it? Cause I'm curious to know. 
@ORL 
Yes, in time I will make a video.

mh has an expression "once you see something, you can't unsee it".

I think seeing in this case is going to be necessary. 
Protocol 999 
I'm the original designer.

The core idea is actually quite solid. It's based on 666, but with the addition of a bunch of opt-in features. The client and server negotiate which features to use, and the whole thing can gracefully degrade if a feature is unsupported.

It was always more about higher precision angles and more TE_ effects than big coords, or at least that's how it seems to me thinking back, but big coords was just one of the things it could also support. The important thing though is that it's extensible nature means that you could plug in your own big coords system if you wanted.

Being built on 666 means that it inherits all of an NQ protocol's weaknesses. That's not an attack on 666, it's an observation on NQ protocols in general. There are much better ways of doing all of this stuff; supporting big coords, more precision, more effects AND being more efficient in the data stream. NQ is a bit brute force, which is fine in simpler setups but hits scalability ceilings much faster. 
 
mh: it was always more about higher precision angles ...

Translated: nice smooth rotating doors and draw bridges.

(like Remake Quake could do -- as opposed to clunky hipnotic doors)

Fitz 666 didn't have enough angle precision resulting in walking on a drawbridge coming down to not feel jerky and the same for getting pushed by an opening door. Also the higher precision angles were used for some rotating effects in QuakeC. 
So... 
999 should be used on any map with bsp rotation such as drawbridges, pushable gates (ne_ruins), rotating path changers (like Dismal Oubliette but rotaty), etc.

OR maps as big as Orl's.

Still not sure what the problem with it is. 
 
It should probably just be renamed to "ORL Protocol." 
@qmaster 
Nope. 999 does nothing for hipnotic rotation at all.

If you want to see real rotation, you'll have to play Remake Quake and trigger the draw bridge or find a rotating door.

Must use the Remake Quake engine -- Quakespasm doesn't support true rotation (nor does Mark V, it did briefly once upon a time but it led to the discovery of some oddness with existing Quake maps -- even a couple of stock Quake ones -- and was removed).

Sadly, true rotation sadly interferes some with existing maps where entities or even maps have the angles key set (and they shouldn't be). I think dis_sp3 is an example. 
 
a lot of games come with two *.exe's
one for windows 32 bits and one for windows 64 bits...quakespasm have quakespasm.exe and quakespasm-sdl2.exe... even quake has two exe's (normal and opengl)

maybe would be cool to have two markv.exe's, one for old maps and one for new maps with true rotation :)

just my two cents :) 
MH 
There's something strange I've spotted on your GLQuake code, in R_BuildLightMap.

This is your source:

for (j=0 ; j<smax ; j++)
{
t = *bl++;
t >>= 8;
if (t > 255)
t = 255;
dest[j] = t;
}


But this is the original source:

for (j=0 ; j<smax ; j++)
{
t = *bl++;
t >>= 7;
if (t > 255)
t = 255;
dest[j] = 255-t;
}


What's the reasoning behind that?
(255 - (t >> 7)) == (t >> 8) ?

Oh, wait, I've found it:
"shift the lightmap by 8 (jnstead of by 7) in R_BuildLightmap"
Overbrights, ok.

However, by doing that you lose precision, resulting in more abrupt discrepancies in light values across different surfaces, which is likely another reason why the lightmapped water in your GLQuake engine looks worse than in Retroquad.

Compare these shots:
GLQuake
Retroquad (with soft depth disabled) 
 
Yeah, that's overbrights. Yeah, it loses 1 bit of precision, but it still has 256 gradations of light - software Quake only had 64.

Rotation: higher precision can't fix Hipnotic rotation, that was born broke (fun fact: the hackiest mod is Nehahra, the second-most hackiest is Hipnotic). I can't recall the exact use case but it would have been something like a drawbridge that had the herky-jerkies with standard 8-bit angles. 
 
Retroquad uses the full 8 bits of precision, and it also compensates for the loss of precision. It has nothing in common with WinQuake when it comes to shading & texturing.

The fact is that the same light can be raycast to slightly different levels across the edges shared between different surfaces. The less precision is used, the bigger this difference can become. 
 
The full range of light scales per the BSP format can't be represented by standard 2x overbrights. "z" is double-bright, so with 4 lightsyles combined I make that 11 bits per channel, and that's not including dynamics.

I guess that the point is, you're always going to be losing precision. 
@Tribal 
maybe would be cool to have two markv.exe's, one for old maps and one for new maps with true rotation :)

32-bit vs. 64 bit doesn't have anything to do with rotation. Remake Quake engine with true rotation is a 32-bit.

Half-Life has had true rotation since 1998 and it evident in all aspects of the game.

There really aren't any advantages for 64-bit on Windows that I can name, except 64-bit uses a bit more memory because pointers are twice the size.

The Linux build of Mark V, for instance, has always been 64 bit. 
 
I guess it wasn't clear that I'm implying that the loss of precision can be compensated for by doing t = (t + (1 << 7)) >> 8. It's exactly the same principle of adding 0.5 to the velocity to fix the gravity issues in low framerates. It's obvious.

Anyway, it may be not enough. Besides this compensation, Retroquad performs color correction, gamma correction, brightness correction and multiple kinds of error diffusion.

Maybe the results will be better when your code gets ported to Mark V or other advanced engines. 
@Baker 
The win32/win64 bits was used just as an example of games that come with two exe's. I didn't want to imply that it has something to do with true rotation :)

Well, forget my lame example... My point is, why not compile two markV.exe's? One to play old maps and one (with true rotation) to play new maps that can use this feature? =D 
Yeah, Sure Not Quite Mark V But Whatever 
A induces B.

Image ---> video 
@mankrip 
That's just rounding to nearest rather than rounding down.

Believe me, I've rewritten the lightmapping code to use L16, RGB16, RGB32F, RGB10A2 and other formats over the years. I've written GPU lightmap implementations where the 4 styles are combined on the GPU with zero precision loss. I've stored exponential factors in the alpha channel and unpacked them in a shader. I've even done 4x overbrights with standard RGB8 lightmaps, losing 2 bits of precision.

This is not a big deal. For lightmaps the extended range is more important.

I guess a version 3 using L16 lightmaps might be in order to prove this. 
 
And just in case this needs to be explicitly stated.

The lightmapped water path uses exactly the same code as regular lightmapped surfaces. In GLQuake that's just multiplying 2 numbers, and nobody can claim that one way of multiplying 2 numbers gives a better or different result than another.

Frankly, I'm sick of hearing "Retroquad is better because..." - where can I download Retroquad, run it, study it's code and learn from it? Nowhere. You may as well be talking about touched-up screenshots for all the practical use that is. I've heard the mouth, show me the trousers. 
Arcane Sprites And Particles 
I was talking with some others about the way that Arcane's particle effects are rendered in different engines. I was wondering if you had any plans to bring Quakespasm's level of detail to the engine. QS doesn't really do a whole lot but there are some extra sprites for models like the flame. Their absence is pretty striking in Mark V. Here's what I mean:

QS:
https://i.imgur.com/5lvrO9y.jpg

Mark V:
https://i.imgur.com/rmgvRMq.jpg

I didn't even think that QS was doing anything in particular regarding Arcane's extra particle effects. I do know that QSS takes it a step further with smoke but I'm not expecting that level of detail in Mark V. I also know it's a pain when users make requests like this but don't get me wrong, I'm not asking for this to be turned into an existing engine. I just like the extra sprites and I was wondering if there were any plans for something like this. 
Their Absence Is Pretty Striking In Mark V 
not sure what you mean, i believe the particles not showing up on mark V - it's on your side

i have no probs here
https://imgur.com/a/YBJ9pFq 
 
I have a feeling that you're not using a default setup. The flame itself in your photo looks like a sprite or even just a bunch of particles lumped together. In a clean install of Mark V and a fresh install of Arcane 1.7.1 with default settings, flames don't look like that. 
 
Version 3, with GL_LUMINANCE16 lightmaps; thse are 16-bit lightmaps with 7 more bits of precision than GLQuake without overbrights and 8 more bits than GLQuake with overbrights. I'd encourage anyone who thinks that bits of precision in lightmaps are super-impotrant to run this and see if they actually are. I'd even encourage double-blind tests.

http://www.quaketastic.com/files/misc/Q1LitWater_3.zip 
@Poorchop 
yeah, the patricles depend on temp1 in AD cfg settings 
Ah The Flames 
it's QMB enabled in my case, you can turn them off 
GPU Lightmaps Implmentation 
Quake 2 engine, D3D9, with GPU-animated lightstyles and GPU dynamic lights; renders the lightmaps at the full original precision of the BSP light data lump; unlimited dynamic range for added dynamic lights.

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

It's a long time since I worked on this so I don't know how robust it is, but it should be fine for playing through the original SP missions. 
Quake 1, Partial Real-time Lighting Implementation 
This was another one that went part of the way but I didn't continue with; no real idea why. It uses real-time lighting derived from the same light equations as are used in the original light.exe, but I never got round to adding shadows. Needs heavy optimization work.

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

Its fun to run around the original maps and look at how different the lighting quality is, but I wouldn't play Quake with this. Also, any map compiled with any more modern tool will probably look hellish weird because I don't have support for all of the other options added since light.exe was originally released. 
As You've Stated 
I was talking with some others about the way that Arcane's particle effects are rendered in different engines.

https://imgur.com/a/3oSpkFn

this pretty much matches the qs screenshot 
Q2dx9 
not bad

https://imgur.com/IrDhF6Z

https://imgur.com/kFW0TIU

it seems it's a great alternative to KMQ 
 
That's just rounding to nearest rather than rounding down.

Yes, but in color calculations, every small inaccuracy amplifies the others. And as mentioned, gamma correction also plays a part and there may be issues with gamma correction.

Anyway, while I was open to explore how to improve the image in GLQuake and trying to figure out what's causing the differences in lighting, you're getting angrier. Better forget this conversation and leave it behind, it's not good to let things become unhealthy. 
#2405 
Go underwater ;) 
@Poorchop 
In Mark V change Temp1 to 1024 and restart the map for particles. Its at 0 by default. Mark V is capable of displaying the same AD particle effects as QS. 
MH 
the waterwarping is a pretty great
but i'm not a fan of distortions
sorry

https://imgur.com/a/LXc2KYT 
 
Thanks spy and Redfield, that worked and it looks great now. 
Gamma 
If you let Mark V generate a new config file from scratch and check the gamma, it says that it's set a 0.75 even though 1 is listed as the default. I thought that this was a bit strange and I'm looking for some insight on it.

I also have a slight suspicion that this has an impact on mappers. I've played some maps recently that were incredibly dark at gamma 1 and contrast 1, but they were much more playable at Mark V's default gamma of 0.75. It makes me wonder if people are mostly just testing in Mark V causing their maps to be extremely dark in other source ports that default to 1/1 gamma/contrast. 
Gamma 
GLQuake defaulted it's gamma to 0.7 on non-3DFX hardware. Not sure why MarkV is doing similar but it seems too much of a coincidence. 
 
Mark V doesn't default gamma 0.75 (gamma 1 is default), but a certain revision did (revision 2? revision 3?) where I was merging with QuakeDroid. Johhny Law noticed different defaults in the Windows version and I corrected.

QuakeDroid defaults gamma 0.75 because gamma 1 is just too dark. 
Windows 10/Poorchop/Johnny Law 
On my Windows 10 machine, I didn't experience any Poorchop/Johnny Law mouse oddities.

Makes me wonder if maybe I could cause the issue somehow by installing maybe new Direct X drivers? I don't know.

If I can't experience an issue, makes it tough to guess. The mouse was fine for me.

If Mark V 1036 download link doesn't experience the mouse issue on Johnny Law/PoorChop's machine, I would suspect the issue relates to DirectInput which 1.99 switched to.

If that is the case, I could make DirectInput turn on and off and maybe default off. 
 
make DirectInput turn on and off and maybe default off.

I'm thinking that's probably the best option.

After playing Mark V and setting my sensitivity to an appropriate value to account for dinput, if I then use some other engine or a different version of Mark V, my sensitivity is way too high!

Here's another thought: If dinput is being used, automatically double the sensitivity value (rather, treat the value as doubled). That would probably get rid of the need for the Sensitivity slider to go up much higher to account for dinput being much less sensitive.

And if people wanna be more precise (even with the doubling happening behind the scenes), they can use decimal values, like sensitivity 10.5

But doubling the Sensitivity value for dinput would probably feel very close to the standard Sensitivity value when dinput is not being used. 
 
Bummer that you couldn't reproduce. I gave Mark V another few tries within the past few weeks and I had the same exact issues that Johnny Law spoke of - sometimes -mouse1 didn't register so I was firing indefinitely. Previously I just thought it was neither +mouse1 nor -mouse1 registering.

I'll spend some time playing around in 1036 to see if it works fine for me. 
 
I'm about to go camping, but I'll remember to get back to this later. 
 
Guys take your time, it's the summer. But yeah, if either of you can find out if 1036 does or doesn't have the issue, it can really shed some light on the nature of the issue. 
V1036 Works Just Fine 
I've tested long enough by now that I would've noticed if I was still having issues but I haven't had any problems with 1036. I spent a while bunny hopping and playing through maps, and all of my mouse clicks registered just fine.

On a side note, I am getting some pretty terrible performance outside of id1 maps but that's another issue. 
 
Thanks for info. Helps confirm thoughts on issue. 
@poorchop 
May I trouble you to test one more build ...

The 1080 build. download

And tell me if you have the mouse issue with 1080.

The results from 1080 should allow me to conclusively and quickly do a patch fixing exactly the "right" thing. (The alternative is some guesswork and if I am wrong it could take 3 attempts.)

I'd like to resolve the "Poorchop/Johnny Law Windows 10 mouse issue" right the first time. 
1080 
I played through some id1 and bunny hopped around for a long time, but I didn't notice any issues with mouse clicks registering. v1080 seems to be working fine here as well. 
@Poorchop 
Thanks! 
 
FWIW I just played through Amphitheater Of Abaddon using build 1080 and didn't notice any problems. 
 
(and that was me) 
1099_r4 
Defaults to gamma .75 I can confirm this as I've installed it into new directories 3x this week. I usually reset my config by hand BTW so it's defaulting for sure. 
@Baker 
Heads up that uwjam is performing pretty badly with this mod. Seems the sprites are causing significant framerate issues. I will test some more this evening but wanted to check with anyone else and see if they were experiencing issues.

I just played in QSS and did not experience the showdown. 
 
I haven't tested uwjam with Mark V but I've played a few other maps that have some frame rate issues despite running perfectly fine in other ports. Not really sure how to troubleshoot something like this though. 
 
The MarkV D3D9 sprite drawing code is particularly sensitive to high numbers of sprites and will suffer performance problems in those situations.

Basically it looks something like this:

for (int i = 0; i < numsprites; i++)
{
SetState ();
DrawSprite ();
UnSetState ();
}


In order to deal with D3D9's well-known draw call overhead problems, the D3D9 wrapper code attempts to concatenate multiple draw calls with the same state into a single draw call, so that the whole thing can run with fewer draw calls.

The MarkV code (inherited from FitzQuake, in turn inherited from GLQuake) prevents it from being able to do that, because making any state change will break a batch.

Changing it to something like this will help a lot:

SetState ();

for (int i = 0; i < numsprites; i++)
DrawSprite ();

UnSetState ();


By SetState and UnSetState I specifically mean the alpha test state here; the polygon offset state only happens with Hipnotic bullet-hole decals and should be rare enough, whereas texture changes are something that has to happen so that's a state change that you'll just swallow. But this change on it's own should go a long way towards fixing things up. 
@mh 
Added to the list. 
 
Recursion is hated in lowest-level coding -- when you look at what is going on at the stack level.

Recursion causes tons of unnecessary stack push/pop slowing down what would be faster loop mechanics inside a single function.

Elegance hates "goto". Yet "goto" dominates the world and well-written low-level code is code that the compiler can reduce to "goto" form avoiding the use of recursion.

/The D3D9 sprite handling is making me think about how to best optimize sprites next round to fit how D3D9 wants the data fed. 
 
This is just similar to the technique for making dynamic lights go fast - if you have a bunch of work to do, dividing it into fewer large batches will always outperform many smaller batches. Beyond that it's just a matter of understanding what patterns can prevent fewer large batches, and in any 3D API (including native OpenGL) that's going to be things like unnecessary state changes. Typically brought on by things that seem "right", such as unbinding textures/buffers, or putting state back the way it was after drawing an object.

The Quake code is riddled with small inefficiencies and it's death by 1000 cuts. None of this mattered in 1996 when GLQuake only ran on high end workstations, and everybody else had a 3DFX which routed it's drawing through a layer which tried to make something sensible out of it.

Ever bought a new GPU and found that Quake ran no faster on it?

Recursion is going to be down in the noise in any Q1 performance graph. Any decent compiler will automatically generate the right optimized tail-recursion code for you, without you needing to resort to tricksy or cutesy obfuscation. Don't waste time on the small beans.

In an ideal world that D3D9 code would not be needed; you could rip it out tomorrow and start investing time in making your OpenGL go fast, which IMO would be preferable to trying to make the 2 APIs coexist peacefully. The big secret is that Intel graphics are no longer crap, and haven't been for a long time. It's not Intel graphics, it's Quake's use of OpenGL that's crap.

As a general rule, bad OpenGL code will go faster than bad D3D code. But good D3D code will go faster than good OpenGL code. But in order to get good D3D code you need to go native and start writing code that's tailored to D3D's strengths; trying to translate bad GL code into something that tries to do the right thing in D3D can only get so far and will always throw up unexpected glitches and bottlenecks - like the sprites case. 
@mh 
I was thinking of qmb and to some extent Nehahra extra effects that are in the engine (above and beyond stock Quake sprites). qmb is highly recursed. 
 
Ah, I'm not familiar with the QMB code although I've been aware of the effects since almost the very beginning. That's something I must rectify. 
@mh 
I took a look at the real-time lighting prototype you made a few hours ago.

Looking at the source, I thought the dates were funny because you wrote it at the same time as the DX9 wrapper. 
 
How do I enable vsync and set color depth in Mark V? And for a Quakespasmer just coming around to Mark V, what are some of the notable differences between Mark V and QS, ie. what's the reason behind developing two separate engines that do a lot of the same things? 
Mark V Vs. QS 
vid_vsync 1 (I think away from PC)

Mark V in DirectX 9, has mouse driven menus (if you get used to it and go to QS - you'll miss it), levels menu item, demos menu item, you can fast forward demos, some developer tools and a "find" function in the console - which is handy.

Quakespasm has excellent performance and compatibility with mods etc is very good. But I prefer Mark V overall for the reasons above. 
 
Mark V does nehahra, whereas QS doesn't, correct me if I'm wrong 
 
Many of the MarkV features you speak of are not solely markV, but a culmination of other open source software.
Use what you like. But when you get down to brass tacks, gameplay, it's pretty much just Quake. 
 
MarkV Direct3D 9 doesn't allow changing of colour depth; it's hard-coded to the colour depth of your desktop. 
@mh 
Thanks. Mark V looks nicer on my machine (better colour depth, smoother gradients than QS) but as dumptruck_ds alluded to I have issues with performance. As a total package QS is tough to beat. 
 
how could the color depth be better than QS? Is it HDR? 
 
It should be identical unless the driver is doing some performance/quality tradeoffs behind the scenes. 
 
Black is a deeper black and fog gradates better in a map like honey for example. I thought it was my shitty monitor until I ran Mark V for the first time to play Nehahra. Performance was slower than QS (laggy mouselook) but it looked great. Too bad I can't show the difference. Could very well be my system which is getting up there in age but the two certainly don't look identical. 
 
Fog being different would make some sense, because the two different APIs can potentially have different fog calculations, with OpenGL's hint mechanism in particular being quite weakly specified: it's perfectly legal for GL_NICEST fog to give you per-vertex fog, for example.

In general however I would attribute this to your driver just giving a different image, as I said, likely via a performance/quality tradeoff. There's certainly no magic voodoo going on here. 
 
Ah yes, that pesky driver update that failed on three different occasions is fucking me in the ass, thanks for the insight... 
 
Hm. Baker... I found something you did and I don't like it :D

I was re-assigning some buttons so now I can use ALT to +attack (I was using the button on my trackpad with my thumb to +attack, but I've found it's less of a stretch -- physically -- to just hit the ALT key with my thumb instead).

So then I hit ALT + M to do a certain key combo that I occasionally use, and the console starts spitting this out at me:

Mute: ON --- ALT-M to Toggle
Mute: OFF --- ALT-M to Toggle

Sure enough, ALT + M puts Quake on Mute....

But I don't want that!

If you want a Mute feature, just make it a console command: "mute" and we can assign it to whatever key we choose.

As it is now, it's interfering with a key combo that I want to do something else....


Ya know, while I'm talking about ALT key combos, I remember suggesting in the past to allow key combos to be bound, so if I actually wanted ALT + M to do MUTE (if MUTE were a console command) I could do it like:

Bind @m mute

(if you made @ designate the ALT key combination)

Ah, on the Old Page #1352 I was thinking about "shift" keys for gamepad binding, but it could also work for keyboards. I suggested allowing any key to be designated at the "shifting" key for combinations....

Do any other Quake engines allow fancy binding of key combos?


Anyway, key combo binding is a "possible wishlist" kind of thing.

Whereas ALT+M = MUTE is a "NOOOOOOOOOOOO!!!" kind of thing :D

And probably a "Only Gunter would discover that undocumented feature and take issue with it" kind of thing ;) 
 
Do any other Quake engines allow fancy binding of key combos?
FTE allows you to bind alt+m "echo ALT+M was pressed"
(ctrl+alt+shift modifiers and variations thereof are supported. Note that if you use a key as a modifier then you should probably not bind it to something else at the same time - it'll work, you'll just get unwanted binds.)

A workaround for DP would be to write some csqc that looks for modifier keys and then reconfigures DP's bindmaps, which isn't user friendly for multiple reasons. 
 
Yes, confirmed that MarkV has Alt-M hard-coded to toggling mute on/off.

Other hard-coded key combos:

Alt-Enter: switch between fullscreen and windows.

Alt-Tab: switch between different applications on the OS.

Ctrl-C: Copy.

Ctrl-V: Paste. 
 
That FTE functionality wold be something really (really) good to import.


I hadn't thought about those other hard-coded combos, since they are standardized Windows behaviors.... so they behave as most people would already expect.

I suppose you don't need to have CTRL+C and CTRL+V function when the console isn't down though. Those would be the only other combos I would think that might potentially interfere with something someone might bind. Few people are going to mess with the TAB or ENTER key, since they already have commonly-used functions in Quake (scoreboard and entering messages or menu navigation).


On the subject of Mute, if I use my media keys on my keyboard to change system volume or mute, it causes a little display window to pop up on screen notifying me of whatever I changed, and that causes Quake to minimize. I wonder if there's a way for Quake to ... not be forced to minimize in this situation.... 
 
Huh, well, I'm testing it again today and my media keys aren't forcing Quake to minimize.... Well, not consistently. The first time I tried it, Quake minimized but then it restored itself. After that (even after closing and restarting Quake) it doesn't minimize at all, and the overlay flickers in front or Quake for a moment.

So I don't know. It's inconsistent. Probably a Windows thing. 
 
On the subject of Copy/Paste, I guess even if the console isn't down, you'd want CTRL+V to function if someone was entering a chat message too.

I have often wanted to Copy test from the console, but you can only select text from the line you are currently typing on (by using shift + left/right), but that's never what I want to do. There should be some way to select text that has already been printed in the console, either with mouse select or by pressing shift+up to select previous console lines.

I end up having to use the "copy" command, which copies the entire console contents. 
How To Build On Linux Myself? 
Source code only contains project files for building on Windows. No makefile, cmake, etc. 
#2455 
There's a project file for codeblocks. 
In Futute Versions 
Would there be a way to have more that just three cycling autodemos? I test a lot of maps for newbs and like to use Mark V's cl_autodemo. But much of the time I die a lot! Which obv overwrites the dems.

I know I asked for the map name to be added before, I figured heck why not ask for this too. 
Weapon Animation Interpolation 
Hey guys!

Animations of Weapons and Super nailgun in particular still look choppy when firing, though these cvars are enabled :

r_lerpmodels "1"
r_lerpmove "1"

How to make 'em smooth like in DirectQ, for instance? 
 
Animations of Weapons and Super nailgun in particular still look choppy when firing ... How to make 'em smooth like in DirectQ, for instance?

This is a content issue.

FitzQuake (which both Quakespasm and MArkV are derived from) works around it in one way, DirectQ works around it in a different way, and both ways have their pros, cons and trade-offs.

First of all, the issue.

The Quake weapon models have polygons for the muzzle flash animation embedded in them, and when the gun fires the flash polygons are moved into the correct position.

When interpolation is switched on, what this causes is for these polygons to move with interpolation, which causes them to swim into view, and dance back-and-forth across the space between the nailgun barrels.

FitzQuake and derivatives work around this by temporarily switching off interpolation if the gun is in a muzzle flash state.

DirectQ works around it by measuring the delta between vertices in the two frames to be interpolated, and if the delta is sufficiently large (above some arbitrary value that was tweaked until it gave the correct result) assume a muzzle flash motion and don't lerp, on a per-vertex basis.

DirectQ used vertex shaders for everything so it could do this quickly and easily, and it really wasn't much more than an extension of the same kind of thinking as the "assume a teleport and don't lerp" check elsewhere in the engine. It should be obvious that this approach is vulnerable to both false positives and false negatives, however.

The correct way to fix this is new content. A set of weapon models that don't include the flash polygons, a separate generic muzzle-flash model, and the QC code to stitch them together.

Meanwhile, FitzQuake allowed disabling it's behaviour by setting r_lerpmodels to 2 - not sure if MarkV and QS do likewise. 
#2459 
Big thanks for an explanation MH !

"r_lerpmodels 2" works just as intended in Mark V either :)

I've actually wanted to ask you a DirectQ related question since 2013 but was unable to contact you.

You've probably been informed about "sinking into ground" bug that occurs after about an hour of playing in DirectQ. Most of the corpses around the map blow up and the player starts sinking into ground. The only way to solve an issue (temporarily) was to save a game, restart the engine and load it again. I've wondered since then, has there ever been a solution found for eleminating this nasty issue or not? As it is the only major problem I found while playing DirectQ. That source port satisfied me in every aspect of gameplay and gave a really nice old-fashioned feeling of quake experience.

I was running v1.9.0 
 
You've probably been informed about "sinking into ground" bug that occurs after about an hour of playing in DirectQ...

I fucked-up the physics code somewhere, but never was able to determine where. 
#2461 
Yeah... it's a pity.

Apart from that terrible bug, DirectQ is still great

:) 
@dumptruck_ds 
startdemos demo1 demo2 demo3 demo3 etc up to 32 demos
or edit your autoexec.cfg and add :

demos demo1 demo2 demo3 demo4 demo5 demo6 demo7 etc.. 
Oops! That's Not Right 
startdemos assigns the order demos is the console command to skip to the next one in sequence.
so just use startdemos either in the .cfg or console 
@R00k 
I wasn't too clear in my request.

Currently Mark V records 3 autodemos per session: autodemo_0, 1 & 2. If I die a 4th time (happens too often!) autodemo_0 will start from that point in the game, erasing my prior demos. What I'd like is to just keep recording demos 3, 4, 5 and so on.

And would love to have the demo be named the same as the mapname. So e1m3_0, e1m3_1 and so on. 
Anti-funky Weapon Interpolation Models 
@Andrew,

I have a set of view models that someone fixed to work better with interpolation, by hiding the muzzle flash under the gun between the frames where it should appear, so it don't look as weird when fully interpolated. This doesn't make it look perfect (there is still some small movements visible), but it is a definite improvement (most notably for the standard nailgun).

I have no idea where I got these.... I've had them for many years.

http://fvfonline.com/vmodels.zip


Uhh, to use those in Mark V, you'll have to make a mod folder and put them in a "progs" folder in there, and run that game folder (but then they'll only work when you run using that game folder), or go to the hassle of sticking them in an extra pak file to drop in your id1 folder so they will always be used... which I'm sure is what you want.

This is a overly-difficult because Baker doesn't have Mark V (like the other advanced Quake engines) give preference to user-inserted drop-in content outside of pak files. But it really should do that, for reasons such as this! ;) 
@dumptruck_ds 
Qrack has cl_autodemo which names demos automatically.
using mapname_date_time as the filename.
cl_autodemo 1 starts recording at mapload and stops at intermission.
Qrack also has bsp2 support with protocol 666 so it will load any map that markv can load.
http://quakeone.com/qrack if that helps for the time being 
@R00k 
Downloaded - will play with it for sure. Looks like you are still updating this regularly. I wasn't aware. 
 
let me know if there are any config issues i can
help you set it up. 
Dwere Did Some Really Nice Weapon Models 
#2466 
Thank you, mate :)

I will surely give it a try. 
 
MH wrote a nifty ‘hack’ to remove muzzle flash polygons
from the original models.
look for gl_clip_muzzleflash here in gl_mesh
https://github.com/sputnikutah/Qrack/blob/master/gl_mesh.c 
 
This hack, IIRC, is pretty much what I described above. It's a good few years ago so I don't remember details, but I'm pretty certain it uses the same logic. 
Quake Giblets: Mark V 
Enjoy! Feedback welcome. I can always do a sequel with more features.

https://youtu.be/dMOF3l2MtlI 
NE_Ruins (Custom Map) 
A terrible freeze occurs if I use "LAST WEAPON" command bound to MWHEELUP, especially when I picked up the Quad Super Shotgun (Looks like super shotgun from Quake 2). Once I use "bind "MWHEELUP" impulse 12" it freakin' freezes. Only task manager helps to shut the game.

Also Mark V shut down once I entered the bridge with Death Knights. 
NE_Ruins (Custom Map) 2 
It's impossible complete this one with Mark V.

I've solved an issue with a freeze glitch discribed above by setting the following cvar :

"sv_gameplayfix_no_impulse12_override" to "0"

but the enemy which uses yellow shield (some sort of a witch) around itself causes the engine to crash. Once it starts to use that kind of attack the engine instantly crashes.

An emergence of this bug was also tested with a default cfg to eliminate a suspicion that something is wrong with setup. 
Mark V Mouse Input Issues 
Hi guys! New to Mark V, but really enjoying it. The only problem is the mouse input issues that others have touched upon recently, and I have a few things to add:

1. My mouse1 button does tend to get stuck not firing or stuck continuously firingas mentioned before, however it doesn't just extend to mouse1:
-mouse2 also tends to have the problem sometimes in the rare circumstance I use it to scope in. It's difficult to recreate by accident but I can do it sometimes if I purposefully mash it.
-mouse4 and mouse5 also seem to be affected. I use them for next and previous weapon, and they often just don't respond at all.

2. These problems only happen in Mark V, like others have experienced. It cannot ever be recreated in any other game, application, or circumstance. It doesn't seem to matter which mouse I use, either.

3. The most interesting thing is the fact that this doesn't seem to affect other types of keys. I never experienced the issue once after remapping my left click to Ctrl in my mouse software. Furthermore, I had previously mapped the side buttons to 1 and 2 instead of mouse4 and mouse5 in my mouse software and until I changed it back to normal I had never had a problem with those buttons in Mark V.

4.It doesn't seem to be a Windows 10 only issue, as I'm running Windows 7.

Hopefully this can get fixed, because I am really enjoying this engine a lot otherwise. It's difficult to discuss issues like this online without others immediately blaming your mouse despite all the evidence to the contrary or just telling you to switch to another engine like Quakespasm :P 
Re: Post 2476 
Errr... that crash bug with the witch resurrecting fallen enemies in NE_Ruins was fixed years ago. I had reported the issue and delivered hints to fix the problem back then. Are you sure you are using a recent build for Mark V? If it's crashing with a new version, then the issue was accidentally reintroduced and requires fixing again. 
Post 2476 
I'm using v1.99 (Revision 4)

From the section "Download Windows .Zip"

"DirectX / GL / WinQuake''

It seems that this bug bug emerges on the newest version... 
Re: Post 2476 
Yay, that means that Baker must have reverted these fixes in one of his last updates. Try using a previous snapshot and see if it works with those. We need to find the build that broke it. 
 
Ne_Ruins was fixed back then in beta 14 of pre-v1.0:

http://quakeone.com/proquake/interims/mark_v_20150428_windows.zip

As you can see, that was back in 2015. The problem back then was "incorrect handling of entities with alpha=0" according to Baker. If he did anything in the meantime that undid this, it's clear why the crashes occur (again).

I am not sure if I had reported the impulse12 issue as well, but when I played Ne_Ruins with that beta build back then, I know I had zero crashes. 
Re Post 2481 
"Mark V - Version 1.99 - Revision 2 (Stable?)
#2092 posted by Baker on 2018/05/08 23:25:05"

Have just tried "Revision 2" from post #2092

Same issue, same occasion.

Game crashes 
Re: 2476 
You will probably need to go back further. It's possible it broke last year or even earlier again... I never checked it a second time after the fix since I assumed it would not break twice. Makes me wonder which of my reported issues are still solved. Gulp. 
Ne_Ruins Crash Reproduction 
So I have tried builds dating back to 1001 (Nov 21, 2016) and it still crashes. This needs investigation.

Please download this savegame for testing purposes (zipped, 66 KB) and copy it into your ne_ruins directory, then load it with F9 ingame.

How to reproduce the issue:
- Go around the corner
- Kill ONLY the Death Knights
- Let the succubus with wings alive and let it resurrect the Death Knights
- Stay in FOV of the succubus, crash will occur eventually

Sad that this problem returns to the stable builds. However, couldn't reproduce the impulse12 crash. I can go back and forth through my weapon inventory without issues. 
RE Ne_Ruins Crash Reproduction 
I have just checked it out following your instructions.
The crash occured immediatly right after the succubus started resurrecting those guys. Yeah, that's pretty inconvenient to have this stuff emerging in stable builds.

Concerning "impulse12" related crash. You gotta have super shotgun and quad super shotgun in your possession.
Try to scroll previous/last/next weapon with any button you assigned to execute that action. The game freezes then. 
Couple Of Things To Mention 
1) When I press "load game" then load the savegame and then press ESC button it shows me "load game" menu instead of Main Menu of Quake. That's a bit inconvinient because I usually accidentally press "Enter" button and load a save game while forgetting to save the game after updating my game progress thus it results in loading an old savegame :D
Is there an option to disable this kind of a "Remember last menu" feature ?

2) If you run across a nailgun ammo box while firing the nailgun - it stops firing for a half a second. Really strange. Same applies for Supernailgun. 
Ne_Ruins 
I think the impulse12 in Ne_ruins would need to be fixed within the mod. It wasn't made with impulse12 support and since that quad shotgun is an extra weapon, it causes problems. I believe s.o. actually made a patch for that, but I could be wrong. The succubus resurrection crash is definitely to blame on Mark V, though.

I also cannot run Ne_Ruins without assigning more memory to it via -heapsize 512000. Otherwise I get a crash right after leaving the intro map (Hunk_Alloc). 
One More Thing To Mention (#2486) 
At the introdution map of Quake, if you don't move your mouse and you go forward (move forward command) the player starts to look down at ladder a bit and if you go back (move back command) to the top the player centers his view back. If you move your mouse at the beginning - this behavior disappears.

Strange stuff, I think there must be a console command to disable such a behavior, but I can't find one. 
Some Questions 
When I go to multiplayer section of Dissolution Of Eternity (or any other mission pack) I don't see any maps of this expansion available for deathmatch or cooperative gameplay. There are only original Quake SP and DM maps displayed. Same for Scourge Of Armagon. Is there any way to make the maps displayed in multiplayer? Because it's impossible to play mission packs in coop or dm modes.

Is there any specific command line to enable creation of directories called "Save" and "Screenshots" inside a corresponding mod folder or main ID1 directory? It would be nice to have Mark V storing savegames and screenshots inside these particular folders. 
A Note To Baker 
You shouldn't remove this command since it is actually used. For example I change my refresh rate between my laptop and stationary PC. On laptop I'm running 60 hz and 100 hz on PC. So I use this - "vid_refreshrate" to set it up. 
Savegames 
It would be nice if Mark V had more than 20 save slots for savegames. 50-100 would be great.
Should be implemented :) 
Is It Sorta Trolling 
 
 
i dont think i have ever saved a game. then again quake is kinda easy by today's standards why do you need more points of continue from point another to during any one map? 
Save Slots 
One simple way to gain more save points is to simply use console command "save".

For example, you can easily type "save 111" in the console and save your progress up to that point in the save file named 111.sav.

Likewise, if you need more save points, simply type another name for the new save file.

Though I must admit that remembering all those save file names can be a hassle. I don't remember if MarkV still allows for "dir" command in console for listing the file names. 
Some Tests 
So I'm stuck with Windows 10, and I guess you are already aware of the audio problems. Having several second lag on all sounds, so havn't been able to work much with MarkV lately.

My most recent map uses a lot of new mdls some with alpha masking. MarkV can handle all except for one. There is a seahorse with masking on the wings and fullbrights intentionally painted on the stomach for glowing effect.

QS and QSS can render it properly:
https://i.imgur.com/IsHhNhI.png

But MarkV will display the fullbrights as solid black:
https://i.imgur.com/m936Lf6.png

Its a shame, as its the only one it won't handle.

Here's hoping that a fix comes along one day. 
Windows 10 Audio Latency 
 
Seems like MarkV is probably detecting palette index 255 as fullbright rather than as alpha. 
Who Cares If 
everybody's running qs

shitbler and its minions

_____

detecting or not detecting 
DirectQ/ QuakeSpasm Style Coloured Lighting 
Hi devs, i have 2 questions/requests:-

1) Is it possible to have a tweak(config) for the intensity of coloured lighting in Mark V to match that of DirectQ/ QS. The colour lighting in Mark V is not as intense and vibrant as it is other two ports. I am using lit and vis file from here:

https://quakewiki.org/wiki/External_Lit_And_Vis_Files

2) Is it possible to tweak settings to get DirectQ style coloured dynamic light effects without QMB effects. Maybe u can add another effect preset that matches DirectQ effects.

Although QMB effects are cool but they do feel out of place of 90's. But the coloured dynamic lights alone feel perfect. 
 
Is it possible to have a tweak(config) for the intensity of coloured lighting in Mark V to match that of DirectQ/ QS. The colour lighting in Mark V is not as intense and vibrant as it is other two ports.

The lighting in MarkV and QS should be identical; they both effectively use the same 2x modulate blend which is capped-off (and saturates to white) at double intensity.

There are areas in even stock ID1 maps where this is a significant factor.

DirectQ used a custom HDR texture format which required unpacking in pixel shader code, and which had neither capping nor saturation. The idea was to store some extra data in the (otherwise unused) alpha channel of lightmap textures to fill in the extra dynamic range. Typically you'd see examples storing an exponential or multiplicative factor in there; I put a division in because I tried everything else and that was what looked best (in the context of Quake lightmaps, that is).

In a fixed pipeline engine it would be possible to trade an extra bit of precision and do a 4x modulate, capping at quadruple intensity. That's actually OK because 4x in 8 bits still beats software Quake's 2x in 6 bits. However it would rule out support for single TMU cards (you could gracefully drop back to 2x via glBlendFunc (GL_ONE, GL_ONE) however, but the very first generation of consumer cards may not support that blend mode). Other texture formats such as RGB10A2 would also work well, assuming you were happy to set OpenGL 1.4 as a minimum requirement.

Personally I think these would be all reasonable tradeoffs - there comes a point at which continued support for dead hardware contributes a net negative - but I'm not the developer of Mark V. 
@mh 
I'm more a fan of e5bgr9, as it can also be used by a fixed-function pipeline (although requires a gl3ish gpu) without extra scalers, doesn't require any manual interpolation, still allows for up to 4000-fold overbright (ish), has higher precision than rgbx8, and uses the same ammount of gpu memory as rgbx8 (half as much as half-floats would). etc. If you're lazy you can just hardcode the exponent and get 4x overbright with the same precision as rgbx8 would get with 2x overbright. And if you're not lazy then you can get more precise dark areas alongside insanely bright areas.

does anyone still use a gpu older than gl3?.. 
 
I personally consider D3D11 to be entry level these days, it's a ~10-year old API. GL versions do lag for some vendors, however. GL3.2 is probably a reasonable minimum.

I find it better to do lightstyle animations on the GPU, and dynamics with extra additive blending passes. I've coded it up in GL1.5 assembly shaders, GL 2..4 GLSL, D3D9 HLSL and D3D11 HLSL for Q1, Q2 and H2 so I'm quite satisfied that the approach is solid. 
 
The difference in lit rendering between MarkV and QuakeSpasm, DirectQ could be the LightNormalize function which does:

lit = lit * (greyscale / max(lit.r, lit.g, lit.b));

so max(lit.r, lit.g, lit.b) needs to be equal to the greyscale value, or the final rendering will be different from engines that don't do this. If the lit files from https://quakewiki.org/wiki/External_Lit_And_Vis_Files don't have that property, this will be causing the difference you're seeing. 
31 posts not shown on this page because they were spam
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.