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

The X & Y coordinate layouts are different throughout engine (?) #5

Open
ghost opened this issue Apr 4, 2020 · 4 comments
Open

The X & Y coordinate layouts are different throughout engine (?) #5

ghost opened this issue Apr 4, 2020 · 4 comments

Comments

@ghost
Copy link

ghost commented Apr 4, 2020

Some (or all or many) portions of LITIengine are inverted or different as to the standard XY Graph I'm used to in the United States:
82338fea60fbf48fd86e2103ce7b3526

I do get it, it depends on what your starting corner is. I actually do like that maps start at 0,0 top left and left to right, get larger. Makes math easier. But I do think at the same time, everything should start top left also.

The bottom line is it seems like Camera() coordinates are different from Physics() coordinates are different from Creature() coordinates, etc, etc.

I'm not a math guy but I can figure stuff out through a lot of trial and error.
My first implementation on this thing was a visual debugger.

There's some inversion required when generating tmxMaps -> for y first, then for x

I had to inverse the player's movements to convert it into something Game.physics() can understand.
Here's some of the finagling I did to get collision to work properly:

Point2D oldPosition = _entity.getPosition();
Point2D newPositionCollisonInverse = _entity.getPosition();
Point2D newPosition = _entity.getPosition();
...
switch (keyCode.getKeyCode()) {
     case 87: timeRestrictedKeyPressed(); newPosition.setLocation(newPosition.getX(), newPosition.getY() + stepY); newPositionCollisonInverse.setLocation(oldPosition.getX(), oldPosition.getY() - stepY); break; //w
     case 65: timeRestrictedKeyPressed(); newPosition.setLocation(newPosition.getX() + stepX, newPosition.getY()); newPositionCollisonInverse.setLocation(oldPosition.getX() - stepX, oldPosition.getY()); break; //a
     case 83: timeRestrictedKeyPressed(); newPosition.setLocation(newPosition.getX(), newPosition.getY() - stepY); newPositionCollisonInverse.setLocation(oldPosition.getX(), oldPosition.getY() + stepY); break; //s
     case 68: timeRestrictedKeyPressed(); newPosition.setLocation(newPosition.getX() - stepX, newPosition.getY()); newPositionCollisonInverse.setLocation(oldPosition.getX() + stepX, oldPosition.getY()); break;  //d
}
boolean collides = Game.physics().collides(new Point2D.Double(newPositionCollisonInverse.getX(), newPositionCollisonInverse.getY())) || newPositionCollisonInverse.getX() < stepY || newPositionCollisonInverse.getY() < stepX;
if (!collides) {super.handlePressedKey(keyCode); HEROUtility.moveCreatureTransition(_entity, (int)newPosition.getX(), (int)newPosition.getY(), 10, 10);}
       

Github Project:
https://github.com/evnsch/OpenHero/blob/master/src/main/java/com/escho/game/creatures/hero/HeroController.java

@ghost ghost changed the title The X & Y coordinate standard/inverse conflict The X & Y coordinate layouts are different throughout engine (?) Apr 4, 2020
@steffen-wilke
Copy link
Collaborator

Welp, that's not something the LITIENGINE invented... Java AWT and Java 2D coordinate systems start from the top-left origin. Since the LITIENGINE is based on these Java implementations, we also inherited their way to handle coordinates.

Honestly: When I first learned Java, I was also really confused about this but over time I got used to it.

The bottom line is it seems like Camera() coordinates are different from Physics() coordinates are different from Creature() coordinates, etc, etc.

Actually that's not exactly true. While locations in the Environment are defined in the coordinate system of the map, the Camera just translates these locations to the viewport in order to render everything at the right place, respecting renderScale and zoom. So it's basically just a translated version of the same coordinate. There is no difference between the "physics-coordinates" and the "entity-coordinates".

To sum this up, the three "different" coordinates I can think of are:

  1. The map coordinates
    e.g. IEntity.getLocation(), Game.world().environment().getCenter()
  2. The coordinates on the tilemap's grid (aka. coordinates divided by tile size)
    e.g. MapUtilities.getTile(Point2D mapLocation),
  3. The coordinates on the viewport/screen (aka. where stuff is rendered)
    e.g. ICamera.getViewportLocation(...)

All of these coordinates are based on the same coordinate system and have their origin in the top-left corner. Hope that clarifies things.

@ghost
Copy link
Author

ghost commented Apr 4, 2020

Thanks for explaining. I don't claim any of this anything more than observations of a mathematically challenged programmer.

What's your take on my experience not being able to send a creature's coordinates directly into the collision engine? It's always exactly one tile off, but everything always starts at 0,0.

When I use the same coordinates, collision check & movement, everything is off by exactly one tile. I do really think that this is engine related.

@steffen-wilke
Copy link
Collaborator

steffen-wilke commented Apr 4, 2020

The PhysicsEngine is not tile-based in general. We have made games in the past were we checked for tile-based collision and we ended up using IEntity.getCenter() instead of IEntity.getLocation() if I remember correctly.

Btw: many thanks for your open thoughts on this. It's always great to hear a fresh objective opinion on some stuff that we take for granted in the engine.

@ghost
Copy link
Author

ghost commented Apr 4, 2020

No worries, it could be something I'm doing. Same thing with getCenter. I'll dig around in the debugger and see what we can find.

@steffen-wilke steffen-wilke transferred this issue from gurkenlabs/litiengine Sep 8, 2020
nightm4re94 pushed a commit that referenced this issue Dec 30, 2020
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

1 participant