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
@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. 
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.