Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[isometric] - Object position not correctly handled #51

Closed
eschnou opened this issue Apr 21, 2012 · 19 comments
Closed

[isometric] - Object position not correctly handled #51

eschnou opened this issue Apr 21, 2012 · 19 comments
Milestone

Comments

@eschnou
Copy link

eschnou commented Apr 21, 2012

In an isometric mode, the position x:0, y:0 corresponds to the first tile, which is at the top of the diamond. However, when assigning my player at this position using Tiled, melonJS places the player at the screen coordinates 0:0.

I've just started playing with Melon and Isometric stuff, so I don't know to which extend the whole coordinate system as to be changed to support isometric types of worlds. I would be happy to work on a patch for this, but have no clue where to start looking and what would be the best way to fix it. Let me know if you are actively working on isometric

@andyveliz
Copy link

Proposed solution in #96

@andyveliz
Copy link

Allright, i have some new information about this, i was talking about it in my pull request #96 besides the problem of not showing the "tile objects" these object are getting incorrectly positioned in the map, because of the way that tiled saves the position in the tmx file, actually, any kind of object have this issue, including the "mainPlayer".
My code in the pull request solved this, i hope you can include some of it, or maybe come up with another way to fix it.

you can see the problem here: http://enoc.akrontec.cl/iso-test/

and you can download the project files here: http://enoc.akrontec.cl/iso-test/iso-test.zip

this demo is using the last version of melonJS downloaded and built 10/30/2012 from github

i hope this can help anyone developing iso games.

@melonjs
Copy link
Collaborator

melonjs commented Nov 2, 2012

Hi,

I also discussed the point with parasyte before, and the "future-proof" idea was to add an additional translate operation (through context.translate) in the draw function of Sprite object to position the object correctly in an isometric world. I tried to do so, but did not manage to find the right mathematical formula for it

the proposed solution is working, but only when object are initially placed in the world, further draw are not managed. And I don't want for each draw to convert back from Ortho to tile, and then to tile to iso (it's too CPU demanding).

I wish we had some isometric expert or guru among us :)

@andyveliz
Copy link

and how about doing it the way tiled does it?

in tiled you have a global renderer, that it can be ortho or isometric, since in one map you cant have an isometric layer and an ortho layer, and the drawing process all go through the renderer, so in that way, you can make sure all objects and all tiled layers are drawn correctly.

what do you think?

@adamlatchem
Copy link

Hi, for reference here is the Tiled isometric render-er it has comments in the .h on how the Tiled projection works and the .cpp looks to contain the maths in the drawGrid() and drawTileLayer() methods:

https://github.com/bjorn/tiled/blob/master/src/libtiled/staggeredrenderer.h
https://github.com/bjorn/tiled/blob/master/src/libtiled/staggeredrenderer.cpp

Is it the case that MelonJS assigns a renderer to each layer? If so you could put the translate on the render-er so the drawing, collision and movement logic all use the same translation then you could mix layers with different renderings which though not supported by Tiled could be useful for in game effects and would come for free?

@bjorn
Copy link

bjorn commented Feb 26, 2013

@adamlatchem Actually I'm pretty sure this issue talks about the IsometricRenderer, not the StaggeredRenderer. For the latter, objects are not even supported properly in Tiled yet because I'm unsure how to deal with its strange coordinate system.

So, for this issue the reference should be this class:

https://github.com/bjorn/tiled/blob/master/src/libtiled/isometricrenderer.h
https://github.com/bjorn/tiled/blob/master/src/libtiled/isometricrenderer.cpp

@adamlatchem
Copy link

@bjorn yes that maybe the case. I was going party on this comment at the start of staggeredrenderer.h:

/**

  • A staggered isometric renderer.
    *
  • This renderer is meant to be used with isometric tiles, but rather than
  • doing a true isometric projection the tiles are shifted in order to fit
  • together. This has the advantage that the map has a rectangular shape.
    *
  • Only one variation of staggered map rendering is supported at the moment,
  • namely shifting the uneven rows to the right.

So what is the main difference between the two we have found here (and which fits best with MelonJS)?

@bjorn
Copy link

bjorn commented Mar 4, 2013

@adamlatchem Whether you want a true isometric map or a staggered / zigzag one depends on your game. I don't think either of them is a better fit than the other for melonJS. Both of them are less efficient than orthogonal maps since with isometric tiles you're drawing transparent pixels 50% of the time (that's why some games that look isometric are actually using orthogonal maps where just the graphics on the tiles are isometric).

@adamlatchem
Copy link

@bjorn so might it be useful for @eschnou to implement both as options? The idea being the maths can come from the .cpp files we found?

@bjorn
Copy link

bjorn commented Mar 4, 2013

@adamlatchem Yes, both are interesting to implement. However, melonJS already supports the true isometric one (this issue is just about a shortcoming in handling object positions), while the staggered one is just added in Tiled 0.9 and hasn't been used a lot yet. Also, it does not render objects at the moment. It is of course planned to be further worked out in future Tiled versions, depending on demand.

@adamlatchem
Copy link

@bjorn ah okay understood. I wrote the below 'test' using the ideas in the staggered renderer comment:

http://www.intrepiduniverse.com/betaTest/emeraldstarlight/index.php

it doesn't use MelonJS (its just a few lines of javascript to get it done) but it does use a tiled map so I think shows it is along the right lines i.e. take tiled map and some isometric tiles and lay out as in Tiled - I needed to convert mouse clicks back to objects so the code needed to reverse the projection also. But maybe I am not solving the same problem?

@bjorn
Copy link

bjorn commented Mar 4, 2013

@adamlatchem If that is using a staggered Tiled map, then indeed your code has little to do with this issue. If staggered isometric support is to be added to melonJS I think it would be a separate issue.

@adamlatchem
Copy link

@bjorn ah okay cool - sorry to get wires crossed !

@andyveliz
Copy link

Hello All! i want to continue with the debate in this topic, to see if we can finally fix this :) ... to summarize what's happening:

  • Tiled stores the position of an isometric object, in pixels, taking the bottom middle pixel of the object, but based on isometric origin of the map (top middle), and counting the pixels just like the map where rotated 45 degrees clockwise:
    eleccion_posicion_iso1

The problem presents when melonJS interpret this position ortogonally

eleccion_posicion_iso2

Maybe the correct question to ask, before go any further with this development is: should we transform the position of the isometric objects to ortogonal coords? or just, let the isometric object have the "wrong coordinates" and apply a transformation when drawing?

I think we should keep in mind that when checking if an object should be drawn we use:

// check if object is visible obj.inViewport = obj.visible && (obj.floating || (obj.getRect && api.viewport.isVisible(obj)));

and
api.viewport.isVisible : function(rect) { return rect.overlaps(this); },

so having the wrong coordinates may result in the object not getting drawn when it should.

So, if we choose to keep the coordinates as their are, we should change the way the viewport checks if an object is visible.

What do you think??

maybe there's another easier approach...

@bjorn
Copy link

bjorn commented Apr 11, 2013

@andyveliz Wonderful images to demonstrate the issue! Until now I didn't even exactly understand what the problem was on the melonJS side.

I would suggest to convert the coordinates to their orthogonal equivalent when loading the map. In the end it's up to you guys though, either approach will work. It's just that I kind of regret taking this approach to store isometric coodinates.

@parasyte
Copy link
Collaborator

Yeah, isometric support needs a lot of love in melonJS. I agree with @bjorn that melonJS should internally convert the object coordinates to an orthographic system. melonJS already supports two coordinate systems: world coordinates and screen coordinates. I would hate to confuse programmers by adding a third system for isometric perspective maps. :)

... Not to mention translating between "isometric world coordinates" and screen coordinates would be just awful ...

@andyveliz
Copy link

how do you feel about this?

andyveliz@7b7541e

@bjorn
Copy link

bjorn commented Apr 12, 2013

@andyveliz That looks quite decent. You should drop or update that duplicated comment though:

// Offset the object position by the tileheight
// (Objects origin point is "bottom-left" in Tiled, "top-left" in melonJS) 

That comment is also out of place:

//tiled places the origin of an object in the bottom center of the image 

Since you put it along with the orthogonal render code which does not translate from the bottom center.

@obiot
Copy link
Member

obiot commented May 13, 2013

This one is actually closed !

Make me thought however about adding an align property to object (as we have in font), that would allow to specify the default alignement for object ("top", "bottom", etc..)

@obiot obiot closed this as completed May 13, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants