Trying to pfread playfield pixels gives strange results.

[CapitanClassic]

I am having an issue with reading if a playfield pixel is on using bBasic and the DPC+ kernel.

 

I have a playfield that is 32x44 pixels (each 4x4). There is color banding such that each even row (starting with 0, TOP) is the same color, and each odd row (starting with 1, BOTTOM) is another color. Each playfield pixel I am interested in is 4x8, consisting of a top colored one color, and a bottom of a different color.

 

What I am trying to do is check if either the TOP or BOTTOM of a playfield pixel is already turned on. If it is, then get another random pixel.

 

The code bellow will eventually fill the screen, and will loop endlessly searching for an unfilled bottom playfield pixel. I have a similar subroutine for the pfpixelTOP, but when the TOP pixel is already filled in, the code below doesn’t recognize it is already filled in, and fills in the bottom anyway. What am I doing wrong for the check top and check bottom already filled pfread calls?

 

Is there a way in Stella to debug the DPC+ ram values or bBasic (I.e. could I assign temp5 to a bBasic variable or read/display the pfpixels status var000-var127?)
 

__mainLoop

    gosub __fillPlayfield

    ; playfield is 32 x 44
    ; each pixel is 4x4
    DF6FRACTION = 128
    DF4FRACTION = 128

    DF0FRACINC=64
    DF1FRACINC=64
    DF2FRACINC=64
    DF3FRACINC=64

    drawscreen
    goto __mainLoop

__fillPlayfieldBottom
   
__checkPFBottom
    ; get random X pixel range 0-31
    temp3 = (rand & 31)

__nextVert
    ; get random bits covering Y range
    ; only need 22, since each pfpixel consists of top+bottom
    temp5 = (rand & 31)

    ; outside random range for bottom 1-43
    if temp5 > 21 then goto __nextVert
    temp5 = (temp5 * 2)+1

    ; check bottom already filled
    if pfread(temp3,temp5) then __checkPFBottom
    ; check top already filled
    if pfread(temp3,temp5-1) then __checkPFBottom

    ; not already filled, so fill it
    pfpixel temp3 temp5 on

    return

 

[+Karl G]

It doesn't look like pfread writes over any of the temp variables, so I don't think that's the issue. I'm not sure that "temp5-1" would work as an argument to pfread thought, so I'd suggest putting that calculation into another temp variable, and see if that helps

[CapitanClassic]

42 minutes ago, Karl G said:

It doesn't look like pfread writes over any of the temp variables, so I don't think that's the issue. I'm not sure that "temp5-1" would work as an argument to pfread thought, so I'd suggest putting that calculation into another temp variable, and see if that helps

Thanks that was it. I didn’t realize that when bBasic makes its first preprocessing pass it couldn’t correctly parse that value. (Kind of makes sense, since it is a run-time variable).