Jump to content
  • entries
    298
  • comments
    862
  • views
    243,445

Leprechaun movement musings, part 2

Sign in to follow this  
Guest

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.

Sign in to follow this  


5 Comments


Recommended Comments

lda xposf,x

cmp #36 ; clears carry bit if a < 36

sbc #34

sta xposf,x

lda xpos,x

sbc #0

sta xpos,x

 

Spreadsheets are wonderful what-if tools.

Share this comment


Link to comment

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.

Share this comment


Link to comment

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.

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...