evilC wrote: ↑29 Jun 2018, 12:27
I had a little play, but did not alter any of my pointer settings, however it seemed to work fine.
I couldn't really work out how to change the options after the initial run, I am also not sure why it needs to re-create the file, or also what is with the "will only work on this computer" message?
Also not sure why you need to mess with the pointer settings, I guess maybe because you are working with pixels (Cursor) not mickeys (RawInput)?
Functionally though (in terms of the physics implementation) it's really good.
I have a renewed interest in this subject as I came across a disabled gamer who was interested in this kind of tech, but wants to be able to set up a glide, then tweak it while it glides - ie a 2nd pad or something, but this is for 1st person shooters, so manipulating cursor position just ain't gonna cut it.
Now that I have AHI, the optimal solution seems to be your physics logic with my input manipulation techniques.
Great questions eC I will add them to a FAQ section.
How can I change GGGlide glide parameters?
Anytime you want to change GGGlide glide parameters you have to run GGGsetup and modify them via its GUI.
Why is a new GGGlide file created every time I run GGGsetup?
Using numerical values instead of variables make GGGlide run faster. So GGGsetup has a template, fills in any numerical parameters required and outputs the newly created GGGlide file. This happens every time you make changes via GGGsetup.
Why shouldn’t I copy a GGGlide script from one PC to another?
One of the baked-in GGGlide numerical parameters relates to the tick length of the time keeping counter and is CPU dependent. So a GGGlide script created in one machine is not portable to another.
If you want to replicate a GGGlide config you should copy the “.ini” file and GGGsetup to the new PC and run GGGsetup again. This will reproduce the same GGGlide experience (or you could note the GGGsetup parameters and enter them manually via the GUI).
Why modify the OS pointer settings?
When you alter the Windows pointer settings, the OS takes the pointing device input and scales it accordingly. Say the device reports displacement X and given your pointers Windows“sensitivity”, for example, it scales that to 0.5*X or 1.5*X (other settings affect things like pointer acceleration). Using the default settings suggested by GGGlide the OS does not interfere with the pointing device output, it is 1 to 1.
This way you eliminate some variables from the physics equation.
Also, usually these settings are used to increase the reach of the pointer (by increasing pointer sensitivity) but at the cost of fiddly short distance navigation. With GGGlide you are covered for long/medium pointer displacements and you might as well enjoy an increased short distance resolution and range of hand motion.
All that being said GGGlide works fine with any OS settings. It boils down to reproducibility and sharing of configurations.
I have never investigated how the RawInput "units" are derived. I do not know if the OS pointer movement modifications occur at Rawinput level or not. If it does not occur it could pose an issue with Rawinput data as they do not translate faithfully/linearly to on-screen pointer motion perceived by your eyes which must be extremely confusing to use and configure. On the other hand, if the OS scaling does occur at Rawinput you get the same issues as pixel-based data and modifying OS settings might be a good idea.