Player and enemy moving at different speeds

In my game, I have my player (controlled with stick) and the enemy (chases the player). Of course though I want the player to move slightly faster than the enemy. How do I do that? I can't use wait because that slows down the whole programs instead of just the enemy. Vsync seems to do the same thing as wait so I probably shouldn't use that. What should I do?

Multiply stick input by some constant when assigning it to the new player position. Alternatively (or additionally), multiply enemy updates by a constant 0<x<1

Or you can assing enemy's specific variables and reduce their value by division. Something like this:

STICK OUT SX,SY

'player input movement'
PX=PX+SX*2
PY=PY+SY*2

EX=PX/1.3
EY=PY/1.3

'enemy chase here'
SPOFS ENEMYID,EX,EY

I'm not quite sure I understand. How do these things control the speed that the player or enemy (computer controlled by the way) moves across the screen? Sorry, you know how it is. New comer.

I figured it would be something like, the player sprite changes location every 5 frames, and the enemy sprite changes location every 7 frames.

See the line PX=PX+SX*2

PX  'Player X coordinate, however it's used later.
=   'assign the following expression's value to ^
PX+ 'We want to modify the current value of PX
     '(rather than overwriting it)
SX  'Raw stick input, i.e. some value between -.8~ and .8~
*2  'Multiply ^ by a(n arbitrary) factor of two.  
     'Instead of moving the player by e.g. .7 units, 
     'they would move 1.4 units with the same input.

right well, that's all and good but I don't that's what I'm looking for. I applied the code from Autz64 to my current program, and it made the player move faster the further you pushed the stick in a direction. the movement was very precise too, moving in the exact direction you pushed the stick. I don't want that. the stick is supposed to work like the plus pad. I want him to move at a constant speed in eight directions. his speed should never change, but it should be faster than the enemy's the way I had it configured was... IF SX > .4 THEN PX = PX + 2 and so on

did you possibly try IF SX > .4 THEN PX = PX + 3 (though in this case, you probably actually want to move the enemies by smaller increments, instead.)

yeah I did. and yes I do want to move the enemies by smaller increments. unfortunately increasing the amount of pixels he moves is a little to drastic of a change. Is there some way I can count the number of frames that go by? Or is there just no way to do it how I'd like it to be?

Is not that drastic, on most-basic levels movement is always pixel-based. And regarding your problem, i have a few ideas but none of them are optimal since i haven't tested it myself. I was playing right now and the game has the Instruction List included LOL. I never checked that. But anyway, you could use this:

SPFUNC management number, Label or Function

What this does is to assign a function or label to execute to an sprite, and then you can do the sprite check and speed check aside.

But anyway, you could use this:

I think the problem is on more of a basic level of "how to implement a timer"

But anyway, you could use this:

I think the problem is on more of a basic level of "how to implement a timer"

Right.

A timer huh. can I make it where the sprite location is checked every 10th of a second or something? or maybe the program could count the number of times it goes through the loop?

Multiply stick input by some constant when assigning it to the new player position. Alternatively (or additionally), multiply enemy updates by a constant 0<x<1

This is the easiest way of doing this. As long as character is not moving more than sixteen pixels at a time there won't be a problem (assuming that you're using 16x16 sprites). Visually, you shouldn't be able to tell the difference in most cases.

Multiply stick input by some constant when assigning it to the new player position. Alternatively (or additionally), multiply enemy updates by a constant 0<x<1

This is the easiest way of doing this. As long as character is not moving more than sixteen pixels at a time there won't be a problem (assuming that you're using 16x16 sprites). Visually, you shouldn't be able to tell the difference in most cases.

Actual, I'm using 16X32 sprites(or at least that's the size of the man). still though, could you tell me exactly what that would do? I don't quite understand what that's saying.

Multiply the x and y coordinates by some constant 0<c<1. So do SPOFS #,x*c,y*c. If this isn't fast enough for your game, then let me know. There are other things you can do.

well I tried it. It worked but I would prefer there to be some sort of way to count the number of screen redraws or frames? then I would just spofs the sprite again every 5 or 7 frames.

Not sure if this is what you mean but I have an idea. You can't count frames (at least that I know of), but you can use a variable to count time in some way. Use a timer variable; T = 0; Then in your main loop increment T by 1 every loop, and only allow enemy movement on even frames using the modulo operator.

... You can't count frames (at least that I know of, ...

Yes, you can. MAINCNT stores the number of drawn frames since start. You can store MAINCNT+7 in a var (NEXT) on startup, and in your main loop, if MAINCNT >= NEXT, do the enemy routine and do NEXT=MAINCNT+7 again.

... You can't count frames (at least that I know of, ...

Yes, you can. MAINCNT stores the number of drawn frames since start. You can store MAINCNT+7 in a var (NEXT) on startup, and in your main loop, if MAINCNT >= NEXT, do the enemy routine and do NEXT=MAINCNT+7 again.

I'd strongly recommend NEXT=NEXT+7 instead. If your loop happens to take more than 1 frame sometimes, then NEXT=MAINCNT+7 will be less than 1/7th of the frame rate, and diverging from it more if more iterations take longer. NEXT=NEXT+7 will ensure a constant frequency (as long as an iteration doesn't take as long as 7 frames); the phase may be a bit jittery, that's unavoidable if one iteration takes that long, but the frequency will be steady. And of course, all of this is bad advice, because NEXT is a reserved keyword. Pick another name.