Sonic Fan Remix

Discussion in 'Fangaming Discussion' started by pelikan13, Mar 13, 2010.

  1. Deef

    Deef

    Member
    695
    0
    16
    Just in the off chance Merc or Pelikan or someone else in the know checks in on this, could someone explain more about that Unity issue with the slight delay in the input? I believe it was something to do with the way Unity updated its physics or some such? Not sure really, I'm just learning about Unity now.

    If anyone knows what I'm on about, was there also a workaround that was ever figured out? Cheers.
     
  2. Deef

    Deef

    Member
    695
    0
    16
    Ok, just discussing this now.

    I think Merc made the mistake of not simply using Update() to catch input, storing it, then dealing with the stored inputs in FixedUpdate().
    That's the standard approach for handling input, and I'm quite sure Unity doesn't drop inputs between Update() calls.

    He talked about a CustomInput handler, but talked about it in terms of running it inside FixedUpdate(). If it's inside FixedUpdate(), it's out of sync with Update(), and Update() is what the player sees and thus registers as "feeling laggy".

    Soon I'll give this the same test I gave SFR. That is, play S2HDa in the background and compare the jumps.
     
  3. KernelSys

    KernelSys

    Member
    3
    0
    0
    Alicante, Spain
    Sonic The Hedgehog in Unity 3D
    @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:
    1. 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).
    2. 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 :)
     
  4. Deef

    Deef

    Member
    695
    0
    16
    1. I think we are all assuming Pelikan didn't deliberately set SFR's physics update rate to something low.
    2. That is possible. However, after experiencing it on my laptop I tried SFR on a friend's beast machine; no difference. This is maybe the best theory though; suggestion that something in its code was simply making FixedUpdate() take too long. People were also reporting very mixed results with SFR, so yes, quite a possibility.

    As for the inputs, something like GetKeyDown() could be missed by FixedUpdate(). That one must be in Update() for accuracy.

    But for GetKey(), which Merc would have been using, I'd say you're right in that it wouldn't make a difference. However it would still be wiser to use Update() and store it, purely for clarity, since getKey() does not mean "Get the state of the key"; it means "Get the state the key was in when Update() was last called, whenever that was." The user could be holding X throughout 3 FixedUpdate() calls and GetKey() will still return false if Update() still hasn't rolled around again. The results are the same, but the reason for those results is clearer if GetKey() remains in Update(). But yes, I believe it's unlikely that input delay could come from this.

    Ultimately, FixedUpdate()/Update()... both should be running faster than a Megadrive on a TV.
     
  5. Is this true that this game was banned by Sega or is this just a rumours on top of developer dropping his project for some other reason?
     
  6. BlazeHedgehog

    BlazeHedgehog

    A "Community Enigma"? Oldbie
    1,464
    6
    18
    Sega has never to my knowledge ever "banned" a fangame, and recently, the official Sonic the Hedgehog social media account even said they were cool with fangames.

    I think Pelikan just got bored and moved on to other projects, namely 90's Arcade Racer.
     
  7. Thank you. :)
    But but Streets of Rage...
     
  8. Covarr

    Covarr

    Sentient Cash Register Member
    4,233
    3
    18
    Trapped in my own thoughts.
    Two stageplays, a screenplay, and an album
    They did send a DMCA notice to that one, but I don't think anyone ever said anything about SFR, or any Sonic fangame, *ever* getting a DMCA notice.
     
  9. Retroman

    Retroman

    Member
    729
    2
    18
    Any news on this? Was thinking of this game from the Sonic Fangames topic.

    Edit: Nevermind, cancelled (Before Page 83 - 84).

    Such a shame as it's a fresh, gorgeous fan-game even in it's wip state (lack of hud, graphics style to be tweaked, bugs, improve physics) and had tons of potential. I do hope Sega hires Pelikan13, Mercury and co for a game, perhaps a 2D classic mobile game?

    Found a working link:
    https://www.fileplanet.com/216947/210000/fileinfo/Sonic-Fan-Remix-Demo