ID:118068
 Sep 3 2011, 6:55 pm
|
|||||||
Redundant
| |||||||
I've been tinkering with the pixel movement system for a couple of hours now, and my only true issue with it seems to be the lack of a simple method to move an object an awkward amount of pixels in the x and y directions. step() is lacking because of its focus on the 8 major directions; taking 2 steps (one for x and one for y) can cause problems if you're not using a fairly high framerate, and even then, it only reduces the rate at which they occur (for example, if you're step()ing horizontally before vertically, you may bump an object to the west of you, rather than the object to the northwest). Using Move() is also fairly annoying because it involves handling a couple of different turf and position checks that one would expect to be handled internally.
| |||||||
I'm not sure what you mean about the turf and position checks. To move an object 6 pixels east and 3 north, you'd just use Move(loc,dir,step_x+6,step_y+3).
Tom and I have discussed options for making such a thing easier, but I'm not sure what complexity you're referring to. | |
From what I've experienced, that snippet doesn't function too well. Though I just retried it and it actually moved my object (last time I couldn't even move it, which means that I probably just screwed something up), it still doesn't seem to work properly.
For example, in my Pong game, which has a 1 pixel boundary on the top and bottom of the map, the ball gets stuck because Bump() is never called, which is because I'm attempting to move it outside the boundaries of the map. In order to work around this, I have to convert the location into pixels and make sure that the net pixel location after the move will still be on the coordinate grid, then modify it as necessary and convert it back into a turf and a step_x and step_y. Also, like Kaiochao mentioned, a float version of the loc variable would be nice, though that's a little more feasible to do yourself and round. EDIT: This is the workaround I made, I could probably simplify the MoveByPixels() proc though now that I know I can do what you mentioned plus the checks I'm already using. | |
I've tinkered with your workaround by giving the mob px, py, vx, and vy variables.
-px/py are exact positions with decimals. -vx/vy are how many pixels the position is shifted each tick (via infinite loop). The only problem that complicates this is the fact that collisions don't affect how vx/vy is added to px/py each tick. I tried moving twice, once with a horizontal offset, and once with a vertical offset, and checking the return value, but to no avail. I think I'm gonna have to do something complicated. | |
I would like to see this feature added. Splitting the move into separate x and y components produces a different move. The end result might be the same, but sometimes it isn't.
The support for fractional moves would also be nice. My library provides it and it's easily compatible with the new feature, but still not entirely correct. I can't think of many problems coming up now, but if new geometry is added that can have boundaries with decimal values this would be needed for correctness of collisions. | |
Ter13 resolved issue (Redundant)
Move() accepts a step_x and a step_y coordinate argument. | |
pixel_move(dx, dy): Shift an object's pixel position to pixel (px + dx, py + dy).
/* Off-topic
-angle_move(angle, magnitude): Shift an object's pixel position to pixel (cos(angle) * magnitude, sin(angle) * magnitude).
-Though I'd prefer to use bearings instead of angles. 0 degrees = NORTH, 90 degrees = EAST, so bearings are just 90-angle.
*/
This kind of movement would only work if pixel positions were floats(decimals) instead of integers.
Until then, I suppose I'll have to go back to using Forum_account's Pixel Movement library.