search

kgsensei / NitroTypeHack2

An easy-to-use, working NitroType hack for typing at insane speeds! [~200-4,000 WPM] [~100% Accuracy]
Other
43 stars 51 forks source link

WPM seems to depend on FPS of program #32

Closed eclipse1408 closed 3 months ago

eclipse1408 commented 6 months ago

Describe the bug WPM seems to depend on FPS. The WPM seems to get closer to what the title indicates as FPS increases. Clicking in the screen or pressing alt seems to break the program; it stops typing. To Reproduce Steps to reproduce the behavior:

  1. Go into program
  2. Set WPM to any number; for example 169

Expected behavior WPM is at or around 169, the WPM number. Screenshots This really depends on hardware, there isn't any way I can think of to record this issue.

eclipse1408 commented 6 months ago

nvm i forgot to read the disclaimer the variation in WPM is still really extreme though, at a lower FPS the WPM drops from 169 to something in the 80s. I think this might be a program issue, since my computer isn't exactly the worst. image image

kgsensei commented 6 months ago

Thanks for this information, it's definitely a program issue. I don't know enough to resolve it atm. I'm working on a lot of other projects so I wouldn't expect this to be resolved anytime soon.

eclipse1408 commented 6 months ago

Okay, thanks. Also, is a linux version possible? More specifically arch.

kgsensei commented 6 months ago

No, it's made in C# and uses windows components. Sry :(

Soilman38 commented 6 months ago

it could be worse, as i don't even know how to get on the kack...

kgsensei commented 5 months ago

@eclipse1408 Have you tried side loading the cheat onto Proton or using WINE for Linux? It's possible it still won't work because it's a WPF (windows presentation framework) app.

On that note, I found some more information regarding the inconsistencies with WPM and frame rate.

Calculating the framerate from the UI thread is difficult. WPF decouples the UI thread from the render thread. The UI thread will render: Whenever something is marked as dirty and we drain down to Render priority. This can happen more often than the refresh rate. If an animation is pending (or if someone hooked the CompositionTarget.Rendering event) we will render on the UI thread after every present from the render thread. This involves advancing the timing tree so animations calculate their new values. Because of this, the CompositionTarget.Rendering event can be raised multiple times per “frame”. We report the intended “frame time” in the RenderingEventArgs, and applications should only do “per-frame” work when the reported frame time changes. Note that the UI thread is doing many things, so it is not reliable to assume the CompositionTarget.Rendering event handler runs at a reliable cadence. The model we use (decoupling the two threads) means that the UI thread can be a little behind, since it is calculating animations for a future frame time.

Source

It's possible that you could move the typing logic to a separate thread (I believe it's in the render or app thread rn). I don't know enough about WPF apps to provide a solid solution unfortunately.

kgsensei commented 3 months ago

@eclipse1408 In the version I'm currently working on (4.6) I switched from WPF to WinForms, which means... I think it would be possible to add some kind of timer into the app to make sure all the letter functions are run at fixed intervals, which would then fix the WPM offset problem. It seems like it would be a lot of work though and I don't think the benefit is ultimately worth it. The current source code is in /src/ and if you want to make some changes to add the timer I'm happy to merge it. I'm going to go ahead and close this issue as not planned but by all means, if you think you can do it, go for it!

Edit: Just to clarify, version 4.6 is not available via download yet, you'll have to compile it from source.