koobas.hobune.stream
After exporting my project from my PC to my laptop the physics of my game work differently.
I am currently working on a project which involves a lot of physics. I used to do this on my PC but I would never get above 20 fps in a scene which involves just my character and an environment. This was because my PC was really bad and ran most games on lowest settings on about 20 fps. Because of this I recently bought a good laptop which runs most games on high settings with at least 60 fps. After exporting my project to this laptop (I did this by copying the Assets and the ProjectSettings folders to a USB stick like suggested in this link) the physics are all messed up. For example, I have a self-made rigidbody fps character. I control it by setting the velocity to the horizontal and vertical axis. I also calculate what part of the velocity was a result of the player input and what part of it was a result of outside forces. This way my character always has the same influence on his speed. The outside forces can be infinite. On my laptop my character is about a 100x as fast and it keeps acceleration forever. What seems to be the case is that the script recognizes the player input as an outside force and because of that the velocity can become infinite.
However, when I stop charging my laptop and it goes into what I think is a power conservation mode, because when I do it while gaming I have to turn down my settings a little bit, my game works exactly the way it worked on my PC. However my fps is around ten for some reason.
After I opened a script in Visual Studio for the first time it asked me if I wanted to change my line endings to windows(I am developing a game for windows). I did this because I always received errors about it in the console windows. I think this might be what caused it. since it could have changed my script. However looking though it they seem the exact same. Because of this I am really desperate and I would really appreciate it if someone could help me.
Thank you in advance.
I'm thinking about everything else you're indicating, but I thought I'd deal with this one point:
The line endings is not an issue.
The line endings complaint is about a difference between the way all other operating systems declare the end of a line and the way Windows does it.
For text files, there is a character value of 10, known as a line feed. This dates back to the 60's, when paper output was common (that is, there was no display, the display was printed on paper), and continued through line oriented text printers through the 80's. When CRT monitors replaced paper based devices, line feed continued to represent a new line of text, and instructed text oriented printers to move the paper one line up.
The printer devices in the 60's were basically automated mechanical typewriters, with a carriage holding the paper. The term "carriage return" applied to the mechanical typewriters dating from the 19th century, but the printing technology used in the 60's moved the typing mechanics left to right, ins$$anonymous$$d of moving the carriage and the paper from right to left as one typed.
The term carriage return survived into the computer era as a command to move the typing mechanism to the left of the page, the same action as a carriage return on typewriters of ancient style. As a result, the carriage return character, value of 13, is an instruction to move the carriage from where it landed to the left most position of the page.
This didn't necessarily mean, however, a new line. As a result, to print, the command to move the paper up one line, the line feed (10), was usually followed by a command to move the printing mechanism to the left with a carriage return (13).
In UNIX, dating from the 70's, and thus most all other operating systems of the modern era, the value of the line feed was considered the end of a line of text.
$$anonymous$$icrosoft, however, decided that their operating systems should include both the carriage return and a line feed.
That is what the "line endings" refers to.
In UNIX, if output to a printer was indicated such that one simply sent the output of a text file to a printer, the operating system would automatically instruct the printer to perform a carriage return whenever UNIX saw a line feed.
$$anonymous$$icrosoft wanted the FILE content to do that, so they didn't have to write code to interpret text files when sent directly to a text printer.
All of which is archaic and irrelevant in today's devices, except that some standards, now based on these histories, survive to annoy and confuse.
The difference of the line endings means nothing to the compilers, and doesn't alter the meaning or even the appearance of your text in the least.
It sounds like you are changing your players velocity in Update(). Try moving it into FixedUpdate() and it will become framerate-independent and should function the same regardless of your FPS.
Edit: Actually, since you are also detecting input you might try leaving it in your update method which is what im assuming you're using and try multiplying your final velocity by Time.deltaTime
$$anonymous$$oving it from update to fixed update helped. What helped with input was moving the part where the velocity was changed to fixed update and keeping the rest in update.
