I wouldn't look at it as a instantaneous wishful sort of phenomenon. People aren't machines- even though everyone has become conditioned to hitting buttons and receiving instant responses in modern times..

I'd suggest just slowing down a bit and do some studies of other games if you are interested in expanding your understanding of games. Try not to be so reliant on a single person's response, etc, because then that leads to bad habits (I'm trying to break some of my own).

You're only comparing the Chromium engine - have you tried Edge and Firefox? They have different v-sync engines. Edge was particularly good IIRC.

Chromium is the only option we have if we export to pc.

I think html5/javascript is a good platform to invest in. I do feel at times that the more complex a construct game becomes, the more unstable it runs. There are various small things that have been noticed by users that effect a game's performance, such as function calls requiring more processing, multiple tilesets, etc. And all these things add up, especially if you aren't aware of how to avoid the problems. And who knows what else there is.. There have been many times where I implement something, and get a weird feeling that it should run better than it does- maybe because construct adds extra stuff to ensure a more universal possibility.

I'm more interested in construct allowing more customization for users, so they can better control how their games can be developed and how they run, etc- there is still so much that can be improved, and construct is already a really great tool.

Alright- makes sense.

I only need the bounding box type for my specific case, I was just confused at first but figured out I had to reset poly to bounding box (can't just drag the points to the corners).

Chipmunk still is very great to use- one of my main reasons I use Construct2.

Okay, so.. here is some more info..

Seems like if I modify the tile's collision poly, then Chipmunk separates it into another group or something. Moving the points back won't revert it, I had to right click and set the collision poly to bounding box for it to combine properly.

Maybe there is a flag somewhere that is set if you set the poly to bounding box, and it is toggled when moving the points?

Anyways.. kind of interesting.. Basically if a tile is considered a polygon(not bounding box), then it won't combine with tiles that are considered of bounding box type.

R0J0hound , I'm having an issue with tile collisions polygons. It seems like the polygons are generated fine when the tile is index of 0, but if it is a different index, like tile 1 or 2, etc, the polygons don't combine together.

Is there a way for me to confirm if this is the case? How can I fix this if it is?

..maybe a bug in the tilemap object??

edit: the tilemap's collision rects property value in debug remains the same when I replace tile type 1 with tile type 0, so maybe it's a chipmunk bug.

Prominent Really useful plugin. Thank you! Can you add a relative X and Y pinning option? Right now, when using the relative scale, objects changing their location.

Thanks! So if I understand correctly, if an object is pinned to another object that changes scale(width/height), you want the pinned location to stretch with it?

I'll see what I can do.

Yeah, but if you want a game to fill the screen without black borders, the only options are scale inner or scale outer. Those will keep the pixels somewhat square, however, those scale to the window width or height which usually isn't divisible by the original game window size- so you get some pixels that are squished and stretched.

There could be more options that would round the screen size to the nearest value that is divisible by the original size. So an option that would round up and an option that would round down, and display whatever is extending out from that. That way everything remains square regardless of aspect ratio, and it would fill the entire screen/window.

Ashley , it would be great to have options for "Scale Outer Integer" and "Scale Inner Integer" modes. That way we can have games fill the screen and maintain square pixels without black borders regardless of window ratios.

> Does it return true if you are touching a ceiling and no wall to right or left?

>

No. Obviously that would defeat the purpose of the condition.

Alright, well I wasn't the only one confused by the wording- I guess it is my fault for not realizing that the 'is by wall' condition has a left/right option.

Prominent - I don't understand what you're upset about - previously, you could be standing by a wall, and "Is by wall" was false if you happened to also have a ceiling above your head. We fixed it so it's true again, as some other users noticed and insisted ought to be the case (and I agree). There is a backwards-compatibility risk which I carefully considered and was worried about, but I think you have to admit it makes more sense this way. Do you disagree? Should "Is by wall" still be false if you are by a wall, but happen to have a ceiling above you?

Does it return true if you are touching a ceiling and no wall to right or left? Because the way you word it in the update is that it would do this. If it does, then that seems bad to me.

"Platform behavior: 'Is by wall' is now true if the player has an obstacle directly above them"

-That wording fails to make clear if you are next to a wall while under an obstacle. It just says if you are under.

megatronx , Hi, sorry I've been away from Construct for a few months so I haven't seen your post until now..

It has been a while since I touched the plugin. I think relative pinning pins the object relative to the current offset (it keeps the x,y distances) ..I haven't double checked that though.

That is also a good suggestion for being able to reposition the pin! I'll look into adding that when I get some time. I'm slowly getting back into C2 dev stuff.