## RE: [stella] Sprite position to Tombstone Matrix conversion

 Subject: RE: [stella] Sprite position to Tombstone Matrix conversion From: "Dennis Debro" Date: Sun, 18 Jan 2004 22:43:55 -0500
Hi Glenn,

> I'm working on creating a lookup table I can use in the collision routine
> for Death Derby where given the gremlin's X and Y, I figure out which RAM
> strip to write to, which row of the RAM strip, and which bit to turn on.

I don't know if this will help you but I'll post it anyway. It sounds like a
similar problem I had with random ladders in Climber 5. With the random
ladders I needed to calculate when the climber could move vertically. This
is the same problem you'd find in your typical maze game too.

This is from my Climber 5 comments. I hope they make sense.

;Theory behind the playfield computations
;The playfield is broken into chunks of 32 (based on the horizontal
;positions of the objects).
;The objects have a PF range of 7 - 135. (135 - 7) / 4 PF sections = 32
;The PF has 4 pixel res and there are 40 bits across.
;
;----------------------- PF Pixels -----------------------
;|  PF0  |   PF1   |   PF2   |   PF2   |   PF1   |  PF0  |
;|68 . 83|84 .. 115|116.. 147|148.. 179|180.. 211|212.227|
;                       -- or --
;----------------------- PF Pixels -----------------------
;|  PF0  |   PF1   |   PF2   |   PF2   |   PF1   |  PF0  |
;|0  . 15|16 ..  47|48 ..  79|80 .. 111|112.. 143|144.159|
;
;The climber has a horizontal range of 3 - 144 (72 - 213)
;In relationship to the PF that would be (80 - 221) ... pixels shifted by 8
;because of HMOVE
;
;And a PF range of 7 - 135 (76 - 204) -or- (84 - 212) ... again shifting 8
;pixels
;There are 4 sections of the PF that we're concerned about (PF1/PF2/PF2/PF1)
;So we subtract by 32 [(212 - 84) / 4] to find the PF section the climber is
;in
;We keep subtracting until the value is between the PF1 values (i.e. less
;than 116)

sbc #LEFT_PF_BOUND               ; subtract by LEFT_PF_BOUND to remove
offset
ldy #-1                          ; when done y will hold the PF section
the climber
; is in (0 - 3)
.computePFSection
iny                              ; increase the playfield section
sbc #32                          ; reduce the value to find the playfield
section
bcs .computePFSection
negative

lsr
lsr
sty pfSection                    ; y holds the PF section (0 - 3)
tay

.setPfSection
lda pfSection                    ; the playfield is reflected so sections
beq .loadPF1Vars                 ; 0 and 3 are for PF1 and sections 1 and
cmp #\$03                         ; 2 are for PF2

lda pf2Vars,x
sta upMotionCheck
lda pf2Vars-1,x
sta downMotionCheck
bcc .done

lda pf1Vars,x
sta upMotionCheck
lda pf1Vars-1,x
sta downMotionCheck

.done
lsr pfSection                    ; shift the pfSection to determine if
the
bcc .loadAndValue                ; playfield bits are flipped (sections 1
; and 3 are flipped)
tya
eor #\$07
tay
lda upMotionCheck
bne .checkForDown
ldx #%00010000
.checkForDown
lda downMotionCheck
bne .setVerticalMotion
txa
ora #%00100000
tax
NOP_W

.noVerticalMotion
ldx #%00110000

.setVerticalMotion
txa
ora allowedMotion                ; or with allowed motion to get climber
.setAllowedMotion                   ; motion
sta allowedMotion                ; store the value in RAM to be used
during
; VBLANK processing
.
.
.
.byte \$80,\$40,\$20,\$10,\$08,\$04,\$02,\$01

Maybe it helps...then again maybe it doesn't. I don't know about fast but it
gets the job done.

Take care,
Dennis

----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/