[winterhell]

If the collision terrain is made out of polygons, against what shape would they be tested on Sonic's behalf? A ray/line, box, circle?

[CommandanteStreakTH]

Candescence, on 16 December 2014 - 01:03 AM, said:

CommandanteStreakTH, on 15 December 2014 - 11:59 PM, said:

The collision detection works pretty fine even for the minimal amount of polygon edges in each curve, but the amounts that need to be calculated are grinding on the speed of the game. (also, Mr. Lange, did you click on the points instead of the edges? Construct 2 is weird like that) Have you implemented a feature to destroy objects once they're off-screen and spawn them at certain points? Either at invisible objects or their absolute coordinates. It'd be a pain if you're trying to make a game with extra features.

No, and that would be an incredibly stupid idea. Construct 2 already has collision cells, which dramatically reduces the amount of collision checks to within a local area, achieving the same objective but I doubt the engine at the moment is able to take advantage of it, due to the way it works (collision cells need collision checks to be the first picking condition in a top-level event, otherwise it'll brute-force it), and it's difficult to tell whether the way it works now satisfies the requirement.

Huh. That I didn't know. So... I guess the engine's done that for us already... I see... (never really bothered to check all the different features e_e).

[Jase]

I still really think it's a good idea to avoid using more than 4 points on a collision polygon. I think you would get much better results if you use multiple pieces of 4-pointed invisible collision sprites angled along the terrain/curves/halfpipes.

[CommandanteStreakTH]

Jase, on 16 December 2014 - 04:03 AM, said:

I still really think it's a good idea to avoid using more than 4 points on a collision polygon. I think you would get much better results if you use multiple pieces of 4-pointed invisible collision sprites angled along the terrain/curves/halfpipes.

Would it now? I would imagine imperfect clipping would cause for some very clunky physics, but I've yet to try that out...

EDIT: Did a quick test of that with the premade assets, it works rather fine, in fact, better than the ramps with multiple polygons, but that might make it difficult if you want the tiles to snap to the grid... It's also really tedious but it can be way more precise, but wouldn't the sheer amount of objects grind on the performance even more?

This post has been edited by CommandanteStreakTH: 16 December 2014 - 04:15 AM

[Mr Lange]

I don't understand what it means by putting collision checks in "top level events". So, I can't have collision checks later in my code, or have too many collision checks going on and then collision checks later in my code or something, or else it reverts back to brute force checking? I'm confused. What am I supposed to be doing with the order or placement or amount of collision checks to keep it in the safe zone of the new collision checking system?

[Jase]

CommandanteStreakTH, on 16 December 2014 - 04:07 AM, said:

Jase, on 16 December 2014 - 04:03 AM, said:

I still really think it's a good idea to avoid using more than 4 points on a collision polygon. I think you would get much better results if you use multiple pieces of 4-pointed invisible collision sprites angled along the terrain/curves/halfpipes.

Would it now? I would imagine imperfect clipping would cause for some very clunky physics, but I've yet to try that out...

Even if you used a pointy collision polygon, it's never going to be pixel-perfect, and if you could use an infinite amount of points and shaped the polygon around the terrain perfectly, then you win, you get your nice pixel-perfect collision, but say goodbye to your framerate . If I'm not mistaken, it's better to have 2 4-pointed sprites to test each of them, than 1 8 pointed sprite or something. Then again, I could be wrong, I guess I should test and benchmark this stuff.

[CommandanteStreakTH]

Jase, on 16 December 2014 - 04:17 AM, said:

Even if you used a pointy collision polygon, it's never going to be pixel-perfect, and if you could use an infinite amount of points and shaped the polygon around the terrain perfectly, then you win, you get your nice pixel-perfect collision, but say goodbye to your framerate />/> . If I'm not mistaken, it's better to have 2 4-pointed sprites to test each of them, than 1 8 pointed sprite or something. Then again, I could be wrong, I guess I should test and benchmark this stuff.

Either way, with any sort of optimal collision detection method (and the "invisible box" method can result in some more unique shapes than what is limited by a square tileset), the physics still work as they should, though I would suggest vertical surfaces have more friction, because right now it acts weird. Uh... Candescence, what are some of the problems you're seeing so far?

[Jase]

CommandanteStreakTH, on 16 December 2014 - 04:07 AM, said:

EDIT: Did a quick test of that with the premade assets, it works rather fine, in fact, better than the ramps with multiple polygons, but that might make it difficult if you want the tiles to snap to the grid... It's also really tedious but it can be way more precise, but wouldn't the sheer amount of objects grind on the performance even more?

I guess that's something I've never been able to test. I would have thought the sheer amount of multipointed objects would be worse than hundreds of 4-pointed objects. But yeah your right, it is tedious

Mr Lange, on 16 December 2014 - 04:12 AM, said:

I don't understand what it means by putting collision checks in "top level events". So, I can't have collision checks later in my code, or have too many collision checks going on and then collision checks later in my code or something, or else it reverts back to brute force checking? I'm confused. What am I supposed to be doing with the order or placement or amount of collision checks to keep it in the safe zone of the new collision checking system?

Lets say you have a sprite called "FloorCollision", and in an event you decide to put:
+Is Sensor overlapping FloorCollision
Then this event will take advantage of Collision cels.

If you was to have another condition in this same event so it looks like:
+FloorCollision.X > 50
+Is sensor overlapping FloorCollision
Now the event will not use collision cels. This is because it picked from all existing FloorCollisions that have their X position > 50 , then with that list of picked FloorCollisions, it then tests them for collision with the sensor.

It's a downside and it is annoying lol.

[CommandanteStreakTH]

Jase, on 16 December 2014 - 04:28 AM, said:

CommandanteStreakTH, on 16 December 2014 - 04:07 AM, said:

EDIT: Did a quick test of that with the premade assets, it works rather fine, in fact, better than the ramps with multiple polygons, but that might make it difficult if you want the tiles to snap to the grid... It's also really tedious but it can be way more precise, but wouldn't the sheer amount of objects grind on the performance even more?

I guess that's something I've never been able to test. I would have thought the sheer amount of multipointed objects would be worse than hundreds of 4-pointed objects. But yeah your right, it is tedious

If you ask me though, it reminds me a lot of playing around with the editors in Spore when you want to make a curve but all you have are squares (and if you have played with Spore editors before, this method is the best for you). It's great for complex and unorthodox shapes, but I've yet to check out the performance consequences of having those many objects. Probably another workaround for that is to have single pieces for long platforms instead of the segments that have been provided. (Also, using this method, you could just overlay a dummy image of the level and make a collision skeleton that's set to invisible, instead of having to piece the level together with a tileset, great!)

Currently I made this massive "hook"-type ramp using that method, and Sonic is running around it without a snag. If you'd like to see the results, just ask and I might post a gif

This post has been edited by CommandanteStreakTH: 16 December 2014 - 05:06 AM

[Jase]

CommandanteStreakTH, on 16 December 2014 - 04:41 AM, said:

Jase, on 16 December 2014 - 04:28 AM, said:

CommandanteStreakTH, on 16 December 2014 - 04:07 AM, said:

EDIT: Did a quick test of that with the premade assets, it works rather fine, in fact, better than the ramps with multiple polygons, but that might make it difficult if you want the tiles to snap to the grid... It's also really tedious but it can be way more precise, but wouldn't the sheer amount of objects grind on the performance even more?

I guess that's something I've never been able to test. I would have thought the sheer amount of multipointed objects would be worse than hundreds of 4-pointed objects. But yeah your right, it is tedious

If you ask me though, it reminds me a lot of playing around with the editors in Spore when you want to make a curve but all you have are squares (and if you have played with Spore editors before, this method is the best for you). It's great for complex and unorthodox shapes, but I've yet to check out the performance consequences of having those many objects. Probably another workaround for that is to have single pieces for long platforms instead of the segments that have been provided. (Also, using this method, you could just overlay a dummy image of the level and make a collision skeleton that's set to invisible, instead of having to piece the level together with a tileset, great!)

Currently I made this massive "hook"-type ramp using that method, and Sonic is running around it without a snag. If you'd like to see the results, just ask and I might post a gif

Lol yeah, I know what you mean. I guess it's all about illusion, the player thinks it's a smooth curve but in reality it's loads of squares and lines stuck together, but to the player it seems smooth, which is who we are trying to cater towards anyway, right?
The single pieces for long platforms thing is similar to what I'm doing in my own engine!
gif plz

This post has been edited by Jase: 16 December 2014 - 05:35 AM

[Mr Lange]

Jase, on 16 December 2014 - 04:28 AM, said:

Mr Lange, on 16 December 2014 - 04:12 AM, said:

I don't understand what it means by putting collision checks in "top level events". So, I can't have collision checks later in my code, or have too many collision checks going on and then collision checks later in my code or something, or else it reverts back to brute force checking? I'm confused. What am I supposed to be doing with the order or placement or amount of collision checks to keep it in the safe zone of the new collision checking system?

Lets say you have a sprite called "FloorCollision", and in an event you decide to put:
+Is Sensor overlapping FloorCollision
Then this event will take advantage of Collision cels.

If you was to have another condition in this same event so it looks like:
+FloorCollision.X > 50
+Is sensor overlapping FloorCollision
Now the event will not use collision cels. This is because it picked from all existing FloorCollisions that have their X position > 50 , then with that list of picked FloorCollisions, it then tests them for collision with the sensor.

It's a downside and it is annoying lol.

Ah wow... this could be a problem with some things, but then again if the check is specific, it doesn't really need the collision cell optimization, does it? For example, if I were checking for the value of an object's variable and only one object has that value, then as long as that condition is above the collision condition, it's already eliminated every object but that one for the collision check, right?

[Jase]

Mr Lange, on 16 December 2014 - 05:48 AM, said:

Ah wow... this could be a problem with some things, but then again if the check is specific, it doesn't really need the collision cell optimization, does it? For example, if I were checking for the value of an object's variable and only one object has that value, then as long as that condition is above the collision condition, it's already eliminated every object but that one for the collision check, right?

Yes that's correct. If you had 100000 objects scattered around a massive level, then I'd probably order the events so that it does the collision check first, since in that situation, it would cost more to check 100000 objects' variables, than to use the collision cells optimisation which essentially lowers the picked object list to however many objects are within the cell (so maybe 100 collision checks depending on how clustered the objects are positioned).
If I'm not mistaken, the way collision cells work internally, it splits objects into different picked lists so it doesn't have to keep iterating through all of them to see if it's close enough or whatnot.

It's an awesome feature but very situational, and I find myself doing a handful of variable checking then collision, rather than collision then variable checking.

This post has been edited by Jase: 16 December 2014 - 06:27 AM

[CommandanteStreakTH]

Hooray! I finally feel useful in a programming community!

Jase, on 16 December 2014 - 05:26 AM, said:

gif plz

(The funny thing is that I was playing "Around the World" as I was recording this... how appropriate)

[Jase]

CommandanteStreakTH, on 16 December 2014 - 06:34 AM, said:

Hooray! I finally feel useful in a programming community!

Jase, on 16 December 2014 - 05:26 AM, said:

gif plz

(The funny thing is that I was playing "Around the World" as I was recording this... how appropriate)

Haha that's awesome and hilarious!
How stable is the framerate?

[CommandanteStreakTH]

Jase, on 16 December 2014 - 06:39 AM, said:

How stable is the framerate?

Well, when I recorded it, I was running a couple programs which would've marred the results of a performance test, so I closed them and did it again, and it was hovering around 30-40 FPS. Worst I got was about 29 FPS, and that was at ground level where most objects are focused in.