Pixel Perfect Collision

Does Construct 2 allow for pixel perfect collision? If so, how do I set it up?

Jason

Not yet, but it probably will in the future. Do you really need pixel perfect collision though?

We're going to do polygon collisions next.

Construct Classic's pixel perfect collider is a bit unusual - it uses all the hardware tricks in the book to get it fast enough to be useful. Javascript doesn't have the same close-to-the-metal features that C++ has, so it's unlikely to be practical in Javascript.

Still, polygon collisions should do just fine.

I am wanting to create top down levels by using a tiled background for the floor and drawing the walls for the entire level as one top down file with transparency everywhere walls are not located. I am wanting to have a collision event only occur when the player hits a wall (that is not transparent) and not while he is traveling across a transparent area of the wall sprite.

This way I can create the walls as a single sprite and use it for collision.

Is there another way to do this?

Jason

I have never heard of polygon collisions. How easy are they to set up and use in Construct 2?

Jason

What I like to do is set up a few all purpose collision objects (namely a square shape and a triangle shape) and place them where I don't want players to go (usually also on a separate layer for organizational purposes), and then have the game turn them all invisible at the start of the layout. Then I leave my scenery on "no collision" usually, unless I really really need it to be. I don't ever notice any slowdown from this technique either.

blueFire, you can create invisible solids and place them inside your walls.

Were polygon collisions added in r52?

Jason

I'm reviving this thread!

Okay, here's the gist:

I have a top down game that has six "zones." It works zelda style. Every zone is basically the same location with invisible sprites on the edges to swap out a custom background.

First, we assume that each zone is 1024x1024px, our focus 400x300 or so.

Next, we determine our colliders: BEACH2JUNGLE and JUNGLE2BEACH. These are invisible sprites that are 20px wide, and 1024px tall. If we set the image point to 0,0, and then set the collider's placement to 0,0 or 0,1014, it will give us a 20 pixel strip along the right and left edge of each zone. When you hit the zone with your character, the following happens...

Player> On collision with BEACH2JUNGLE

   Beach.png destroy

   BEACH2JUNGLE destroy

   System Create Jungle.png at 512,512 (aligned as a background)

   System Create JUNGLE2BEACH at 0,1014 (aligned as an edge)

   Player set X to 100 (more specific than wrap...)

And then...

Player> On collision with JUNGLE2BEACH

   Jungle.png destroy

   JUNGLE2BEACH destroy

   System Create Beach.png at 512,512

   System Create BEACH2JUNGLE at 0,0

   Player set X to 900

This allows you to walk back and forth between maps, scoots you ahead of the collision detector by 100px, destroys unused maps, and destroys the collision detector from the other map. Hopefully that all makes sense.

Because even though swapping screens works well, I still have one crucial problem!

What about my walls? Cliffs, rocks, trees, houses, even water? All the walls I've set up for one zone won't work for every zone. I'd have to destroy everything, and call up NEW walls with NEW coordinates...

And that's where the problem lies. If I CREATE > Wall for one area, and put it in place, resize it to fit, and rotate it just so... and then try to create another Wall somewhere else, its restyling will affect the restyling of the first wall, too.

Wouldn't it be easier to just make a .png of the zone, overlay it on top of your background, and then set it so you could move through the transparent areas? I've tried messing with the collision areas in the animations, but it says to not use more than 8 vertices.

I tried clipping transparent edge, but that did nothing but trim the outer edges, which albeit exactly what it said it would do.

Am I missing something? Is there a way to use transparencies?

And if not... is there a way to give multiple instances of the wall object their own coordinates and size and rotations without overwriting all of them?

Thanks in advance, guys.

Okay, sad to see there was no responses, but let's move on from that.

I tried to make a sort of middle ground here. I know that one big PNG isn't gonna cut it, but neither is a hundred sprites. And while I have discovered that I can indeed give them their own rotations, coordinates, size, and whatnot, I still don't want to make twenty or thirty of them per level. That's a nightmare.

So here's my "Round-Peg-Square-Hole-Bigger-Hammer" approach:

I went back into the image and chopped the entire thing up into areas which contained walls. I made each block just big enough to cover an area that I knew would be covered by only eight vertices. Roughly three walls, give or take a rounded corner.

Each image was then dropped into the layout, the collision areas all properly defined, and then set to an Opacity of zero.

Instead of having a layout that consists of twenty individual blocks for walls, each one requiring a unique list of info, I now had five pngs, and the only attention they required was to simply have their verts properly lined up. And if you can play connect-the-dots, you can line up verts.

To reiterate that last point- creating walls via sprites involves a process which looks like this:

On LoadBeachMap   >

   System Create > WallSprite at 0,0

   Wallsprite > Set Size to 40,500

   Wallsprite > Set Angle to 180

   System Create > WallSprite at 500,0

   Wallsprite > Set Size to 40,500

   Wallsprite > Set Angle to 180

   System Create > WallSprite at 0,500

   Wallsprite > Set Size to 400,40

   Wallsprite > Set Angle to 180

That would create a vague "U" shape. Then you'd still have to set the opacity to 0, change the behavior to solid, etc.

With the new version, one image gets the same result.

On LoadBeachMap >

   System Create BeachWallsU.png at 250,250

Set your behavior, opacity, and verts. Done.

FORESEEABLE PROBLEMS:

   Makes the runtime slow waaaaaay down on my older laptop. As in... each section takes ~1.3 to 1.7 seconds to load. Not using power of 2 is one of my concerns here...

So, in closing, this is one solution that can help you achieve more precise results when it comes to collisions. Break things up into pieces, like reese's.

For grid (or hex) type of movement I wonder if it would be quicker to list the locations of solid objects in an array and then scroll through the array each time to see if a solid object is there before allowing the player to move into that spot? This way there would be no collision detection of graphics needed at all. This would restrict the player to moving in blocks equal to the size of the grid.

Jason