Cybearg Posted June 11, 2013 Share Posted June 11, 2013 I was testing a line that SHOULD fill in the area in front of a sprite if it has no pfpixels and then clear it if there are pfpixels, but it does nothing. If I simply draw the pfpixels at all times, it works fine, but setting it up in this if statement does not work: temp1 = (player0x / 4) - 2 temp2 = player0y / 8 if !pfread(temp1, temp2) then pfpixel temp1 temp2 on else pfpixel temp1 temp2 off I've had troubles with pfread in the past, when testing some collision detection that Random Terrain was asking about. Apparently it worked for others when compiled but not for me. Any idea what is wrong? I am using the standard kernel. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted June 11, 2013 Share Posted June 11, 2013 Why don't you just use pfpixel temp1 temp2 flip ? Quote Link to comment Share on other sites More sharing options...
bogax Posted June 11, 2013 Share Posted June 11, 2013 pfread uses temp1 and temp2 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted June 11, 2013 Author Share Posted June 11, 2013 (edited) Why don't you just use pfpixel temp1 temp2 flip ? It's just a sample--I actually need pfread to work for collision detection purposes. This just seemed like an easy way to test it. pfread uses temp1 and temp2 Let me try different variables and get back. EDIT: By Jove, that fixed it! Thanks, bogax! Edited June 11, 2013 by Cybearg Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted June 11, 2013 Share Posted June 11, 2013 Maybe the extra note about using temp1 and temp2 could be added to the batari BASIC command reference? Also, the "inline pfread_msk.asm" never worked for me using the multi-sprite kernel. If someone else can double check then we can safely write this off as broken. Quote Link to comment Share on other sites More sharing options...
bogax Posted June 12, 2013 Share Posted June 12, 2013 Also, the "inline pfread_msk.asm" never worked for me using the multi-sprite kernel. If someone else can double check then we can safely write this off as broken. Here's one (mostly) in bB function msk_pf_rd() if temp1 & 8 then temp1 = temp1 ^ 7 if temp1 > 15 then temp1 = temp1 ^ 8 if temp1 & 8 then skip_PF1 asm ldy temp2 lda (PF1pointer),y sta temp2 end goto skip_PF2 skip_PF1 asm ldy temp2 lda (PF2pointer),y sta temp2 end skip_PF2 temp1 = temp1 & 7 temp1 = bits[temp1] & temp2 if temp1 then temp1 = 255 return data bits $80,$40,$20,$10,8,4,2,1 end Not sure it's right. msk_pf_rd_demo.bas Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted June 12, 2013 Share Posted June 12, 2013 What sort of mad sorcery is this bogax?!? Working pfread in multi-sprite?!? AWESOME!!!!!! Er, I suppose the function is hard coded to a height of 7? Most multi-sprite programs default to 80. Is there a way to hard code it to "const screenheight=80" instead of "pfheight=7"? Here is an example of a program that uses the usual 80: smoothcrl2.bas Quote Link to comment Share on other sites More sharing options...
bogax Posted June 12, 2013 Share Posted June 12, 2013 Er, I suppose the function is hard coded to a height of 7? Most multi-sprite programs default to 80. Is there a way to hard code it to "const screenheight=80" instead of "pfheight=7"? Here is an example of a program that uses the usual 80: I didn't look too closely a that but I think that's maybe only going to effect how you come up with the parameters, eg how player position translates to playfield coordinates. Quote Link to comment Share on other sites More sharing options...
bogax Posted June 12, 2013 Share Posted June 12, 2013 I just realized I've got some redundant code in there. function msk_pf_rd() if temp1 & 8 then temp1 = temp1 ^ 7 if temp1 > 15 then temp1 = temp1 ^ 8 if temp1 & 8 then skip_PF1 asm lda (PF1pointer),y sta temp2 end goto skip_PF2 skip_PF1 asm lda (PF2pointer),y sta temp2 end skip_PF2 temp1 = temp1 & 7 temp1 = bits[temp1] & temp2 if temp1 then temp1 = 255 return data bits $80,$40,$20,$10,8,4,2,1 end and here is something similar in asm function msk_pf_rd() asm bit bits+4 beq skip_eor07 eor #$07 skip_eor07 and #$07 tax lda temp1 bit bits+3 beq skip_eor08 eor #$08 skip_eor08 bit bits+4 bne skip_PF1 lda (PF1pointer),y bvc skip_PF2 skip_PF1 lda (PF2pointer),y skip_PF2 and bits,x beq skip_ldFF lda #$FF skip_ldFF end return data bits $80,$40,$20,$10,8,4,2,1 end Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted June 12, 2013 Share Posted June 12, 2013 Thanks for that. Please forgive me for being dumb and repeating myself. You think that your pfread replacement will work whether the playfield is 44 rows or 11? Quote Link to comment Share on other sites More sharing options...
bogax Posted June 12, 2013 Share Posted June 12, 2013 Thanks for that. Please forgive me for being dumb and repeating myself. You think that your pfread replacement will work whether the playfield is 44 rows or 11? Yes But I haven't tested it 1 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted June 12, 2013 Share Posted June 12, 2013 I'm not sure what bits to change to allow for the 44 row playfield. I hacked in the usual 44 row playfield into your example like so: rem msk_pf_rd demo includesfile multisprite.inc set kernel multisprite set romsize 4k dim sc0 = score dim sc1 = score + 1 dim sc2 = score + 2 dim sf = f const screenheight=80 player0x=25 player0y=50 COLUBK = $A2 COLUPF = $00 pfheight=1 playfield: ...XXXXXXXXXXXXX ...XXXXXXXXXXXXX ...XXXXXXXXXXXXX ...XXXXXXXXXXXXX ................ ................ ................ ................ ................ ................ ................ ................ ................ ................ ................ ................ ...XXXXXXXXXXXXX ...XXXXXXXXXXXXX ...XXXXXXXXXXXXX ...XXXXXXXXXXXXX ................ ................ ................ ................ ................ ................ ................ ................ ................ ................ ................ ................ ................ ................ ................ ................ ...XXXXXXXXXXXXX ...XXXXXXXXXXXXX ................ ...XXXXXXXXXXXXX end player0: %00000000 %00000000 %00000000 %00000000 %00000000 %00000000 %00000000 %00000000 %10000000 end main temp2 = ((SWCHA ^ $FF) & sf)/16 : sf = SWCHA temp3 = temp2 & 3 : player0y = player0y + dtbl[temp3] temp3 = (temp2/4) ^ 3 : player0x = player0x + dtbl[temp3] temp1 = player0x temp2 = player0y gosub update_scr temp1 = (player0x - 16)/4 temp2 = (player0y-3)/8 temp1 = msk_pf_rd(temp1, temp2) if temp1 then COLUP0 = $1A else COLUP0 = $44 drawscreen goto main data dtbl 0, 1, -1, 0 end function msk_pf_rd() if temp1 & 8 then temp1 = temp1 ^ 7 if temp1 > 15 then temp1 = temp1 ^ 8 if temp1 & 8 then skip_PF1 asm ldy temp2 lda (PF1pointer),y sta temp2 end goto skip_PF2 skip_PF1 asm ldy temp2 lda (PF2pointer),y sta temp2 end skip_PF2 temp1 = temp1 & 7 temp1 = bits[temp1] & temp2 if temp1 then temp1 = 255 return data bits $80,$40,$20,$10,8,4,2,1 end update_scr sc0 = 0 : sc1 = sc1 & 15 if temp1 >= 100 then sc0 = sc0 + 16 : temp1 = temp1 - 100 if temp1 >= 100 then sc0 = sc0 + 16 : temp1 = temp1 - 100 if temp1 >= 50 then sc0 = sc0 + 5 : temp1 = temp1 - 50 if temp1 >= 30 then sc0 = sc0 + 3 : temp1 = temp1 - 30 if temp1 >= 20 then sc0 = sc0 + 2 : temp1 = temp1 - 20 if temp1 >= 10 then sc0 = sc0 + 1 : temp1 = temp1 - 10 sc1 = (temp1 * 4 * 4) | sc1 sc1 = sc1 & 240 : sc2 = 0 if temp2 >= 100 then sc1 = sc1 + 1 : temp2 = temp2 - 100 if temp2 >= 100 then sc1 = sc1 + 1 : temp2 = temp2 - 100 if temp2 >= 50 then sc2 = sc2 + 80 : temp2 = temp2 - 50 if temp2 >= 30 then sc2 = sc2 + 48 : temp2 = temp2 - 30 if temp2 >= 20 then sc2 = sc2 + 32 : temp2 = temp2 - 20 if temp2 >= 10 then sc2 = sc2 + 16 : temp2 = temp2 - 10 sc2 = sc2 | temp2 return Quote Link to comment Share on other sites More sharing options...
bogax Posted June 12, 2013 Share Posted June 12, 2013 (edited) I'm not sure what bits to change to allow for the 44 row playfield. I hacked in the usual 44 row playfield into your example like so: change where player0y gets converted to playfield rows to divide by 2 instead of 8 temp1 = (player0x - 16)/4 temp2 = (player0y-3)/2 temp1 = msk_pf_rd(temp1, temp2) Edited June 12, 2013 by bogax 1 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted June 12, 2013 Share Posted June 12, 2013 change where player0y gets converted to playfield rows to divide by 2 instead of 8 temp1 = (player0x - 16)/4 temp2 = (player0y-3)/2 temp1 = msk_pf_rd(temp1, temp2) Dear lord you're good! That did it! I hope R.T. takes note that the semi-working pfread library isn't needed now that bogax has a working solution! Quote Link to comment Share on other sites More sharing options...
bogax Posted June 12, 2013 Share Posted June 12, 2013 (edited) Another one. Here I've taken the original pfread_msk.asm made some changes and put it in a bB function. It's shorter and faster. function msk_pf_rd() asm clc adc #$08 and #$1F cmp #$10 and #$0F tax lda bytemask,x bcc bytedone and (PF2pointer),y bcs skip_PF1 bytedone and (PF1pointer),y skip_PF1 end return data bytemask 1,2,4,8,$10,$20,$40,$80 $80,$40,$20,$10,8,4,2,1 end it's not rigged to return 255 for a set pfpixel it's just non zero Edited June 12, 2013 by bogax Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 12, 2013 Share Posted June 12, 2013 I hope R.T. takes note that the semi-working pfread library isn't needed now that bogax has a working solution! After he gets done working on it, maybe he can make a new thread that I can link to from the bB page. Quote Link to comment Share on other sites More sharing options...
bogax Posted June 17, 2013 Share Posted June 17, 2013 Also, the "inline pfread_msk.asm" never worked for me using the multi-sprite kernel. If someone else can double check then we can safely write this off as broken. I finally got around to looking at the original I don't find anything wrong with it, except that it uses a bogus opcode. It works for me. 1 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted June 17, 2013 Share Posted June 17, 2013 I finally got around to looking at the original I don't find anything wrong with it, except that it uses a bogus opcode. It works for me. Hey, thanks for the sanity check! It's probably related to the wonky way I code. Although it still could be one of those things that works in one revision of bB and not another. I'll trust your new pfread code a bit more since I know it works! Thanks again, man. 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.