Is Speed related to pixels per second as I may need to use a delay system.
When 'active object X,Y coordinates' = 'stationary active object' then send it back in the direction it came from. This sounds okay but sometimes it travels straight through depending on the speed. If I use the term 'equal or greater than' to one of the dimensions, it works fine but there was a reason I did not want to do this.
If your object is moving 5 pixels each time, it is actually jumping 4 pixels. Because of this your object can skip over the other one.
Try and do a movement with a fastloop, you can then check the position after every pixel whilst still maintaining the same speed. Search the articles section on fastloops if you need help.
Using the built-in movements, if something is going at Speed 100, it's moving 12.5 pixels per MMF loop (which is 1/50th of a second). So yes, if your object is going any faster than a speed of 8, there's a chance that it could skip over the exact coordinates that trigger your event.
I measured this in my game by getting the "fictional" height of the players sprite and working out how long it takes to walk 10 or so metres. But that's my silly way based on junior school maths.
Does your character accelerate or is their movement fixed?
Because if it's fixed you can get away with not using fast loops quite easily.
if not then think of it this way
if your character moves 1 pixel per frame the collision will be tested every time it's moved.
If it moves 5 pixels per frame it will still only be tested once but the character will have moved 5 times as far therefore get stuck in objects before it's stopped.
so you need to make fastloop test for collisions so it can be tested more than once per mmf loop.
in lil pirate the engine runs a collision test based on the walk counter. (or jump). It works something like this.
If walk counter is more of less than 0 run 'loopwalk' as many times as the number on the counter (make it Absolute since you can't run a loop -5 times)
upon 'loopwalk' + walk counter is less than 0 + left detector is not overlapping anything then move the mask - 1 (and all the other detectors)
upon 'loopwalk' + walk counter is greater than 0 + right detector is not overlapping anything then move the mask + 1 (and all the other detectors)
Which should make collisions perfect. But you still need to make the events to make the character actually walk. But you can make them move at 500 and it will slam into a wall perfectly.
Any problems could be as a result of forgetting to readjust the detectors or having their hotspot in the wrong place etc.
Andy... thanks for the info. My character (still square block) moves at a constant speed if that's any help... say, starts off at a speed of 20 and never changes. It isn't collisions I am worried about... it's more a change in direction at exactly the same coordinates as another block or blocks.
I've had alot of problems creating momentum-based movement via fastloops. Since the movement is 2 dimensional, its very difficult to "move 1 pixel at a time" in a fastloop, since using a complex algorithm to figure out where to move each loop often results in a game with 10-20 FPS, and using something simple like "choose randomly between X & Y" will result is horrendously wrong detection for a movement between two points where one dimension is small and the other large, like going from (1,10) to (10, 100000); it would travel in a straight line to (10,20) then go directly up.
Personally, I just gave up on the entire idea of detecting each step of movement, and instead work entirely with a posteri detection; using simple antistick ideas like setting an object to its last "good" position and reversing its X or Y velocity.
If you really do want to continue with checking movement inside a fastloop in a 2 dimensional scenario, you could try using average position steps, based off and preserving the beginning and end locations. For example, checking each position at a 1/10 of the difference, 2/10 of the difference, ect. The problem is that this is will fail just like regular detection as you get into large distances. But its a nice work-around if your movement is capped to say 10 pixels/frame in any direction.
I decided to restart the game from scratch using my own built in movement (actually it's nothing new) which also meant less coding. It is based on moving the character a desired number of pixels in one of four directions. I have used a resolution of 960 by 720 which is divisible by 60... which in turn is divisible by 1,2,3,4,5 and 6! So, speed 1 will equate to one pixel per screen update (very slow) up to 6 pixels (fast). 60 is also divisible by the multipliers of these numbers... 10, 12, 15, 20, 30 and 60 although the higher numbers are unusable. Using this method the pixel detection is spot on every time, however fast (or slow) the character is traveling!
Advertisement
Post Reply
Edited by the Author.
