CapitanClassic Posted July 21, 2020 Share Posted July 21, 2020 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 Quote Link to comment Share on other sites More sharing options...
+Karl G Posted July 21, 2020 Share Posted July 21, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
CapitanClassic Posted July 21, 2020 Author Share Posted July 21, 2020 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). Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.