Thanks so much for the tips everyone. I probably didn't explain myself well enough. I meant that I have bool variables for each direction, and that I wanted a pointer that would point to the last bool direction that the character was moving in. Then I had a function that took care of movement depending on which bool I was using.
I'm not too familiar with enums, but I'm definitely going to use that. So if I do have
public enum Movement { Up = 0x0, Right = 0x1, Down = 0x2, Left = 0x4, None = 0x8, Last = 0x10};
will all these directions be saved into one int variable?
Edit: Actually, I would need a Movement last; variable wouldn't I? Without Last being part of the enum. Then its directions could be set through my movement() functions.
Thanks so much for the tips everyone. I probably didn't explain myself well enough. I meant that I have bool variables for each direction, and that I wanted a pointer that would point to the last bool direction that the character was moving in. Then I had a function that took care of movement depending on which bool I was using.
I'm not too familiar with enums, but I'm definitely going to use that. So if I do have
public enum Movement { Up = 0x0, Right = 0x1, Down = 0x2, Left = 0x4, None = 0x8, Last = 0x10};
will all these directions be saved into one int variable?
You also need to set the Flags attribute, here's a link to the MSDNdocumentation on enumeration types (including bit flags and how to add/remove flags).
Edit: Actually, I would need a Movement last; variable wouldn't I? Without Last being part of the enum. Then its directions could be set through my movement() functions.
Sounds fine. Just one thing: Now you set your number to behave like (binary) flags, though without using the Flags attribute. Does it make sense that a movement can be both Up and Down, for instance ? Probably not. (Oh, my, ninja-ed again).
Edit: By the way: If you actually want flags, then it's done wrong: Up == 0, so you can't set the Up-flag.
will all these directions be saved into one int variable?
Yes, this is the default type. You can select the integral type yourself though:
public enum Movement : short { Up, Down, Left, Right, None};
The problem with a regular enum would be that you could very well be moving left and up at the same time, so that's why the bit flags would be more helpful in my opinion. I wouldn't really have the "Last" because you could just pass the state however you like.
From an input point of view, Up/Down, Left/Right isn't that much of a mind boggler since you would be able to check for when not to move. E.g. someone presses W + S at the same time on standard WSAD controls, then you shouldn't go up or down. But that doesn't sound right if you reverse the thinking, and the state becomes the current direction the object is moving in. If its the latter case, then you could very well have two regular enum in your pac-man entity that define hiss current move state. One for up/down, one for left/right, and only he can set these states based on user input. That way he's only ever moving in one or the other, and not both at the same time.
Edit: Heh I got ninja'ed too with all these post edits.
I don't know why everyone is freaking out about bitflags and enumerations when we're talking about some flags which will probably be touched at most twice a frame. I don't think there is a huge amount of benefit to be gotten from worrying about the low level details of this.
I'd probably just go with two integers, using "0" for not moving and "-1" and "+1" for left and right. The advantage of this approach is that it is very easy to move the player, take its velocity and multiply it by the direction. I do this to reduce the amount of if statements you otherwise have to write. It also works nicely with event based programming and pressing releasing keys, as you can implement LeftDown() as direction -= 1 and RightDown() as direction += 1, and then when the user does odd things such as press Left, Right, release Left the player moves as expected.
It might be faster to do this than a bunch of conditional checks but I've never bothered to look into it, as I said the value is inspected once a frame and updated very infrequently (relative to framerate), so it has never been a bottleneck for me. The exact implementation isn't really important, provided it works.
Just for clarification in terms of being stored as a "int" variable. The storage size is an int, but you don't store in an int variable directly. The enum is a wrapper which you use as the variable type which forces you to set the value to one of the ones provided in an enum. Using the movement scenario from unbird above.
public enum Movement { Up, Right, Down, Left, None, Last }; // Values will be 0, 1, 2, etc
public class Player
{
private Movement currentMovement; // It will be stored internally as a int but only relevant if you serialise etc
public void GoUp()
{
currentMovement = Movement.Up;
}
}
I don't know why everyone is freaking out about bitflags and enumerations when we're talking about some flags which will probably be touched at most twice a frame. I don't think there is a huge amount of benefit to be gotten from worrying about the low level details of this.
I'd probably just go with two integers, using "0" for not moving and "-1" and "+1" for left and right. The advantage of this approach is that it is very easy to move the player, take its velocity and multiply it by the direction. I do this to reduce the amount of if statements you otherwise have to write. It also works nicely with event based programming and pressing releasing keys, as you can implement LeftDown() as direction -= 1 and RightDown() as direction += 1, and then when the user does odd things such as press Left, Right, release Left the player moves as expected.
It might be faster to do this than a bunch of conditional checks but I've never bothered to look into it, as I said the value is inspected once a frame and updated very infrequently (relative to framerate), so it has never been a bottleneck for me. The exact implementation isn't really important, provided it works.
I don't think anyone's freaking out, no one's talking about this being a bottleneck - just having a friendly discussion. Of course what works, works. This is actually how I handle input for simple WSAD controls because its really really simple and straightforward. But I think one of the topics the OP is also talking about is how to convey the current state of the pac-man (e.g. to other entities), and having just an int isn't really all that readable in my opinion. But in the end game, it's all really just the same - as long as it works.
