Sonic and Sega Retro Message Board: KernelSys - Viewing Profile - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help

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:
User is offline Apr 10 2013 05:28 PM
Currently:
Offline

My Information

Age:
23 years old
Birthday:
March 17, 1992
Gender:
Male 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

Posts I've Made

  1. 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 :)
  2. 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.