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.
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.
@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
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.
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?
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.
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.
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
If a working link or someone still has the "Noir" variant of this game, let me know or DM me it. So i can proper archive it.
Since the thread was revived, what is pelikan13 doing these days? Did he release his Streets or Rage inspired game? 90's racer still is never seeing light of the day, right?
Awesome thanks, leaving this Link here then for anyone else stumbling upon this forum topic https://scaleyfoxy.weebly.com/sonic-fan-remix.html
When I wrote the script to this episode of Game Facts Special, I read every post from this thread and did a ton of research with Way Back Machine. I'm surprised most of the front page posts from Sonic Retro about Sonic Fan Remix were removed overtime, along with front page posts about the Sonic 4 refund contest. Really proud of how this episode turned out. @Mercury provided a lot of info to me about the game when I wrote the script. I would have loved to contact Pelikan for additional information about the game, but Mercury could not get in contact with him.
Great video. This is probably a stupid question but does anyone have the link for the modded version of Sonic Fan Remix that adds tails, chemical plant, and the drop dash? I’ve only been able to find a download for fan remix’s mobile port
Thanks for the compliment. What you asked was not a stupid question. When I wrote the script, I did not realize the guy who made that mod of Sonic Fan Remix ever publicly released it. I sent him a tweet on Twitter about it, but I never got a response.
I can't believe that there are those who were willing to put time and effort into reviving a instant classic scrapped sonic fan game such as this one.
Beatz has only released the Android port but not a build with additional content. A lot of stuff he shows off is usually never released, either because it's not meant to be or he moved on.
When I wrote the script, I did not realize the mod never officially released. The Android version did add a few additional features, like Tails (without the flying functionality), item boxes, and a small options menu. If anybody here has additional questions regarding anything said in the video, feel free to ask me.
