4.5.6 grid based movement for player
- Thread starter jcramer
- Start date
Mugi
Member
you can read the players position by doing
on which after, if you wish for a button press for example, move the player up 16 pixels (one metatile)
you can simply do something like
Code:
LDX player1_object
; get horizontal offset of Player
LDA Object_x_hi,x
; get vertical offset of Player
LDA Object_y_hi,xon which after, if you wish for a button press for example, move the player up 16 pixels (one metatile)
you can simply do something like
Code:
; get horizontal offset of Player
LDA Object_x_hi,x ; load x offset of X (player1 is loaded in X above)
SEC ; set carry
SBC #$10 ; substract 16 pixels (substract for moving up, add for moving down)
STA Object_x_hi,x ; store the new value in player1's position
mouse spirit
Well-known member
Mugi's answer is right on but i had a workaround in mind. Maybe someon could use 2 states. Both "walking states" that switch back and fourth every second or so, but on the 2nd state, make it so you cant move. Possibly. All this can happen when holding a direction.
Mugi
Member
you can try to finetune it by writing a value to object_x_lo,x or object_y_lo,x for adjusting the subpixel positions. Im not exacly sure how joe's engine deals with the relations of the hi and lo values though, so you'll have to experiment with it a bit.
also keep in mind that the values are hex, not decimal, so #$10 means 16 in decimal, whereas #$09 is 9 in decimal
if you want to move, say 11 pixels, you use #$0B
also keep in mind that the values are hex, not decimal, so #$10 means 16 in decimal, whereas #$09 is 9 in decimal
if you want to move, say 11 pixels, you use #$0B
CutterCross
Active member
jcramer said:
#$10 isn't directly after #$09 btw. Remember they're hexadecimal values.
... #$08, #$09, #$0A, #$0B, #$0C, #$0D, #$0E, #$0F, #$10... etc.
mouse spirit
Well-known member
Awesome. I just meant like....
Start holding your walk button,so change to walk state ,but for only for 1 second.
While still holding walk button,change to stop state , but for only 1 second.
Base it off animation frames maybe, every 6 frames or at end of animation(6 frames) go to next state.
Same for the "stopped""walking"state.So you can walk,stop,walk,stop.
But it would take tweaking to make it perfect. These guys solution is much more efficient.
Start holding your walk button,so change to walk state ,but for only for 1 second.
While still holding walk button,change to stop state , but for only 1 second.
Base it off animation frames maybe, every 6 frames or at end of animation(6 frames) go to next state.
Same for the "stopped""walking"state.So you can walk,stop,walk,stop.
But it would take tweaking to make it perfect. These guys solution is much more efficient.
mouse spirit
Well-known member
Maybe im thinking of dragon warrior, you are thinking like pacman without walls, or like Kickle Cubicle.My bad.
My workaround would be an illusion anyway.And its a stop an go "grid" walk.
My workaround would be an illusion anyway.And its a stop an go "grid" walk.
mouse spirit
Well-known member
Cool. Yeah it would be good for a monster to walk a square then stop, change direction and walk a square then stop.
And thanks, i am a workaround typa person.
And thanks, i am a workaround typa person.
puppydrum64
Active member
I tried this and my character just jumps all over the place. Here is my sample code.
Code:
;;;;
TXA
STA temp ;; assumes the object we want to move is in x.
GetActionStep temp
CMP #$07
BNE +notHurt
RTS
+notHurt
StartMoving temp, #RIGHT
TXA
STA temp ;; assumes the object we want to move is in x.
ChangeFacingDirection temp, #FACE_RIGHT
;; Snap to Grid by Mugi
LDX player1_object
; get horiz. offset of player1_object
LDA Object_x_hi,x
SEC
ADC #$10
STA Object_x_hi,x
; get vert. offset of player1_object
LDA Object_y_hi,x
SEC
ADC #$10
STA Object_y_hi,x
RTS