[SOLVED: YOU CAN'T] How can one change an inherited public variable (x, y) to private or protected?

(Helios) #1

Hey guys! This question is asking for equal parts programming design advice and as3 language help!

for reference, I am making a 2.5d isometric action rpg.

the subclasses of Entity receive public variables x and y, but I would like to move objects around on screen according to their planar x, y, and z (respectively, their position left and right, their position near or far from the camera, and their height above the ground)

I don’t want any of my movement functions to be able to modify the screen position of my entity subclasses directly. I want to hard code in the need to use getters and setters to access and modify the x and y values. This is important, because I am working with multiple people coding, and it reduces the possibility of introducing error.

(JP Mortiboys) #2

You can’t, but in reality you probably wouldn’t want to anyway.

In an isometric world like yours, (x, y and z) are the world-space coordinates - for collision, distance calculations and whatnot.

Screen coordinates are what are used in the Graphics class. It’s true that the way FP is set up there isn’t a lot of difference, but in your case there would be.

One way of handling this is to set your graphic’s relative property to false, and then in the entity’s render function, set the graphic’s x and y properties based on your entity’s x, y and z:

public class MyIsoEntity extends Entity {
    var gfx:Image; // or whatever
    function MyIsoEntity() {
      gfx = new Image(...);
      gfx.relative = false;
      graphic = gfx;
    }

    override public function render():void {
      gfx.x = worldCoordsToScreenCoordsX(x, y, z);
      gfx.y = worldCoordsToScreenCoordsY(x, y, z);
      super.render();
    }
}
(Helios) #3

Alright, so I’m more or less terrified of mucking about in the render function. So, as long as I modulate the graphic’s x and y (in this case by the world space coordinates) and call the super function, I’m not going to break anything critical?

(JP Mortiboys) #4

No, you won’t break it! Just remember to call the super() function or the entity will be invisible.

(Helios) #5

So, I’m a little confused as to what “relative” means in this context. its a property of an image, not a graphic, right? and relative to what?|

alternatively, maybe theres a good tutorial out there on this?

you’re the best by the way. Still suspicious that you may, in fact, be a raptor.

(JP Mortiboys) #6

relative is a property of a Graphic of which Image is a subclass… I just used Image as an example. Entitys and Graphics both have x and y properties. When the Graphic has relative set to true, its x and y are relative to the Entity (it follows it), when it’s set to false its x and y are absolute - measured from the top-left of the screen, and do not follow it.

In a “normal” 2d game, the main graphic of a player entity would be set to relative. Similarly, if it had a hitpoint counter or bar above its head, that would be relative too, so when the entity moves the hitpoint bar would follow it. On the other hand, if the entity had a blood spatter effect (Emitter could do this in FP), that graphic would not be set to relative, since blood flying through the air won’t follow the entity as it moves.

In your case, since the x and y coords of the graphic are each dependent on both the x and y coords of the entity, making use of the relative property is more work, not less - just handle it manually.

And thank you! I couldn’t possibly be a raptor, of course - raptors can’t lie - it’s scientific fact!

(Helios) #7

Okay. so that seems to manage my image, but now my hitbox is not following my graphic!

is this something i have to fix by calling sethitbox every frame and passing it the graphic’s x and y data?

(JP Mortiboys) #8

Assuming your isometric entity is only going to be colliding against other isometric entities, you don’t need to - the hitbox will be in world space, as will all of the other isometric entities’.

Sure, it won’t look right on the debug console (although you could fix that if you really wanted to), but if you add two isometric entities using this method and check their collisions, you’ll see that a collision is reported when it should be,

If you really really want to perform your collisions in screen space, beware! There are lots of configurations where the sprites would overlap but a collision shouldn’t be registered - for example if one entity was a whole tile up and left (world space) it would be directly north of the other (in screen space); the sprites would overlap but the actual objects aren’t colliding. If you want to do it in screen space, you need to have the hitbox to be a smallish rectangle centred on the entity’s feet.

If you want the entities to collide in world space but also be pickable by the mouse pointer, transform the mouse coords from screen space to world space before you check the collision.

Oh, and isometric render order is great fun. It’s easy to determine, given two objects, which should be rendered first, but this property isn’t transitive, so you can’t use it as a compare function to sort a list. Also it’s entirely possible to have a set of objects which form a cycle (A is in front of B which is in front of C which is in front of A), impossible to render in a single pass. Fun fun fun!

(Helios) #9

ahhhh, fascinating! Foolish me, my test case was attempting to collide something using world coordinates with something using screen coordinates.

Thanks, NotARaptor! Clever girl…

(JP Mortiboys) #10

You might say I’ve been down this road before… http://shinyhappypixels.com/punk-forums/oblique/, http://shinyhappypixels.com/punk-forums/oblique-grid/