search

multitheftauto / mtasa-blue

Multi Theft Auto is a game engine that incorporates an extendable network play element into a proprietary commercial single-player game.
https://multitheftauto.com
GNU General Public License v3.0
1.37k stars 423 forks source link

Weird camera movement in the map editor #763

Closed NoType1 closed 5 years ago

NoType1 commented 5 years ago

Describe the bug The freecam has very weird and snappy movement. So if you try to move your camera, it feels as if it is being snapped into place instead of moving smoothly (like it used to be)

To reproduce

Steps to reproduce the behaviour:

  1. Go to local map editor (it can be in a server as well)
  2. Move camera around when its in the freecam mode

Expected behaviour A properly functioning freecam with no snappy movement. (I'm reporting this on the behalf of lots of other mappers, including myself) The bug does not occur when you press F for the cursor mode.

Version MTA 1.5.6 Latest build. OS: Windows 10, 8.1 and 7

Additional context I hope that someone can find a fix for this. It is very frustrating, and totally demotivating. This has all started after the latest update.

NoType1 commented 5 years ago

Here's a screenshot of my settings image

Aqu1L commented 5 years ago

I've got the same problem, reinstalling MTA & GTA didnt help. +More mappers have this problem :c

Wolfee-J commented 5 years ago

Set FPS limit to 60, at-least for me 30 FPS has been slower then normal with the latest updates.

NoType1 commented 5 years ago

Set FPS limit to 60, at-least for me 30 FPS has been slower then normal with the latest updates.

Sadly that doesn't work either.. I have reinstalled my mouse drivers, people have reinstalled MTA and GTA SA. Nothing seems to work.

moon91210 commented 5 years ago

I can confirm the camera is broken. All the mappers I talk to have the same problem, they're all on different computers and servers too. Everytime I want to help out my buddy with a map I get reminded that the camera is broken and that I just can't work with it at all.

Wolfee-J commented 5 years ago

Would you mind trying this - https://github.com/CodyJL/Editor-2 and seeing if the camera movement is the same? (narrows down if it's related to MTAs editor or something internal)

moon91210 commented 5 years ago

Cody, your camera behaved the same when I tested your resource. Are you using the freecam resource by any chance? That's what the mta editor is using.

Wolfee-J commented 5 years ago

I was just verifying there wasn't a recent update with the editor because this uses a modify version of 'Freecam'. I will look into what is causing the delay and report back.

NoType1 commented 5 years ago

Your camera also behaved the same for me. Did you have any luck in finding the bug?

Wolfee-J commented 5 years ago

I believe this - https://github.com/multitheftauto/mtasa-blue/issues/643#issuecomment-443262422 is related.

Deltanic commented 5 years ago

That issue is a graphical glitch and has nothing to do with this. This issue is is related to imprecision in onClientCursorMove. In fact, I would argue the current situation might be a hack since there is no better alternative. Dumping the values of aX and aY of the code here at a constant mouse moving rate yields a sequence similar to the following: 3, 4, 3, 3, 4, 3, 10, 3, 4, 0, 3, 3, 4, 10, 4, 3 Obviously, these outliers cause the glitchy feel to the freecam.

Also related: the onClientMouseMove event is called more frequently than onClientRender. This may cause some jitter too, since onClientMouseMove could be called twice per frame, causing the camera to update twice before it is visibly rendered.

My guess is that the outliers within onClientCursorMove are caused by irregular repositioning of the cursor, allowing the mouse to move further away from the screen center before it is recentered. Not sure what the cause of that is, though.

Is it perhaps technically viable to implement a function that is able to get the mouse movement speed without relying on the repositioning, possibly as a control state? Such a function would inherit the mouse sensitivity from the game, and allow use in onClientRender, effectively solving both issues.

MegadreamsBE commented 5 years ago

Proper interpolation could smooth things out then (consistent timing between moving between two camera positions).

Wolfee-J commented 5 years ago

I'm creating a new freecam system at the moment. However the screen tearing is still related because it makes the issue stand out a whole lot more then it initially would have.

On Sun, Dec 9, 2018, 10:21 PM MegadreamsBE <notifications@github.com wrote:

Proper interpolation could smooth things out then (consistent timing between two camera positions).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/multitheftauto/mtasa-resources/issues/134#issuecomment-445651543, or mute the thread https://github.com/notifications/unsubscribe-auth/AmWIt0kHocbKiuQWCHKaji69H6n1cmQMks5u3dNUgaJpZM4Y9d_- .

Deltanic commented 5 years ago

Just because it makes it more annoying doesn't mean the issues are related to one another. One is a graphical issue, the other is an input issue.

Wolfee-J commented 5 years ago

This issue came into knowledge due to that issue. They are related in the sense that that one mixed with the precision causes this issue. Precision alone is not as noticable without the screen tearing.

On Sun, Dec 9, 2018, 10:31 PM Deltanic <notifications@github.com wrote:

Just because it makes it more annoying doesn't mean the issues are related to one another. One is a graphical issue, the other is an input issue.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/multitheftauto/mtasa-resources/issues/134#issuecomment-445654559, or mute the thread https://github.com/notifications/unsubscribe-auth/AmWIt8btDwo6hLwNRmFQgIG2AN6Brf3Oks5u3dV6gaJpZM4Y9d_- .

NoType1 commented 5 years ago

So is there a way to fix this properly? I'm sorry, I'm not a scripter. A friend told me where to report this issue. I really appreciate you guys trying to figure it out though :)

Wolfee-J commented 5 years ago

I'm doing an updated freecam system for my new map editor and I'll summit a patch to the current editor as soon as it's done. (Or better idea would be to use my editor when it's done)

Dutchman101 commented 5 years ago

If your definition of "snappy movement" is the precision of your cursor (for convenience of understanding, let me describe it as the amount of pixels your crosshair moves per tiny movement, aka lowest possible sensitivity).. then I can confirm that it behaves exactly the same on 1.5.5 r14281.

I carried out my test with different mouse sensitivity setting values, and found no significant difference. I also confirmed that the auto-updater didn't override my build number while testing (anyone planning to try reproduce really needs to pay attention, you cannot really launch 1.5.5 more than once), therefore I am confident that no recent change in MTA has caused it, atleast for my configuration: Windows 10 1809 with AMD/ATI and the latest drivers for my R9 290 GPU. The reason I describe this is that because if it's unlikely to be a recent change in MTA, it may aswell be a driver or OS problem and introduced with an external update that may affect MTA/particular games.

My test was a couple of weeks ago, I'm not sure about the exact Win10 build number or GPU driver version at the time, it could aswell have been Win10 1803. I don't have access to an PC with earlier builds of Win10 and I really think the combination of that and downgrading GPU/other drivers a few times is the ideal reproduction test case. I hope that there's others willing to do that, and compare results, preferably someone who also regularly maps and therefore knows how it's supposed to feel: I am not, and if I were to start using freecam now, I wouldn't be able to tell that it's supposed to have a higher precision or is less than ideal, it doesn't seem way off to me. But of course, vice versa it's even possible that my specific hardware/driver configuration makes it so that I'm not even affected to begin with, invalidating all of my observations; I think it's a good idea that someone experiencing the problem records it on video.

qaisjp commented 5 years ago

I think I am experiencing this as well, but I can't tell for sure.

NoType1 commented 5 years ago

@qaisjp @CodyJL any luck on fixing the issue already? I honestly don't think it's linked to drivers..

qaisjp commented 5 years ago

Can you install https://nightly.mtasa.com/mtasa-1.4.1-rc-7382-20150731.exe and see if you can reproduce this issue? I am seem to be experiencing the issue with that version of MTA as well.

StifflersMom commented 5 years ago

I also have this issue (Windows 7 x64), the 1.4.1 works like a charme, the actual 1.5.6 moves crappy ...

qaisjp commented 5 years ago

Do you think you could record a video demonstrating the difference, @StifflersMom? It would be really helpful (please)!

On Tue, 8 Jan 2019 at 20:33, StifflersMom notifications@github.com wrote:

I also have this issue (Windows 7 x64), the 1.4.1 works like a charme, the actual 1.5.6 moves crappy ...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/multitheftauto/mtasa-resources/issues/134#issuecomment-452441734, or mute the thread https://github.com/notifications/unsubscribe-auth/AA4WajYDRgdHjIj5llR78FiNux9i685vks5vBQCOgaJpZM4Y9d_- .

StifflersMom commented 5 years ago

2 videos with map editor, moving the mouse like a sine form (up and down), then try to target some objects: https://www.youtube.com/watch?v=wEtESDe1StM (1.4.1) https://www.youtube.com/watch?v=jfy8pDwJAPc (1.5.6)

It's very difficult to demonstrate it with a video, also my mouse has no a high resolution, but you may see the laggy movement with 1.5.6

NoType1 commented 5 years ago

I can totally tell the difference between 1.4.1 and 1.5.6

qaisjp commented 5 years ago

@Deltanic has narrowed it down to r14746. r14744 works fine for him.

https://buildinfo.mtasa.com/?SHA=&Author=&Branch=&Revision=14746

So this is likely caused by bc940094f0d910eea90319260644adecc6292b3c (cc @ccw808)

KnOwNmta commented 5 years ago

Hello, Please, It would be kind of you to look after the problem and get it solved as soon as possible. I'm managing a Discord Community for mappers in Multi Theft Auto and a lot of people, if not everyone is struggling and pissed off. We all have projects to finish but unfortunately, we can't bear with the current state of the editor. We appreciate your work!

zatley commented 5 years ago

Please fix, I can't finish my feat with Vortex right now!!

qaisjp commented 5 years ago

OK, in 6 or 7 hours try the latest nightly.

If you do not have a nightly build:

  1. Start MTA
  2. Click Settings
  3. Click on the Advanced tab
  4. Update your build type in the "Auto updater" section

Please report back and tell us if this fixes your problem. Also please tell us your graphics configuration.

NoType1 commented 5 years ago

Thank you very much for trying to resolve this issue

qaisjp commented 5 years ago

Okay, @NoType1 @zatley @KnOwNmta please tell us:

If the auto-updater doesn't work after following the instructions here: https://github.com/multitheftauto/mtasa-blue/issues/763#issuecomment-452858308, you can click here instead.

1thwonder commented 5 years ago

Latest nightly update didn't fix it for me. GPU: GTX 970

ccw808 commented 5 years ago

Please confirm which version you tested with by pressing F8 and entering the command: ver

botder commented 5 years ago

Please also try the test branch with a solution without the reverted commits. You can get the build here: MTA:SA Test Builds under feature/test-message-loop.

Download link for the Windows MTA:SA client: https://nightlytest.mtasa.com/download?type=windows32&branch=feature%2Ftest-message-loop&hash=a4a09aed0880d1e923c945c93e579e5626aeda21

Note: Test builds do not include the default resource package, you have to copy these.

1thwonder commented 5 years ago

I tested v1.5.6-release-16256.

1thwonder commented 5 years ago

Test Branch build fixed it for me. (Multi Theft Auto v1.5.6-custom)

NoType1 commented 5 years ago

Tested v1.5.6-release-16256 with a GTX1050Ti, that did not fix the problem for me either

botder commented 5 years ago

@NoType1 Please test the test branch build above.

NoType1 commented 5 years ago

@botder the test branch build fixed it for me as well! :)

KnOwNmta commented 5 years ago

@botder The test branch build fixed it for me. The latest nightly didn't @qaisjp

GPU: NVIDIA GeForce GTX 1060

StifflersMom commented 5 years ago

@botder The test build fixed it for me, too.

Multi Theft Auto v1.5.6-release-16262 moves much smoother, setting fps to 25 in map editor does not freeze the movement.

Multi Theft Auto v1.5.6-release-16257 moves totally laggy, setting fps to 25 in map editor freezes the movement mostly for some seconds, sometimes for more than 10 sec.

GPU: Nvidia GTX 660

edit: I checked the 16262 against the test build more times now, the 16262 moves good but the test build moves perfect. Also there are no movement dropsin map editor if I set fps to 25 with the test build. If i set fps to 25 with 16262, there are drops in movement in map editor.

ccw808 commented 5 years ago

@1thwonder @NoType1 Please test with https://nightly.mtasa.com/mtasa-1.5.6-rc-16262-20190110.exe

1thwonder commented 5 years ago

Multi Theft Auto v1.5.6-release-16262 seems to be working fine, I think you've solved it.

NoType1 commented 5 years ago

@ccw808 Yes! It works. It feels very smooth again. Thank you very much :)

ccw808 commented 5 years ago

As the test branch has slightly better results according to StifflersMom, I think we should revert 61fccbc (Revert "Refactored frame rate limiter") and merge a4a09ae (Add extra message loop in idle handler)

qaisjp commented 5 years ago

Sounds good to me. @botder if you're happy with that please go ahead :slightly_smiling_face: :tada:

Wolfee-J commented 5 years ago

Can someone test to see if https://github.com/multitheftauto/mtasa-blue/issues/643 has been fixed? Sounds like this could very likely have been related.

TemaSM commented 5 years ago

@CodyJL I finished testing (will attach dxdiag report to corresponding issue). Problem still occurs 😢

patrikjuvonen commented 5 years ago

These fixes were never supposed to fix screen tearing and any discussion should be moved to the corresponding issue at #643. Locking this issue.