Well, yeah, inheritance would be kind of a given in order to enable ordering, but it's probably not really a problem.

While having global objects appear on layers by name rather than number would be great, you still have to start another layout to initialize everything when you just want to test stuff, which is annoying. I'd like to at /least/ be able to immediately be able to test stuff and let the engine initialize stuff for me.

I think this one speaks for itself. Remember the 'inherited layers' feature from Classic? There are methods of replicating this sort of thing using global objects, but it requires setting up a whole bunch of layers in a certain order for ALL layouts, which can be a pain, and can be time-consuming for testing. I'd much prefer an in-built feature that lets you set up 'global layers' that are loaded on startup, are kept around when changing layouts, and ordering can be sorted on a layout-by-layout basis.

It would certainly make everyone's lives a whole lot easier, I think.

Yeah, remember when I said that the gun sprite was duplicated? Turns out that's a problem with Spriter itself, as the gun sprite in some animations has a different name than what it should be, causing unnecessary replication, and Spriter refuses to let me rename it correctly, instead adding a "_000" or some other number at the end.

Also, with the latest versions of C2, the plugin and Spriter, the spriter animations simply don't appear in C2, despite all the settings being correct. Here's the cap I'm using to test it.

As well, I might've missed this earlier in the topic, but to update a spriter file, you have to SCML File property to the .scml file otherwise it won't work if it's set to the .scon file.

I really hope we'll see an update with fixes to these and the implementation of char maps, as well.

Alright, I've gone back to this topic, it seems...

Well, right now, I've got two sets of events - one for control-based events in the big 'for each' loop, and another group for events that can't go in there. While I've managed to fix up many events to enable multiple players to work better, I've also hit a snag when it comes to 'duplicates' - when two players are using the same 'character', there are, well, issues. Player 1 works fine, but Player 2 is unable to properly end some animations, as "on any animation end"/"on animation <animation name> end" doesn't properly trigger for some reason, which causes the second player to be stuck on the specific action.

This is obviously a problem. Any ideas on how to work around it?

In one of the few updates for the open source branch of Construct Classic before development on it pretty much died, the platform behavior got an interesting feature - being able to selectively toggle collisions with specific objects. For instance, holding up to walk up a set of stairs while moving towards them (while moving past if not holding up), or onto a lift (if the lift is moving up while the player is holding up, the lift will carry the player upwards, and will simply pass by if not).

Another interesting example includes changing to another 'layer' of the map - for example, going upstairs or downstairs in a top-down view without changing layouts, or entering a building that's in the 'background' with a sidescroller view. Such things can have some interesting possibilities for map design.

Stuff like this, though, isn't really feasible right now as things are - you could switch solids/jump-thrus on and off, but that will cause a myriad of problems for other things using those behaviors, especially if you want things to be still be active on multiple 'layers', for example.

So, yeah, for certain behaviors like Custom Movement, 8-Direction and Platform, I'd really like to be able to selectively toggle collisions with specific objects.

Revisting this thread...

While it is technically possible to achieve such results, I really think that such useful functions shouldn't need so much work to set up - when programming languages include proper dynamic arrays/linked lists as standard functions, surely it would be worthwhile to implement them. Sometimes it's just better to get better tools for a specific purpose rather than try use existing tools that'll make solving the problem more difficult.

Just a note, lucid, there's some strange object replication stuff, especially with importing the platformer template with the gun - when imported, the object comes with four gun sprites even though they're exactly the same, which is kinda bizarre.

Edit: Also, the muzzle flash animations are basically worthless unless removed from the rest of the animations into their own file.

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.

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.

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.

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

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.