|
Notes |
|
|
(0005329)
|
|
deathisnear
|
2012-11-07 19:13
(edited on: 2012-11-07 19:17) |
|
Changing the polling rate does not help the issue with my mouse, unfortunately. This problem makes the game quite frustrating at times, but is still a minor problem since very few people have mice that suffer from it.
|
|
|
|
|
|
IIRC this also happens in ZDoom, doesn't it? |
|
|
|
|
|
Not sure how to test it since it still doesn't work offline. Not sure how to make a multiplayer match on Zdoom and join it. |
|
|
|
|
Basically tell is how it works:
1) On Zandronum online
2) On Zandronum offline
3) On G/ZDoom offline |
|
|
|
|
Quote
Not sure how to test it since it still doesn't work offline. Not sure how to make a multiplayer match on Zdoom and join it.
In a command line window, cd to your zdoom folder, then execute:
zdoom.exe -iwad doom2.wad -host 1 -warp 01 -skill 4
this will create a new game which emulates a new multiplayer game with just one player in doom2.wad map01 with skill Ultra Violence. |
|
|
|
|
|
I had a similar problem where mouse 1 and 2 seem to jam. The solution on the most part seems to be to use a polling rate of 500hz or less, but a lot of newer mouses don't work well with less than 1000hz. My mouse was a Roccat Kova+. |
|
|
|
|
1) Happens on Zandronum Online
2) Does NOT happen offline
3) Does NOT happen in G/Zdoom online/offline |
|
|
|
|
Quote from deathisnear
Not sure how to test it since it still doesn't work offline.
Quote from deathisnear
2) Does NOT happen offline
3) Does NOT happen in G/Zdoom online/offline
These two statements contradict. Do you mean "it works properly offline." with "it still doesn't work offline."? |
|
|
|
(0005362)
|
|
deathisnear
|
2012-11-11 16:32
(edited on: 2012-11-11 18:59) |
|
I was doing what Watermelon said, just to make sure it doesn't work offline/online in other ports.
|
|
|
|
(0006365)
|
|
Mynameislol
|
2013-06-06 20:17
(edited on: 2013-06-06 20:18) |
|
This bug is REALLY annoying, i'm playing with a friend and almost every time i play, i blow myself up with a rocket launcher and the map restarts because i died!
I'm trying to play a geniune co-op game, and if someone dies, the map restarts.
It's not fun having infinite respawn, then we would have completed all doom games by now!
Not everyone has an old gaming rig, and not everyone owns 5$ worth of computer gear, i'd like more support for more recent computer gear.
Forgot to add, the mouse feels a bit unresponsive compared to Gzdoom, i have a polling rate of 1000, and it feels like a polling rate of 125.
It would be nice to have direct-input.
|
|
|
|
|
Although i do not suffer from the same problem as Mynameisalol(as i fire/altfire with ctrl and rightshift), i CAN rellate to this sole bug due to the fact that i use the mouse to dodge.
the bug you are discussing never does relate to any keybindings, but SOLELY to the left/right mouse buttons.
one solution would be to bind a key to the mouse buttons, but this is not possible in my friend/gamerbud Mynameislols case as his mouse-software does not
support windows 8 due to some mices non-support in software, which is because microsoft are SILLY BASTARDS who won't allow your mouse to work with win 8
if they are not signed by them.
first this, then the xbox one.
Get your shit together, Microsoft. |
|
|
|
|
Going through the information collected so far it sounds to me as if there are two separate problems:
1. Buttons get stuck. This only happens in Zandronum online. It doesn't happen in Zandronum offline or in GZDoom (no matter if online or offline).
2. Mouse input in Zandronum feels less responsive than GZDoom.
Can somebody confirm this? Furthermore, does the reduced responsiveness in Zandronum compared to GZDoom happen only online or also offline? |
|
|
|
|
|
The reduced responsiveness happens in both offline and online in Zandronum, and there is no reduced responsiveness in GZDoom, not in offline nor online. I have also tested this in ZDoom 2.7.0, and it works just as great as GZDoom. |
|
|
|
|
|
Can you check whether GZDoom 323 is as unresponsive as Zandronum? |
|
|
|
|
|
Nope, GZDoom 323 works great. |
|
|
|
(0006437)
|
|
Torr Samaho
|
2013-06-15 18:17
(edited on: 2013-06-15 18:26) |
|
That's strange. GZDoom 323 and Zandronum have the same mouse code and thus should behave similarly.
EDIT: Did you possibly set some special options in your mouse driver when zandronum.exe and/or gzdoom.exe is used?
And is there anybody else for whom GZDoom 323 works better than Zandronum?
|
|
|
|
|
|
No, i did not set any special options for my mouse driver when zandronum or gzdoom is ued. |
|
|
|
|
|
I've noticed so far that the problem with the firing getting stuck never seems to happen anymore in Zandro online. I still get a problem with the fire responsiveness being a little laggy at time, especially when turning the mouse at a high rate of speed. My polling rate for my mouse is 125 btw. I don't get the issue in GZDoom at all. It may have something to due with the network side and not the actual mouse coding, but that is just my guess. |
|
|
|
|
Quote from Mynameislol
No, i did not set any special options for my mouse driver when zandronum or gzdoom is ued.
Can you test this again with clean ini files for both, GZDoom and Zandronum, and also rename zandronum.exe and gzdoom.exe to something else like test.exe? The latter makes it less likely that your mouse driver silently treats the two ports differently.
Quote from deathisnear
I still get a problem with the fire responsiveness being a little laggy at time, especially when turning the mouse at a high rate of speed.
Do you have this fire responsiveness problem only online? Then it could be a network latency issue. |
|
|
|
|
I don't think it's a network latency issue, as i'm running the server locally, and the mouse feels unresponsive in both Zandronum Online and Offline.
I also did what you tell me to do, and there's no difference. |
|
|
|
|
Quote from Mynameislol
I don't think it's a network latency issue, as i'm running the server locally, and the mouse feels unresponsive in both Zandronum Online and Offline. I was only referring to the fire responsiveness problem deathisnear mentioned. |
|
|
|
|
|
I only have the issue online in Zandro. It could be a latency issue but it still happens on server like Best-ever where I have 30 ping. It happens very rarely but I can still tell it happens. |
|
|
|
|
|
I wish to add that some new mice do not have this odd problem, I have a roccat kone+ and it did not behave differently when I used it, though I got rid of it for some obvious mouse scroll reasons... |
|
|
|
|
|
Are you sure you configured the mouse settings to 1000hz polling rate? |
|
|
|
(0006460)
|
|
Konar6
|
|
2013-06-17 20:07
|
|
|
|
|
(0006537)
|
|
Mynameislol
|
2013-07-01 13:56
(edited on: 2013-07-01 16:17) |
|
Any Progress? Also, i got my mouse drivers working, so i got a temporary solution, i bind the mouse buttons to pgup and pgdn.
|
|
|
|
|
|
No. I have no idea why GZDoom 323 and Zandronum behave differently. As I said before, they should behave the same. And since I can't reproduce the problem with my mice, I can't debug the problem. |
|
|
|
|
|
Why not just buy a cheap gaming mouse? A Logitech G500 shouldn't be very costy, or if you perfer the IntelliMouse Explorer ergonomics, a deathadder. |
|
|
|
|
|
I'm happy with the performance of my mice, so I don't see any need to replace them. And I'm not paying for a new mouse just to debug this issue. |
|
|
|
(0006542)
|
|
Konar6
|
|
2013-07-01 19:03
|
|
|
Does typing "vid_vsync 0" into the console change the mouse behavior for you? |
|
|
|
(0006543)
|
|
Mynameislol
|
2013-07-01 19:13
(edited on: 2013-07-01 19:17) |
|
That sucks. I guess this means zandronum is not supported for newer gaming mice then? There must be a developer that has this problem. Also, vid_vsync 0 did not change the mouse behaviour.
|
|
|
|
|
|
There is a small chance that this has to do with the G15 support. This binary has the G15 stuff removed. Please check if it behaves differently. |
|
|
|
|
|
|
|
|
I'm very happy to hear that! I'll disable the G15 code in 1.1 then, but will need your feedback to confirm that your mouse works as expected when I have finalized the code.
If somebody actually needs G15 support, we can still provide a separate binary with G15 code. |
|
|
|
|
|
Okay, sure! Just a FYI, i've already finished all doom games, including the master levels, so i was wondering if you could recommend me a good faithful map-pack? |
|
|
|
|
|
Update, I've been playing a bit of multiplayer on another computer with another mouse, and the problem is still there. However, it happens less frequently, and the mouse lag is completely gone, but the mouse buttons still get stuck sometimes. |
|
|
|
|
Another update, it seems that the mouse lag is still there, just less of it, GZDoom is still superior here. However, the mouse lag is less than it was before on zandronum. Also, the mouse lag gets worse on software mode, so it's possible that it might be a combination of things that interfere with the mouse settings?
|
|
|
|
|
|
Sounds like this is much harder to test than expected. Are you actually 100% sure that GZDoom 323 and the latest GZDoom version behave the same? |
|
|
|
|
|
Do your buttons still get stuck? If so I have some things you can do. |
|
|
|
|
|
I've gone through this extra carefully this time, and it seems that the newest GZDoom is better than version 323. |
|
|
|
(0006605)
|
|
Dusk
|
|
2013-07-09 00:36
|
|
|
Is GZDoom 323 still better than Zandronum without the G15 code though? |
|
|
|
(0006606)
|
|
Mynameislol
|
2013-07-09 08:10
(edited on: 2013-07-15 19:18) |
|
Yes, GZDoom 323 is still better than Zandronum without the G15 code. However, without it, i feel it's more responsive than before, as the mouse doesn't glitch as much on multiplayer. Another update, it seems that with the test zandronum i got, this bug now also happens in single player as well.
|
|
|
|
|
This builds disables the G15 code in the way planned to be used with the final version of 1.1. Please check if it works as good as the other build I posted before.
Regarding the discrepancies to GZDoom 323: The testing results sound highly subjective and the differences only seem to be minor since it took you extra effort to notice that Zandronum without the G15 code is actually different from GZDoom. Is it possible that Zandronum is just a little slower than GZDoom and thus the mouse input feels responsive? The latest GZDoom version on the other hand is more optimized than GZDoom 323 and thus should be a bit faster which could explain why it feels more responsive to you. |
|
|
|
|
|
Well, i do have this problem with Zandronum, i can't run Zandronum in 66hz, but in the newest GZDoom, i can. The mouse feels alot more responsive in 66hz, so i'm uncertain if there is a difference between GZDoom 323 and the latest version, but i know for certain that there is a difference between GZDoom 323 and Zandronum, because GZDoom 323 can't run in 66hz either. Zandronum has been a bit strange lately, resetting the settings now and then, brightness resets too, it might just be so that Zandronum is very unstable? That might be the issue with the mouse settings and such. |
|
|
|
|
A few of my friends with newer gaming mice are complaining about this issue as well in 1.1.1, so I think the issue has not been solved.
Is this caused by newer drivers? Is there any way to create a debuggable exe that prints out if the button is down, while maybe some external program records mouse output? |
|
|
|
|
Water, are you referring to the "buttons get stuck" problem?
A first step to analyze this issue could be with client side demos. The demo should contain the buttons presses as they are registered by the client. This way we could check if the client actually thinks the player is still pressing the button or if it's a problem on the server. |
|
|
|
(0006823)
|
|
Tiger
|
2013-07-28 00:29
(edited on: 2013-07-28 00:33) |
|
I've also been having this issue with Zandronum since the first stable release. However, I don't fully remember having this issue on SkullTag. I could take some time to test with the ancient SkullTag builds, would this help at all?
My mouse: Logitech G500; using official drivers from Logitech.
|
|
|
|
|
Knowing whether the problem already happened in Skulltag would certainly be helpful.
BTW: Can somebody record a client side demo of the problem with 1.1.1 as I suggested above? |
|
|
|
|
Ok so the following will be happening
I am working with Reck on the mouse issue, this is what we will be doing:
[X] Play on 1.1.1
[X] Play on 1.0
[ ] Play on ZDoom r24... w/e revision we forked off of
[ ] Play on GZDoom 323(?)
[ ] Play on Skulltag 98d
[ ] Play on Zdoom latest
[ ] Play on GZdoom latest
Notes so far:
- 1.1.1 has it way worse somehow, buttons get stuck for him more frequently
- 1.0 is better, but buttons only fail to be sent every 10 seconds or so (might not be a constant wave but approximate failure rate); note there is NO sticking in 1.0 for him
- One of my friends on ZD said he had this problem on both ports and turned down the polling rate, but this drastically damages the mouse playing ability if it's cranked all the way down
|
|
|
|
|
|
I still have the issue of the firing not working in 1.1.1 when doing a quick motion, usually spinning at a high rate of speed. It may be due to too much mouse input signals causing it not to work. Then again that is my guess. It really hurts when you have to do a quick turn to get that archvile or cyberdemon behind you and the firing refuses to work until you click the mouse button again. The issue of the firing getting stuck seems to be gone as I have not had it for a long time now. |
|
|
|
(0006828)
|
|
Tiger
|
2013-07-28 20:18
(edited on: 2013-07-28 20:44) |
|
The testing did not go as well as I was hoping for...
96f:
Could not successfully test
Could not create a stable gameserver; consistently unresponsive
97b:
Could not successfully test
Could not create a stable gameserver; consistently unresponsive
97c3:
Could not successfully test
Could not create a stable gameserver; consistently unresponsive
97d5:
Successful test
The reported mouse issues is also reproducible on this version.
In addition, here's a CLD - but I don't know if this is really helpful. There are times to where I press the mouse keys (for me: attack and jump) - but nothing happens.
Required PWADS: skulltag_actors_1-1-1pk3; skulltag_data_126pk3; d2dm1_126fix.pk3
Requested Demo
*I miss DRDTeam Fileshare :(
|
|
|
|
|
Further tests indicate it is fine for Zdoom 2.x series, but broken on 1.23 and earlier series.
Apparently changing the polling rate from 1000 Hz down to 125 Hz makes the problem go away.
So how is the input handled anyways? Wondering if it's a buffer overflow?
Will find out how 250 and 500 Hz do tomorrow from my friend. |
|
|
|
|
|
Zandronum should behave like ZDoom 2.0.x, so possibly non-code related differences play a role here too. We should definitely check if the VC++ version, the Windows SDK and the DirectX SDK version used make any difference. |
|
|
|
|
500 Hz = working perfectly for him (no more sticking/locking up/anything)
1000 Hz = broken
So I guess the polling rate is responsible. I wish there was a 750 mouse to see if it's a notorious buffer like 512 or something similar. |
|
|
|
|
|
This binary is built with VC++ 2010. Please check if it behaves differently from the VC++ 2005 binaries. |
|
|
|
(0006837)
|
|
Tiger
|
2013-07-29 21:01
(edited on: 2013-07-29 21:04) |
|
Torr Samaho, I am still able to reproduce the issue on that build. The behaviour seems to be exactly the same as from the VC++ 2005 builds.
Watermelon, I've noticed that on 500Hz it is much better, but yet I can still reproduce the 'sticky' buttons just only rarely.
Demo File
Required Files: VC++2010 build (Torr's post above this one), and greenwar.wad
I've used the polling rate of 500Hz in that demo, but test 1000Hz (my default setting) somewhere in MAP02.
|
|
|
|
|
|
Thanks for checking! Can you tell me where (preferably with the corresponding demo_skiptics parameter) in the demo I can see which kind of problems? |
|
|
|
(0006839)
|
|
Tiger
|
|
2013-07-29 21:16
|
|
|
Sure, I'll get back to this tomorrow. |
|
|
|
(0006850)
|
|
Tiger
|
|
2013-07-30 18:36
|
|
Using only the 'Skip_DemoTics' CCMD, the value is 0001541:0011830 tics. Thus, Skip_DemoTics 11830 is where I toggled 500Hz to 1000Hz setting. After a short pause (you'll notice it on the demo), I've then reverted back to 500Hz. Hopefully this helps? |
|
|
|
|
I noticed the pause, but I still don't know what I should look for.
Please elaborate what is supposed to happen in this demo when the mouse would be working properly and what happens instead. |
|
|
|
(0006853)
|
|
Tiger
|
|
2013-07-30 19:07
|
|
The most notable and how I can easily reproduce the main issue; when I spin the view point ridiculously, I am also trying to either +jump (mouse button 2) or +attack (mouse button 1) during the process. If I remember correctly, I could not be able to get Button1 (+attack) to work but I was able to get Button2 (+jump) - which stuck. A simplified version, you will notice that after spinning the view point around, I then begin to +jump several times when I only meant to +jump once. Hopefully this makes sense?
A much more better demonstration would probably be this video.
|
|
|
|
(0006858)
|
|
deathisnear
|
2013-07-31 00:19
(edited on: 2013-07-31 00:20) |
|
|
|
|
|
This may be related:
Input detection appears to respond slower in uncapped. There is a noticeable delay (maybe 150-250 milliseconds) before the mouse movement is actually processed. |
|
|
|
|
|
I don't notice any difference in delay between capped and uncapped input on my machine, so this may depend on the mouse. |
|
|
|
(0006928)
|
|
Konar6
|
|
2013-08-07 18:50
|
|
|
Watermelon: "vid_vsync 0" fixes that for me. |
|
|
|
|
Awesome TY Konar, worked perfectly.
I just tested on odamex and it appears to do the same thing. Is this enabled by default? Or maybe some residual thing left on in my console. I noticed a few other people in the community have it on and probably have never turned vsync on manually. |
|
|
|
|
|
Does this happen in (g)zdoom with the 'vsync' discovery? Does this happen also with other OSes like in linux or macos? |
|
|
|
|
|
vid_vsync 0 does nothing for me. |
|
|
|
|
|
I can confirm this is still an issue with Zandronum 1.2 on Windows 8. I use a Logitech G500, and this has been a problem with every Zandronum release so far. |
|
|
|
|
|
Appears to be fixed in the latest revision from backporting gzdoom features. Needs testing. |
|
|
|
(0007206)
|
|
Tiger
|
|
2013-09-17 20:57
|
|
|
If someone is willing to build: Linux [32bit](server-host) and Windows [default], I'll be willing to test the proposed build(s). |
|
|
|
|
|
I get issues with my Razer Naga Hex mouse, if I set my polling rate to 1000hz or higher. If the polling rate is 400hz or less, it's fine. |
|
|
|
(0007562)
|
|
fuleco
|
|
2013-11-16 13:32
|
|
|
My tracker was closed (http://zandronum.com/tracker/view.php?id=1527). But all my mouse problems was solved when i enabled cap framrate. *cool*. So for everyone polling rate 500 Hz and enabled cap framrate make mouse similar to odamex or zd. *cool* |
|
|
|
|
|
Needs testing? What's there to test? Could i get some clear instructions of what i need to test? I've tried Vsyncing, i've fried capping framerate, i've tried uncapping framerate, none of these work. |
|
|
|
(0008294)
|
|
Qent
|
|
2014-02-28 18:01
|
|
|
|
|
|
I can't test on multiplayer
Connect (v2.0-alpha): 127.0.0.1:10667
Incorrect version. |
|
|
|
(0008298)
|
|
Konar6
|
|
2014-03-01 08:40
|
|
|
You must use the beta executable when hosting the server, too. If you are hosting in IDE, select the right executable in Options -> Directories -> Programs. Or use the command line (zandronum.exe -host). You can also find a beta testing server online. |
|
|
|
|
|
I believe i can confirm this is fixed! A bit of input lag with vsync on, though. |
|
|
|
|
I've recently aquired a Logitech G102 Prodigy mouse, and noticed this issue myself and decided to do some testing.
I found out that the issue is present in all ZDoom versions prior to 2.4.0, meaning that 2.3.1 was the last public version where the same issue was present.
When decreasing the polling rate from 1000hz to 500hz, the issue seemingly goes away.
It's still present in the latest 3.1 alpha build (3.1-alpha-180520-0650).
To be honest, it's really bad, as it can potentially happen all the time when moving your mouse swiftly (SSG swingshots etc.). I'm able to reproduce it very constistently by simply moving the mouse very swiftly while pressing one of the mouse buttons. |
|
|
|
|
|
Can you reproduce this with GZDoom 3.5 (both modern and vintage builds)? If yes, then please make a bug report in the zdoom forum. |
|
|
|
|
Hi, Edward-san. Good to see you.
No, I can't reproduce it in newer GZDoom versions. It was fixed already in ZDoom 2.4.0, however, Zandronum seems to be using 2.3.1's mouse behavior where it's bugged.
ZDoom 2.3.1 and earlier = Broken, buttons get stuck with 1000hz polling rate.
ZDoom 2.4.0 and later = Fixed, buttons no longer get stuck with 1000hz polling rate. |
|
|
|
|
Hi unknownna, sorry for not saying hi before. ':D
This requires some testing on the changes between 2.3.1 and 2.4. I don't know if there are still the svn builds at drdteam, because otherwise we may need to proceed bisecting and rebuilding them, but since the build system has been modernized in the last years, it requires someone who still uses the old system for doing this. |
|
|
|
|
|
|
|
|
|