You sir, are a hero! God only knows why Sega has not employed you to work on their team! (maybe because you do a better job than them?) Not a gripe, not by a long shot but somthing I would like to see, in Emerald Hill zone 2 you have rain, can we make the rain bounce or settle on sonic and swashes as he runs? Again great work! Thanks Craig
That'll explain my slowdown: RADEON 9600 Family - 160 - Mid-Range. I still really think that the blue should be toned down, even just if it's just a little.
Let me start by saying this project is both amazing and beautiful. I came across it the day after I had finished playing Sonic 4 into the ground. Then all of a sudden I found myself with an even BETTER rendition of my favorite hedgehog and for that I thank you. That being said, I'm running Sonic fan remix @ 6088x1200 Eyefinity on my ATI 5970 and it is GORGEOUS. Your eyefinity support is almost perfect with only one small problem: http://i149.photobucket.com/albums/s72/xMc...Eyefinity-1.jpg Original image 6088x1200 (Resized by photobucket because I refuse to pay them.) Is there any chance you could include an option to turn off the corner darkening layer? As far as I know this would not be too difficult and would make SFR have nearly flawless eyefinity support.
It's a vignette to make it look all pretty. It wouldn't be too hard for him to make a vignette for larger resolutions or remove it entirely.
One big question I have: Is it possible to decouple the input from Unity's issues (that Merc mentioned a while ago in this thread)? Because this seems to be a really serious issue... SFR's biggest issue in my opinion. Input lag is one thing, yes, but from the 2 machines I have tested on, even when SFR is running at its fastest it still feels very soft when you remember what Sonic 2 felt like. I've tried switching machines, keyboards and screens to see if it was me, but I *think* it isn't. I think SFR just doesn't have the same response time as Sonic 2, even at its best. Do others see this? If it is true, is there a way around it? Because it's the biggest thing holding back SFR imo. It is not the beast of brilliant response that the classics were. The easiest example is near the end of act 1; the diagonal spring that points left after what used to be the last mobius strip of the act. In SFR I have to pay attention to jump that spring after tearing through the mobius strip. In Sonic 2, I don't have to think; it's cakewalk. Another example is simply jumping from quarterpipes at high speed. It is just not possible to do this with consistency. These could just be user-specific input lag issues... but I don't think they are. This does feel like a matter of lag, yes, but not one that is visible to the eye. It just feels like there's a sponge between me and the game. When testing this between laptop and desktop, I started playing Sonic 2 again and suddenly felt the difference in keyboards. I was surprised for a moment at how easy it was to feel that difference in pressing jump when going from laptop keys to fat desktop keyboard keys. That's how sharp it feels playing Sonic 2. Anyone else's thoughts on this?
Input lag could be one factor. Another could be the camera. In SFR, the camera isn't yet completely accurate; it just stiffly puts Sonic in the middle of the screen at all times. In the original games, this often isn't true. Something like this could change the feel significantly, even if the physics are 99% accurate.
Why not ad some options with sliding bars to change the colors and contrast ratios and etc. Then maybe these people complaining about the colors colors will shut up and you can focus on the real elements of the game.
Wow, you eyefinity guys are really lucky That view looks way cool. Regarding the stiff and unauthentic camera, it's already been mentioned as one of the bugs that will need work (I think I remember reading that). I think this game will be 100.1% perfect when it's all done Deef, I've only come across input lag on my weaker computer. But that unity input thing described does seem bogus.
That input lag could be caused by where Pelikan is writing his input functions or whatnot. Unity has a built in Update function that runs once every frame, which can cause problems if you're lagging at all. If that's where he put his input functions, that could be a major cause for issue, depending on what else is in the update part. Pelikan, if that's what you've done, is it possible for you to read your input outside of the Update function?
Pelikan not programmer! Mercury programmer! Ugh ugh. Unity has two update functions, Update (which runs as often as it can) and FixedUpdate (which runs at a fixed interval, which was 50fps when the demo was first released but might be 60fps now since Pelikan mentioned "speeding up the game" (I'm not sure what he meant by that, though)). All of Sonic's physics have to be in the FixedUpdate, because if the framerate dropped too low for some reason, he could move far enough in a single frame to pass through enemies, walls, etc, and that would be bad. The way I wrote the scripts, Sonic performs - not just his physics - but his entire step in the FixedUpdate, checking the controls, moving to the new position, checking for collision, etc. This would have been fine... But Unity's built-in Input functions for testing whether a button has been pressed or released (as opposed to simply checking whether it is down or not) are refreshed in the Update, not FixedUpdate. This means that a button can be pressed and released (if the framerate is high enough) in between two Updates, and Sonic will never "hear" the button being pressed and react. If the framerate is too low, similar problems occur. The only solution was to write a CustomInput handler; in the FixedUpdate step, a bitmask (call it "A") is dumped into a buffer bitmask (call it "B"). Then the state of all the buttons is dumped into "A". Sonic's scripts can then check "A" to see which buttons are down, or compare "A" and "B" to see which buttons have been newly pressed or released during this frame. This should have solved everything, but it still feels floaty to some people (and me, too! I feel your pain, guys!) I don't know what else might be causing it, but there are some possibilities: Being 50fps instead of 60fps might be enough to cause the floatiness Unity's axis checking (which I directly query for Sonic's left and right movement) might be sluggish for some unknown reason, taking a frame or two to respond to changes. The CustomInput routine, even though it runs in the FixedUpdate step, might not be happening before Sonic's code is run, making everything run 1 step late. I don't know enough about Unity to force scripts to run in a certain order. Something I haven't thought of, and could never think of because I'm so unfamiliar with Unity. I wish it didn't have this issue, because it is such a big one, but I'm not sure what to do about it.
A cheating way to force script order, without looking into Unity in further detail, would be to call the next script at the end of the previous one. It's a very cheaty/hacky way to do it but it should, in theory, work.
Sigh. Wish I understood it more. Curious though... if SFR is using the method that doesn't let him pass through enemies, walls, etc, then how come he still passes through the odd ring? Unity sounds like a bugger. :/
Unity provides you with a time delta value (how many time elapsed since the last update) which you can use to move your objects so the movement is frame rate independant. However if the delta is too big, you may move them farther than what you expected, having the objects move through walls/enemies/objects. You can either use a fixed timer for the physics (FixedUpdate) or subdivide that delta value in multiple steps. Code (Text): /// <summary> /// At every update step, we subdivide the amount of time /// elapsed to a fixed framerate, to have the logic run at /// the same speed regardless of the CPU speed. /// </summary> public void Update() { if (init == false) return; // Calculate elapsed logic frames on this update. float overallDeltaTime = Game.FramesPerSecond * Time.smoothDeltaTime; do { // Compute this cycle's delta time. float deltaTime = Mathf.Min(overallDeltaTime, 1.0f); // Update! UpdatePosition(deltaTime); } while ((--overallDeltaTime) > 0.0f); }
I absolutely love the graphics in this game and you should not change them at all! I love the darkness and the fine detail! It is so much better than Sonic 4, especially without the homing attack, I hate that. I'd pay good money for a finished product.
Erm, forgive me if this sounds obvious and has been considered before, but as you can't sell this have you thought about sticking a donate button on the site? I'd happily donate something equivalent to a retail game price for this to continue development. Love the graphical style, it's just as I'd imagined Sonic would look on decent hardware, especially like the Whale set piece as it shows off the 3d, more set pieces pls! :P
Another thing you could do is sell an ebook about anything from curing pubic lice to making pastry, and in that ebook could be the download link to Fan Remix. So you are in effect profiting from the game (as you should), but you aren't doing it in any official way that violates copyright law. And yes, I would definitely pay top dollar for a finished game of this!
