- Group:
- Trial Member: Trial Members
- Active Posts:
- 4 (0 per day)
- Most Active In:
- Fangaming Discussion (3 posts)
- Joined:
- 09-April 13
- Profile Views:
- 1522
- Last Active:
Apr 10 2013 05:28 PM- Currently:
- Offline
My Information
- Age:
- 23 years old
- Birthday:
- March 17, 1992
- Gender:
-
Male
- Location:
- Alicante, Spain
- Interests:
- Computer Engineering (programming, networking...)
Contact Information
- E-mail:
- Private
Previous Fields
- Project:
- Sonic The Hedgehog in Unity 3D
- National Flag:
- es
Latest Visitors
-
nineko 
16 Mar 2015 - 18:20 -
jumpman 2121 
08 Jan 2014 - 12:17 -
Amnimator 
20 Apr 2013 - 01:42 -
Green Snake 
17 Apr 2013 - 07:39 -
TheKazeblade 
10 Apr 2013 - 15:23 -
Damizean 
10 Apr 2013 - 13:58 -
SeanieB 
09 Apr 2013 - 18:42
Posts I've Made
-
In Topic: Sonic Fan Remix
10 April 2013 - 01:53 PM
@Deef
All inputs should normally be managed inside an Update() method, and normally all forces should be applied inside fixedUpdate() method. In many cases you want this behavior: "When I press X, then something simple occurs". "Something simple" would be do the character execute a single movement like a punch or a kick, that will only trigger a sprite animation function. It would also works with a single force addition to that character. In those cases, we can get the inputs inside Update() and execute the animation or add that single force to the Rigidbody that is the character. But when you want to apply some kind of continuous force, like Sonic's progressive jumping, then fixedUpdate() is the choice if you want a coherent behavior. Yes, you could store a bool that contains if the user is pressing the button or not inside Update() and then checking its value inside fixedUpdate() and apply forces accordingly, but that is useless, since the game execute fixedUpdate() in a different rate than Update(). So you can get the inputs inside fixedUpdate() with the same results.
I think the delay you are talking about would be caused for one or two reasons:
- The physics timescale. By default, it is at 0.02, meaning that will be 1/0.02 = 50 fixedUpdates per second. If the game is running at 100fps, then each two screen frames would reflex one physic update. As higher physic timescale is set, higher would be the difference between the updates (more delay is appreciated).
- If you have excessive forces applying, mesh renderers with colliders and that physics stuff, it is possible that the physics engine couldn't follow the physics timescale setting in an strict way. That means that fixedUpdate() may be called “whenever as possible” and not each 0.02 seconds (by default).
I hope this has made things clear for you
- The physics timescale. By default, it is at 0.02, meaning that will be 1/0.02 = 50 fixedUpdates per second. If the game is running at 100fps, then each two screen frames would reflex one physic update. As higher physic timescale is set, higher would be the difference between the updates (more delay is appreciated).
-
In Topic: Sonic The Hedgehog in Unity 3D
10 April 2013 - 12:33 PM
Thank you for the information!
And thanks to Mercury for the sprite equidistant strip
(I give thanks here because that thread is already closed)
Friends
KernelSys hasn't added any friends yet.

Find My Content
Apr 10 2013 05:28 PM
Male