Jump to content
A 2021 backup has been restored. Forums are closed and work in progress. Join our Discord server for more updates! ×
SoaH City Message Board

The general "making shit work in Construct 2" thread


Candescence

Recommended Posts

Yes, I have been working on stuff in Construct 2 as of late, unfortunately, none of that is Sonic-related, because I've pretty much hit my wit's end when it comes to making any kind of proper Sonic engine really work in C2.

My most successful attempt (for reference, the .capx (requires C2 build 151 or later), and an online WIP demonstration) has mainly hit a major snag - performance issues. Oh, the engine works - mostly. But according to C2's debugger (which is wonderful, by the way) the movement routines are taking up an absurd amount of C2 time. This, obviously, isn't ideal.

So, at this point, as far as getting any kind of Sonic engine done is concerned, I'm stuck between a rock and a hard place, and any kind of solution (whether it be using a physics-based recreation, a custom plugin, redoing the whole thing from scratch, or figuring out how to optimize what I've already got) will likely involve someone who is far more qualified for this this than I am, because I've come to the conclusion that I'm no good at this Sonic engine stuff at this point. :asweatdrop:

Link to comment
Share on other sites

Since im building my current project off the same engine, I feel like i should help, although I can only test so much seeing as I don't have a real version of C2, and it wont let me alter anything.

I can't really think of, or see a reason why your engine is behaving the way it is. It's just really jerky and everything is very inconsistent. But comparing events, nothing really seems to be different. And I cant think of any one screwup that would cause it to behave this way.

If I had a quick guess, i'd say it probably has something to do with something on C2's end. Are Functions slower than they were before? Did they add some new feature that wasnt in Classic that is doing something differently? In Classic, Functions activate, carry out their events immediately, and do not let the application even update until its finished. If that is no longer the case, I think it could account for the shitty position updates.

Does TimeDelta work the same way? Try removing the update to the 'Player.pvTimeDelta' and setting it to 1. See if it still screws up on angles and acts super jerky when you try to move fast.

I don't have too much experience with pushing C2, but the performance doesn't seem to resemble typical CPU consumption issues.

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

I'm sure most of the reposition calls are needed because of how often the movement routines move sensors around, and that can mess up the event logic really easily when it comes to collisions and throw you into infinite loops. So the crash on that point isnt so odd.

 

I dont think this has much to do with the port itself, just some changes in Construct 2. I know Scirra mentioned that in terms of power C2 isn't as strong as CC, but I really don't think worlds is that cpu intensive. And even if it was, that is no excuse for that engine to run the way it does. It's not lagging, it's just broken. I still think it has something to do with functions. It's really easy to slow down CC with too many function calls, so the problem may be compounded in C2. I just can't think of any reason why it's working the way it is. The framerate is fine but the movement engine is behaving as if it cant keep up with itself.

Link to comment
Share on other sites

I think you need to wait on Construct 2 to reach a little more maturity before trying to do a Worlds/more generic 360 engine port.  They only just recently added tilemaps (which should help with some of the heinous performance problems) and those still don't support collision that goes beyond whether or not a whole tile is solid.

 

And honestly I'm not sure if it's ever going to be any kind of ideal option at this point.

Link to comment
Share on other sites

I think you need to wait on Construct 2 to reach a little more maturity before trying to do a Worlds/more generic 360 engine port.  They only just recently added tilemaps (which should help with some of the heinous performance problems) and those still don't support collision that goes beyond whether or not a whole tile is solid.

Actually, the tilemap plugin does support collision polygons for individual tiles, so there's there.

 

And to be fair, last I checked, MMF2 doesn't have tilemap support, period  :P

Edited by Candescence
Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...