Optimizing a Function-Heavy Sonic Platform Engine

So, last time I tried to get help when it came to a optimizing my Sonic-based platform engine, the focus was collision checking. Turns out I was looking at the wrong area, because, apparently, that wasn't the actual problem.

For refernence:

• engine .capx (requires C2 Standard, obviously)
• Playable Engine Test

So, it seems the major CPU bottleneck is fairly obvious, now that I've rechecked the CPU profile in the debug:

<img src="https://dl.dropboxusercontent.com/u/919275/Screenshots/CPUStuff.png" border="0">

Yikes.

Yeah, that's more than a bit much. For reference, the Pre- and Post- movement sections only call a couple of functions each tick, and the former modifies a couple of variables. Those two functions are "Player.Reposition" and "Player.Collision", the former of which properly aligns the position of the player sensors, and the second runs though every sensor and checks if they're colliding with something, by ALSO using a function for each sensor. And there's eight different sensor functions. "Movement" itself does plenty of function calls to both above functions depending on the circumstances and to other functions as well. Sensor Routines and Movement Routines in general does a LOT of function calls.

Unfortunately, this seems to be incredibly inefficient in C2, whereas it's perfectly fine in Classic, probably because of the way the two work differently.

So, yeah. I'm somewhat at a loss as to what to do. The whole thing is rather complicated, and I wouldn't know where to start in order to optimize the whole thing.

Your files don't seem to be linked properly... :/

Whoops! Turns out I accidentally missed them when composing my post. Fixed, sorry about that!

very impressive use and trick for slope and mouvement ;)

Well I noticed it looks like your abandoned the the Platformer behaviour. Possible becuase you need too for some of Sonics abilities. But doing so puts a lot more stress on your cpu code.

You should figure another way to cut out the WHILE loop in movment and try to only run it once per tick. I haven't sit down to see how many times per tick it will run. But I can imagaine that it's running a few hundred times. And is likely the reason it accounts for %16.

Also I noticed you call Player.Repo and Collision with both on Evertick.

you should run a single every tick and put them in order once. As it looks now If assuming these are running in order.

Position/Collision

Movement while loop

position/Collision

ok. se thats the supposed run order. Now imagine 3 ticks of that

Position/Collision

Movement while loop with position/Collision

position/Collision

-

Position/Collision

Movement while loop with position/Collision

position/Collision

-

Position/Collision

Movement while loop with position/Collision

position/Collision

notice how poosition/collision call functions are right after each other. Is that really needed?

now I did some testing. You can disable the entire post-move and have no negative gameplay effect i noticed. And this saved apx 8%

I then tried leaving the post animation on and turned all the other collision and position checks prior tot he post and managed to get the the group from 36% to 16%. However this comes with that the animation starts going off. Character doesn't rotate as smoothly. There is some room for improvement :)

Alright, here's what I've got when trying to tweak the engine:

�

1. The timescale has been set to 1, because the old way it worked, for some bizarre reason, doesn't stay�constant.�The movement works slightly better as a result.

2. The pre-movement function calls are�entirely�unnecessary.�Now, removing both the pre- and post- movement function calls pretty much sorta breaks the movement, but removing just one set seems to have no negative effects, making the whole thing slightly more efficient.

3. Now, you'd think just having one set of calls for Player.Reposition and Player.Collision once every frame would be fine, right? So just removing those calls from the main movement group would be fine, right? Nope! The whole thing�crashes upon startup�if those calls are removed. I'm serious. By all rights, it shouldn't be capable of�doing that.�You'd think it would simply cause the movement engine to spazz out or something, but instead, it crashed! It would be impressive it were not so frustrating.

�

I'm pretty much calling this engine a lost cause at this point, point no. 3 just makes it seem fundamentally broken. I'm likely going to have to explore new avenues at this point.

I remember using Sonic Worlds a lot when I used to use MMF2!

Looking at this capx reminds me EXACTLY of the layout of the events from the MMF2 Sonic Worlds.

Not that I'm exactly genius on all of this, but I can see a lot of events that are very badly optimised (the same things jayderyu picked up on).

Mostly avoid repeated Collision checks. I know it's difficult to sparse collisions, but some checks aren't necessary, such as, whilst Sonic is moving right (XSpeed>0), it's not really needed to check the "Left" sensor if it's overlapping a wall (Sure, it could create problems such as if a moving wall was coming towards sonic whilst he's moving right slowly, it may not push him, but I'm thinking "Basic" Sonic engine :P )

"Every Tick" with lots of math involving Sin and Cos, probably is a bit overly taxing on the CPU (Even general calculators lag for seconds when you do multiple sin calculations in one go), I guess to avoid that though is a bit complicated, as Sonic needs to detect stuff constantly as he's running.

I haven't got time to analyse or write any more right now :( but I hope I gave some sort of useful insight!

Honestly, at this point, I'd say it would be easier to just find someone who could make a custom behavior. It would certainly be more efficient, I think, and probably easier to work with when it comes to stuff like multiplayer, due to the lack of need for picking with all those freaking sensors.

Don't give up, man! It's your baby. And just like all babys it is not always cute and innocent. Sometimes it just cries for no obvious reason. But you as the daddy have to find out what the crying is for.

And at least you're learning a lot about optimizing - and about all the things you could have done in the beginning ;)

Optimizing in this case means being familiar with how C2 works (best), so that you can avoid redundant events, functions or checks.

Again, don't leave your baby alone crying xD

Candescence It's easier than you'd think to make multiplayer. You could have as many different players as you desire using only one set of sensors (each player would have their own "Player" sensor, but all the slopes, walls, ceiling censors). In the most simplist way, it would literally require a "ForEach" loop that sends a function that does all the movement events, with a function parameter of the Player's UID. Sure there might be a hickup or two, but trust me, it's very straight forwards (a lot more straightforward than optimisation stuff!).

Listen to tulamide! Don't abandon this, you've managed to get very far already, it's further than I ever got in my few attempts of making a "Sonic" engine in C2 (I have tried a few times and only end up making a ball that can walk up slopes and stick to them using trig, then I gave up lol). If you're stuck, just keep asking questions on here, people here love to help others :P

To be perfectly frank, it's not really 'my baby', it's a port of StreakThunderstorm's Classic engine.

But I'm really not convinced that this engine can actually even be salvaged. I've figured out that the slope detection events are the ones that cause the crash when you remove the reposition functions from them, and removing all the other function calls of Collision and Reposition do little to optimize it and start causing issues anyway.

At this point, you might as well just scrap the whole thing and start over, because trying to optimize it will inevitably just break the whole thing in half. The engine is too complicated for its own good, collapsing under its own weight and unable to make it lighter without removing any vital parts.

Back in the day, I was convinced that a direct port from MMF2 was a terrible idea due to the differences in the ways the event systems worked, among other things, and now I'm once again convinced that this route was a futile, pointless effort.

Sure, you didn't develop the MMF2 Sonic Worlds, but "Porting Sonic Worlds to Construct 2" is what is yours. Your baby, if you will.

Also, you HAVE directly ported it, and it works almost perfectly; just a few bugs here and there and this performance issue. But other than that, you've ported it very well. It's impressive, and it's unfortunate that think it's a futile effort.

I think the one inevitable problem is "curved platforms", as C2 handles collisions via polygon, and not per-pixel; but it's still totally feasible.

I hope you continue to work on it! I'll see if I can apply what I know to optimise it in my free time. Kudos on what you've managed to do so far!

Hi all,

Sorry to revive an old thread, but what ended up happening with this?

-Someone on the last page suggested getting someone to make a custom behavior for Sonic the Hedgehog-esque movement. Has that been done? If not, for someone with the relevant coding skillset, what would be the time required to program one? Could other open-source reimplementations of Sonic the Hedgehog physics save time for making that happen?

-Running the demo on a 5-year-old desktop computer today, it appears to have no slowdown at all. When people talk about it being poorly optimized, was that prior to the changes in how C2 handles collision? Or were the concerns more about performance on mobile devices? With the exception of a couple of bugs (in a lot of cases it seems like Sonic has troubles starting a roll down a curved slope) this seems like something you could reasonably build a Sonic fangame off of. MMF2's might be easier to work with, but MMF2 doesn't have multiplayer support...