@Melkon I get you now. I guess the syntax just slipped my mind.

@Pink Horror Using GetX/GetY gives me the same result.

@Nypyren I figured it was some weird memory thing, because it gives me the same value regardless of what the value actually is.

I guess I forgot to mention, the "other" object is a Block object, which is practically identical to the Player object, except it has a different sprite and a velocity of 0. The problem is that it IS initialized, the COORD variable DOES have actual values, and if I output the coordinates from the Block object, it gives me the correct result. The only time it gives me issues is when I pass the Position (20, 10) to somewhere outside the Block object.

Show the constructors for Block and Player.

Block::Block(short x, short y) :
    ID (eIDBlock)
{
    Position.X = x;
    Position.Y = y;
    Dimensions.X = 16;
    Dimensions.Y = 16;
    Velocity.X = 1;
    Velocity.Y = 0;
    Velocity.Z = 0;
}

Player::Player(short x, short y):
    ID (eIDPlayer)
{
    Position.X = x;
    Position.Y = y;
    Dimensions.X = 16;
    Dimensions.Y = 16;
    Dimensions.Z = 0;
}

Check IN the getter if they have a valid value before the return, or not.

I would put a data breakpoint on the COORD (well, the associated one in heap memory, not the temporary/stack variables) that reports bad values to find out exactly when it's being changed. It's possible you're stomping over memory in some completely unrelated code.

Can we see the declaration for Block? And what is ID? Does it inherit from Entity? What's your complete inheritance chain?

Only thing I can think of is that maybe you have duplicate declarations of Position (i.e. declared in Block and again in Entity, and you're only setting the value in Block).

Agreed with phil_t - if you have an extra Position accidentally defined in your derived classes, really "fun" things can happen.

I don't know how to get rid of this code box :D

I haven't written a virtual destructor for Entity. Is that essential? I don't create any new objects inside them, so I figured the default one would kick in, or am I forgetting something? If so, what should I put as a virtual destructor?

The consequences of non-virtual destructors in polymorphic classes have more clever effects than that. When you call a destructor of a derived class, the base class destructors get called automatically whether they are virtual or not, but when you cast a derived class to it's base class (as is often the case) there is no guarantee that the derived destructor will be called. The results of this are undefined behavior, although generally you'll end up destroying only the base part of the object.

@Melkon/Nypyren Yeah, I tried that.

@phil_t Okay, so I looked it over, and it turns out that I did redeclare Position, Velocity, and Dimensions in my derived objects. I took them out and now it works perfectly.

@boogyman So what exactly would I put for a virtual destructor? For anything, really? They don't have any assets I necessarily need to delete, I think.

Once again, thank you all for your help.

@boogyman So what exactly would I put for a virtual destructor? For anything, really? They don't have any assets I necessarily need to delete, I think.

It still needs to be marked as virtual. So write one that does exactly nothing.

virtual ~Entity() { }