'pfread' and 16kSC kernel option...

[PacManPlus]

Hi:

 

I was just wondering if anyone was using 'pfread' successfully along with the SC (16kSC) kernel option. I seem to get funny responses when I use it in an 'if' statement. I am assuming that the arguments are the x, y coordinates (in that order). Is the valid 'x' range 1-40 or is it 1-32? What is the valid 'y' range when I am using a pfres of 32? Can I check all 32 (31) lines?

 

Thanks

 

Bob

[SeaGtGruff]

I was just wondering if anyone was using 'pfread' successfully along with the SC (16kSC) kernel option. I seem to get funny responses when I use it in an 'if' statement. I am assuming that the arguments are the x, y coordinates (in that order). Is the valid 'x' range 1-40 or is it 1-32? What is the valid 'y' range when I am using a pfres of 32? Can I check all 32 (31) lines?

Good question; I'll check it out tonight and see.

 

Michael

[SeaGtGruff]

I was just wondering if anyone was using 'pfread' successfully along with the SC (16kSC) kernel option. I seem to get funny responses when I use it in an 'if' statement. I am assuming that the arguments are the x, y coordinates (in that order). Is the valid 'x' range 1-40 or is it 1-32? What is the valid 'y' range when I am using a pfres of 32? Can I check all 32 (31) lines?

Good question; I'll check it out tonight and see.

 

Michael

I just checked out the pfread function when using the Superchip, and it seems to work okay. You are correct about the format being pfread(x,y). The x value can range from 0 to 31, because there are 32 playfield pixels on each row in bB, and they're numbered from 0 to 31. The y value can range from 0 to pfres-1, or 1 less than the pfres value. Without the Superchip (and using the standard kernel), there are 12 playfield rows, so y can be 0 to 11. But with the Superchip, you can have up to 32 playfield rows, so y can be from 0 to 31 (if pfres is set to 32).

 

Michael

[PacManPlus]

Cool...

 

Thank you very much Michael; I really appreciate the help.

 

I'll check on what I'm doing wrong

 

Bob

[Fort Apocalypse]

I'll check on what I'm doing wrong

 

Bob

 

Please post some code so we can check it out. If you're using temp variables, Curtis suggested not using temp1-3 (I had some problems with playfield collision detection which were probably a result of me using them).

[Fort Apocalypse]

I'll check on what I'm doing wrong

 

Bob

 

Please post some code so we can check it out. If you're using temp variables, Curtis suggested not using temp1-3 (I had some problems with playfield collision detection which were probably a result of me using them).

 

Also, note you can't use pfread with multisprite kernel.

[+batari]

I'll check on what I'm doing wrong

 

Bob

 

Please post some code so we can check it out. If you're using temp variables, Curtis suggested not using temp1-3 (I had some problems with playfield collision detection which were probably a result of me using them).

 

Also, note you can't use pfread with multisprite kernel.

You can, but you need to specifically include the module for it.

 

Place inline pfread_msk.asm in the last bank, somewhere outside of your program. (For a 4k game, include will work as well.)

[PacManPlus]

I'll check on what I'm doing wrong

 

Bob

 

Please post some code so we can check it out. If you're using temp variables, Curtis suggested not using temp1-3 (I had some problems with playfield collision detection which were probably a result of me using them).

 

 

I figured it out I was using temp1 and temp2 for calculating screen positions

Thanks guys!

 

Bob