• entries
298
862
• views
243,445

# Leprechaun movement musings, part 2

305 views

Ah-ha! I've got it!Currently, the code is set up for six sprites - the player and five enemies. Each frame one sprite moves one pixel. So it takes 24 frames for a sprite to move horizontally from one PF block to the next.Now, what if I change this to fractional positioning for the enemies. The player I'll leave be because he can change direction in mid-move. What if I want to still limit myself to one full sprite movement update per frame. Okay, so let's make it take 30 frames for the enemies to move the 4 pixels. That gives the player a slight speed advantage.With fractional positioning, that's 4/30 = 0.1333 pixels per frame, or 34.1333/256 pixels per frame. Hmm... how to handle that roundoff error? Well 34*30 mod 256 = 252, so I need to somehow add 4 to the fraction over the 30 frames... Ah, heck let's just show you the code.lda xposf,xcmp #221 ; this sets the carry bit if a is >= 221adc #34sta xposf,xlda xpos,xadc #0sta xpos,xNow, I have to also figure it out for the opposite direction (subtraction), but that shouldn't be too hard. I've also decided to have both the player and the enemies fall at the same rate - 8 pixels in 24 frames. I never liked that gravity was seemely different for the enemies in Lode Runner.

lda xposf,x

cmp #36 ; clears carry bit if a < 36

sbc #34

sta xposf,x

lda xpos,x

sbc #0

sta xpos,x

Hi there!

Is that code time critical?

BCC fine

INC xpos,x

fine

Greetings,

Manuel

Nope, constant cycles not required. Thanks for the optimization, I just wasn't thinking this morning.

If all of the following actions for a monster take the same amount of time...

• Travelling one square horizontally
• Travelling one square vertically on a ladder
• Falling one square

Then it might make sense to arrange the play mechanic so that internally the monsters moved on four-pixel increments horizontally and one-row (however many pixels) vertically. Then arrange things so all the monsters are "out of phase" with each other.

If you do this, you can have monsters move visually on every display frame but only have to worry about collisions detection for at most one monster on any frame. One fractional motion counter could take care of all the monsters.

Supercat - hmm, I hadn't given any thought yet to enemy-enemy collision detection. I probably should simply to prevent / reduce overlaps.

My current frame loop goes something like this:

- every frame update the movement logic for only one sprite (player or one enemy). 5 sprites (player + 4 enemies) for PAL, 6 sprites (player + 4 enemies + 1 unused) for NTSC

- player sprite moves 1 pixel on movement logic frame, grid square is 4 pixels width, 8 pixels high

- falling sprites (player & enemy) move 1 pixel twice every sequence (so you fall twice as fast as climbing down)

- enemy sprites move 34.1333/256 pixels per frame

So I've already got a current sprite; everything is "out of phase". Of course, there's no code yet so things might change.

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.