Jump to content

Phaser Isometric plugin


lewster32
 Share

Recommended Posts

I'm newbie of phaser

 

I have some problem about isometric plugin

 

in your example, http://rotates.org/phaser/iso/examples/interaction.htm

 

I copied your code and your image, tile.png, it worked.

 

afterthat, I resized image to 60x40 px, change for loop +=38 to +=35 instead

 

but not work follow picture

 lz4tt.png

I want to know, Why it doesn't work. and how to fix this problem, thank you.

Link to comment
Share on other sites

Because 60x40 is no longer a 2:1 ratio image. You need to adjust the game.iso.projectionAngle until it's correct for this ratio of tile. I would guess the value you need is 0.5880026035475675 (Math.atan(40/60)) but I'm no maths expert (yes, I've developed a plug-in without understanding the maths behind it!) and I could be totally wrong.

Link to comment
Share on other sites

Hi, first off thank you lewster, I signed up just to say how great this plugin looks.

 

I was interested in the "OBLIQUE" project as posted below in post #43... do you think that is is possible with the plugin?

 

Is it possible to modify this plugin to use trimetric projection? 800px-Graphical_projection_comparison.pn

 

 

Seems like it would be a matter of moving the Xs into the right place during projection, in addition to the Y (which currently is just a multiplier). What's the math to figure that part out?

Link to comment
Share on other sites

135° oblique is already possible with the projectionAngle property; I believe this should give you the projection you need.

game.iso.projectionAngle = Math.atan(1);

Essentially, the projection angle is determined by Math.atan(height/width) where height and width are the 2D bounds dimensions of a cropped flat 'tile' (see attachment)

 

If you need the 180° oblique projection, this doesn't require the plug-in at all, as it can be achieved perfectly well in 2D space :)

post-7918-0-73423700-1415871031.png

Link to comment
Share on other sites

  • 3 weeks later...

Question: how do I get 'sprite.events.onInputDown.add' to register the event to the correct sprite when the sprites overlap?

 

Hi, I've just started with Phaser and the Isometric plug-in. Its really nice.

 

I'm making an isometric board game, say like chess.

I've made 2 groups of sprites: one for board background and one for game pieces on top.

 

I want to pick up the mouse click / screen touch so I can select and move pieces around the board.

This is working but of course the sprites overlap and I end up firing events for the incorrect game pieces.

 

How do I get the click to register to the correct sprite?

 

(I figured I could do the calculations after an event has fired to see if the click was in the correct 'diamond' part of the sprite sprite.isoBounds.containsXY(cursorPos.x, cursorPos.y)

and if not fire the event to the next sprite back) but I can't get that working 

I'm sure its something simple that I've missed

 

Thanks 

Steve

Link to comment
Share on other sites

great thanks Lewster. I started my game from that example but had an issue getting a TRUE from "containsXY", something to do with the SourceSize I was setting in my 'sprite-slicing-up' data

			"filename": '1100',			"frame": { "x": 256, "y": 128, "w": 256, "h": 128 },			"rotated": false,			"trimmed": true,			"spriteSourceSize": { "x": 0, "y": 0, "w": 256, "h": 128 },			"sourceSize": { "w": 256, "h": 256 }

it seemed that setting "h":256 to 128 (not all my sprites were 256 * 128, some are 256 * 256) kind of broke it. My fault I guess as I'm not sure what all the numbers mean yet!

I've got something nice working, will show you ASAP.

Link to comment
Share on other sites

I'm having some trouble getting what I want from this plugin and I'm starting to think there may be some fundamental differences between my conceptual model and the actual implementation...

 

The code I have works great using Phaser.Sprite, but if I switch to Phaser.Plugin.Isometric.IsoSprite I can no longer update sprite positions. After a lot of stepping through the debugger, it turns out that sprite.position always gets overwritten in IsoSprite#postUpdate(); that calls IsoSprite#_project(), which updates sprite.position from sprite._isoPosition. There's a guard to only update position if _isoPositionChanged is true, but since _isoPositionChanged is never set to false, position is always overwritten...

 

It seems that when working with an IsoSprite you always have to work in isometric coordinates rather than world coordinates (as you would with Sprite), so you have continually to be calling project() / unproject() to switch between isometric and world coordinate spaces.

 

I guess the idea is that you should modify isoPosition instead of position on an iso-enabled sprite, in the same way you should modify body.velocity instead of position on a physics-enabled sprite. To me, though, that seems back to front. The isometric coordinate system is an artifact of the iso plugin; nothing outside of the plugin is aware of it, and I shouldn't need to be either unless I need to work in the pseudo-third dimension. If the plugin projected the sprite's world position into isometric coordinates, rather than projecting its isometric position into world coordinates, there'd be less contention with the assumptions of existing code and less cognitive dissonance for the user. 

 

Alternatively, perhaps my mental model of how the plugin works is distorted by my expectations to the point where I'm just not succeeding in pivoting my game logic into an isometric world-view :-P 

 

L.

Link to comment
Share on other sites

@laurie: It's an interesting point - I approached it in the only way I could get it working easily initially, and that has kinda stuck. I originally wanted IsoSprites to have a position property which was a Point3 instead of a normal Point, but that caused problems. Also, existing Sprites have x, y and z properties, with z used as a depth sorting helper, which again caused problems. Fundamentally, IsoSprites should be more abstracted from normal Sprites I think, with their own groups/containers and other stuff happening further up the display list chain, as there's a big difference between how Sprites are managed compared to IsoSprites; depth, anchoring and bounds being some of the bigger headaches I've come across.

Link to comment
Share on other sites

@laurie: It's an interesting point - I approached it in the only way I could get it working easily initially, and that has kinda stuck. I originally wanted IsoSprites to have a position property which was a Point3 instead of a normal Point, but that caused problems. Also, existing Sprites have x, y and z properties, with z used as a depth sorting helper, which again caused problems. Fundamentally, IsoSprites should be more abstracted from normal Sprites I think, with their own groups/containers and other stuff happening further up the display list chain, as there's a big difference between how Sprites are managed compared to IsoSprites; depth, anchoring and bounds being some of the bigger headaches I've come across.

 

It took hacking on the bundled Tilemap and related types until they rendered an isometric Tiled map correctly to understand the challenge you're describing. Having gone through that exercise, I better appreciate the constraints the plugin has to work within. I think what's missing is the ability for a container to apply an arbitrary transform to its children's position/scale/rotation. As far as I can see, a Sprite's position is simply added to its parent's position -- and it doesn't look like rotation/scale of the parent affect the child from the (limited) digging I've done.

 

 

It looks like Sprite#position is always relative to the sprite's parent, and Sprite#world is what gives the absolute world coordinates. If the mapping between the two were exclusively managed by either the sprite instance or its container this would be much easier, but I don't think that's the case? 

 

Anyway, understanding the relationship between .position and .isoPosition allowed me to explicitly map between coordinate systems correctly and, modulo needing to write some missing 3d vector math routines, get the result I need. Thanks for the insights on your implementation, that really helped me understand what was going on!

Link to comment
Share on other sites

  • 2 weeks later...

Lewster I have a question:

 

Sometimes the isoSprite objects appear black.

On the screenshot above the snow continued and non-isoSprites rendered.

 

it occurred on my Nexus 7 v2 (upgraded to the new OS and now it runs so slow, big mistake)

and reported by others but I'm not sure on what device, but not an issue on my Hudl2 or pc laptop

 

Any ideas?

Thanks

Steve

Link to comment
Share on other sites

First of all ~ thank you for this awesome plugin for this awesome framework ~
*opened a new topic*

Overlap / Collision
I have run into a problem which I do not know how to solve or why it happens.
using latesest Phaser 2.1 and isoPlugin.

no big GameCode, small for testing: When I check for overlap or collision in the update fun, nothing happens.
the overlap / collision always returns: false


Create:

    this.game.physics.startSystem(Phaser.Plugin.Isometric.ISOARCADE);    this.game.physics.isoArcade.gravity.setTo(0, 0, -500);
    this.player = game.add.isoSprite(300, 200, 0, 'cube', 0, isoGroup);    this.player.anchor.set(0.5, 1);    game.physics.isoArcade.enable(this.player);    this.player.body.collideWorldBounds = true;    this.player.body.bounce.set(0,0,0.3);    this.pillar = game.add.isoSprite(400, 100, 400, 'pillar', 0, isoGroup);    this.pillar.anchor.set(0.5, 1);    game.physics.isoArcade.enable(this.pillar);    this.pillar.body.collideWorldBounds = true;    this.pillar.body.immovable = true;

Update:
 

    game.physics.isoArcade.collide(isoGroup);    game.iso.topologicalSort(isoGroup);
     this.game.physics.isoArcade.collide(this.player, this.pillar, this.behindObj, this);     console.debug(game.physics.isoArcade.overlap(this.player, this.pillar, this.behindObj, this));  //returns false

So I think that I missed something, but don't know what, maybe someone else knows?



Regards

Link to comment
Share on other sites

Found it:

this.player and this.pillar are in the same group.
When I separate this.player into a second group and call:

game.physics.isoArcade.collide(isoGroup2);game.iso.topologicalSort(isoGroup2);

it works. But is this the common behavior?

Do I have to check 2 different groups? And can I not check 2 Sprite in one group against each other?

//EDIT:
in the doc is written: that you can perform a isoSprite vs. isoSprite collision / overlap, but it seems that this isn't working.
Just group vs group.

cause of the typological order sprite vs. sprite would be better in order to handle the z overlapping.

regards

Link to comment
Share on other sites

okay problem was:

calling
game.physics.isoArcade.collide(isoGroup);

and then checking for collision between two sprites.
remove the line above and it works. marked open topic as solved.

Link to comment
Share on other sites

so collision now works.
Another question :)

is there a method to check for "overlapping" via z axis?
further explanation:

- collision and overlap methods are called when overlapping or colliding with the >stand< or the 3D bottom of an object.
- is there a function that is called when the z axis overlaps without the 3D bottom of an object?

Link to comment
Share on other sites

  • 2 weeks later...

@Sam: Sorry I've not been around to answer your questions, but it looks like you've figured most of it out already! I'm afraid there's no built-in method for checking overlapping like that, you'd probably have to do some Point3 to Point comparisons to flatten down the dimensions. I think it'd technically be possible to apply Phaser's 2D Arcade Physics code to an isometric scene too, but it'd probably require a little bit of hacking.

 

@mwatt: Why thank you, you're very kind! :blush:

Link to comment
Share on other sites

Hi,

 

I have a question about "best practices". I want to make a simple map in which the user can drag & drop buildings. So one building will be shaped by one more tiles. I was wondering if it would be a good way to have the map being an IsoGroup with isoTiles to make the floor and isoGroup with isoTiles inside for the buildings ? 

 

Does exit a tile.isoBounds.containsXY(cursorPos.x, cursorPos.y) for isoGroup ?

 

What would be the best way to calculate if two isoGroup according to their content (isoTiles) intersect ?

 

Thank you

 

[edit] sorry - I miss-read the code, there is no isoGroup, that is just the groupe name you use. This post can be deleted.

Link to comment
Share on other sites

Hi,

 

I was wondering how to manage building like a tower for example that occupies only on floor tiles but something like 2 or 3 tiles in "heigh". Is that a good idea to split the tower in several tiles and then add them at the same x and y but different z in order to have the tiles behind the tower free ? 

 

Thank you

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...