Can we stretch a layer? Isometric 3D engine

So it seems

Do you get my genius idea now newt? In that pacman CAPX you can just create maze obstacles and set them to solid, and the collision is taken care of!

There's probably ways to simplify things. Maybe 2 canvas objects are unnecessary? But it works!

I know it does not work as I used this method in CC when it did work, and then was broken when the engine was changed to scale uniformly.

Even then it would have required an offset to be made to any objects as soon as they moved.

Can you show me what doesn't work. Because all my tests show it does. Look at this CAPX. The collisions are correct, pacman can't walk through walls. There's no offset or math, it's the same as regular 2D pacman, but it is rendered isometrically. Help me understand what you don't like about this, apart from the probably inefficient method I'm using.

Are we talking about a different thing? I don't mind stretching layers any more. Just the canvas transformation looks fine. And it works fine.

And apparently it's used in http://rymdkapsel.com/ too.

newt?

This capx by Rojo shows why:

Press the up and down keys and notice how much faster the ball on the 2d layer moves.

That coupled with the need for the gazillion blocker squares is why.

Movement happens in a normal 2D plane, it's that same plane that get transformed so movement skewing is already taken care of. Blocker squares is simply a quick way to add collisions in a proof of concept example. I fail to see how christina's idea is not a good one...

Move one of the blockers after the transformation.

I still don't see what's wrong. The transformation is purely visual, if I move a blocker it'll still continue to block as it did.

But its moving in 2d, not isometric, so its y will be more than what it should be, unless you offset it to iso coordinates.

If you want to change anything that does collisions after the transformation it will have to be done this way.

If you want to add anything after the squash and rotate, it will have to be placed to iso.

Yes, it's moving in 2D, like everything else. But with the transformation, if I say "Set Y to Y + 32", it will look like it shifted 24 pixels left and 12 pixels down, thus mimicking the iso movement.

What will be hell is not positionning and movement, it will be having pre-distorted sprites and backgrounds.

newt r0j0's example is completely wrong, the mapping of the positions are all wrong, it's not the same thing.

[EDIT: no it absolutely isn't wrong, my bad! ]

You're thinking of coordinate transformation, I'm plainly showing you transformation of the *end visual result*

If you want more convincing, take my example and implement a super-exact grid movement on the orthogonal plane, perfect square tiles. When you run it through the two canvases, you'll see every pixel lines up, pacman will be on the exact same grid square in both the orthogonal and iso plane.

Try it!

Magistross agreed. Even though! The "floor" doesn't need any distortion. Only vertical sprites do (walls, people etc). And even then it's a distortion that can just happen using code at Start of Layout: all family_vertical_sprites rotate -45 degrees and scale vertical 200%. And then you forget about it

hmm pretty clever christina

I ran a quick test, it works for me.. I can't see why it wouldn't work. Although I've never worked in iso before so I can't be sure.

so basically this:

Math, it gets you in the end.

Edit:

------------------------------or----------------------------

Math you may not get it, but it will get you.

Magistross agreed. Even though! The "floor" doesn't need any distortion. Only vertical sprites do (walls, people etc). And even then it's a distortion that can just happen using code at Start of Layout: all family_vertical_sprites rotate -45 degrees and scale vertical 200%. And then you forget about it

Quite true, I forgot you could let Construct pre-transform your sprites for you, so the 2D to ISO viewport actually revert them back to their original appearence. Pretty clever indeed !