You shouldn’t have to change the fps in the editor. Try and use
_process() instead of
_physics_process() for this and let me know how that works.
This is odd though because I do something with this in physics_process() and don’t have any issues so idk how fast you’re moving your mouse to be seeing gaps haha.
No works, i an moving fast the mouse, and get jumps, like from 51,14 to 60,30.
PeterPM | 2020-10-26 15:23
Are you talking about the output from the
print() function? Because that may not be accurate.
What is your goal with this? I can’t think of a scenario where you would need the mouse position to update faster than the frame rate.
scrubswithnosleeves | 2020-10-26 15:31
The print function is acurate, but even if it is not, my inference of the problem was when i was tring to ajust a object to the cursor.
There was gaps in the ajustment, that indeed reflected acurately with the readout of the print function.
I cant have only some updates, i need for every mouse cordenate change, to have a update… I KNOW, that is not how things work, there is indeed a “framerate” to digitalize the input coordenate, just like a sound DAC converter would do, inferecing the analog position in a fixed interval, and reporting it.
I am going to start debuging that by using macro to determine the rate of inference, and see if i can get to the root of the problem.
The thing is, it is obviously that the input function is conected to some clock, and that clock is my problem. I need to change the report interval of the readout, to some criticaly intensive mouse input.(and if i can get to that control, maybe others intensive input as well.)
PeterPM | 2020-10-26 15:39
This is a snipet of the dump. Look at the stream when i try to make a fast circular motion. Its all trunketed, this is what i am talking about.
Anyone, please, any ideas?
This is the dump when making a slow line with the mouse, it works flawless, but as stated, fast motion do not produce acurate results.
PeterPM | 2020-10-27 02:17
That’s probably because you are moving faster than 1 pixel per frame. Nothing you can do about that, even if you make the frame rate like 240 fps or something your game will be super slow and you could still move the mouse faster than 1 pixel/frame.
I also cannot reproduce this latency with an object following the mouse. you also might be trying to solve the wrong problem, maybe there is another way to get the result you want without having to adjust this.
Try posting more about what you are actually trying to do gameplay-wise. Are you trying to have a player follow the mouse?
scrubswithnosleeves | 2020-10-27 12:15
I need to map every pixel the mouse “walks” by.
If the mapping does not ocur, i do not have the data i need, and the display in the game reflect that missing information.
There must be a way to fix this, and maybe indeed is not by using a faster inference.
Please, if you or anione know how to have a faster inference, it will be perfect.
I will try to make the workarround algorithm, that:
Get input N
Get input N+1
If N+1 have a diference greater then 1 pixel comparing with N:
Create the plot the points bethen N and N+1
THAT, will fix the holes, but will create straight lines that does not really reflect the mouse movement. If making “waves” on can easily goes beyond Nquist limit and create a wave faster then the “cloud” of point, thus, rendering the wave a misrepresentation.
That is what we got, right?
I an still looking for a way to get all the pixels, so if you reader understand how to maybe fix in the hardway, say-it, please.
PeterPM | 2020-10-27 14:47
Yeah sorry man I got nothing. I was just gunna suggest you do what you just said you are already doing which is to interpolate the missing pixels and draw them in after the fact.
You might check out Pixelorama. Pixelorama is a pixel art editor made in Godot that is open source under an MIT license. You could download the source code and see what they did or even hit up the developers.
scrubswithnosleeves | 2020-10-29 13:18
That was the way.
Now i have another problem. Buglike. will make a post.
PeterPM | 2020-10-30 19:49