PF Collision detection changes when const pfrowheight=7

[EvoMikeUK]

Hi All,

 

I am currently using the standard Kernel with the standard pfrowheight setting. My player sprite is 11 pixels high and 8 pixels wide.

 

I use the BB playfield collision example, modified for my game.

 

eg...

temp6 = (player0y-12)/8
temp5 = (player0x-10)/4


    if temp5 < 34 then if pfread(temp5,temp6) then goto __skipJoy0Up


    temp4 = (player0x-16)/4


    if temp4 < 34 then if pfread(temp4,temp6) then goto __skipJoy0Up


    temp3 = temp5 - 1


    if temp3 < 34 then if pfread(temp3,temp6) then goto __skipJoy0Up


if f = ((f / 2) * 2) then player0y = player0y - 1

This works perfectly.

However, when I change pfrowheight to be 7, this obviously then does not work the same, and i cant get it to. Any light on the replacement calculations i need to use... eg player0y + x / y etc for left, right up and down?

 

[+Random Terrain]

I never know. I just subtract a different number from player0y until it works. It helps to make a test program where you place a playfield pixel on or above or below your sprite and keep changing the numbers. When your sprite and playfield pixels line up perfectly (the way you want them to), you know your new numbers are correct.

[EvoMikeUK]

I never know. I just subtract a different number from player0y until it works. It helps to make a test program where you place a playfield pixel on or above or below your sprite and keep changing the numbers. When your sprite and playfield pixels line up perfectly (the way you want them to), you know your new numbers are correct.

Ok, thank you. Ive tried that but when moving up to a PF on the lower half its well off and ok towards the top of the screen, really confusing lol

[EvoMikeUK]

I never know. I just subtract a different number from player0y until it works. It helps to make a test program where you place a playfield pixel on or above or below your sprite and keep changing the numbers. When your sprite and playfield pixels line up perfectly (the way you want them to), you know your new numbers are correct.

Do you take off AFTER the calculation or inside?

 

eg

 

temp6 = (player0y-12)/8

temp6 = temp6 - 4 <---- new line

 

or change the amount you remove off player0y?

[+Random Terrain]

I forgot that the magic is in the number you are using to divide (you might also find that you have to use something other than player0y-12 if things aren't lining up correctly). You might have to use "include div_mul.asm" and divide using 7 or whatever works in your test program that matches the height of the pixels.

[EvoMikeUK]

I can’t get it to work at all :-(

 

Trying to use the text mini kernel and deduct the of to help cycles, but can’t do playfield collision. It’s been a frustrating evening lol

[+Random Terrain]

I'm not sure which example program you were using, so I just grabbed one of them, popped in "const pfrowheight=7" and a sprite that is 11 pixels high and 8 pixels wide, then played with the numbers (using pfpixel) until it worked:

 

ex_sprite_with_collision_prevention_and_pfrowheight7_2019y_02m_13d_0341t.bas

 

ex_sprite_with_collision_prevention_and_pfrowheight7_2019y_02m_13d_0341t.bin

 

I had to add an extra check in the left and right joystick sections for it to work correctly. Somebody who is better at programming and math could probably do it with less code.

 

Press the reset switch to flip between two different playfields.

[EvoMikeUK]

I'm not sure which example program you were using, so I just grabbed one of them, popped in "const pfrowheight=7" and a sprite that is 11 pixels high and 8 pixels wide, then played with the numbers (using pfpixel) until it worked:

 

ex_sprite_with_collision_prevention_and_pfrowheight7_2019y_02m_13d_0341t.bas

 

ex_sprite_with_collision_prevention_and_pfrowheight7_2019y_02m_13d_0341t.bin

 

I had to add an extra check in the left and right joystick sections for it to work correctly. Somebody who is better at programming and math could probably do it with less code.

 

Press the reset switch to flip between two different playfields.

I shall check this out when I get home

 

Amazing!!

[EvoMikeUK]

I'm not sure which example program you were using, so I just grabbed one of them, popped in "const pfrowheight=7" and a sprite that is 11 pixels high and 8 pixels wide, then played with the numbers (using pfpixel) until it worked:

 

ex_sprite_with_collision_prevention_and_pfrowheight7_2019y_02m_13d_0341t.bas

 

ex_sprite_with_collision_prevention_and_pfrowheight7_2019y_02m_13d_0341t.bin

 

I had to add an extra check in the left and right joystick sections for it to work correctly. Somebody who is better at programming and math could probably do it with less code.

 

Press the reset switch to flip between two different playfields.

 

Will this

 

include div_mul.asm

work alongside the new text mini kernel do you know? Kind thanks

[+Random Terrain]

Will this

---

include div_mul.asm

---

work alongside the new text mini kernel do you know? Kind thanks

 

You might want to ask Karl G.

[+Karl G]

I would be astounded if there was any incompatibility with that include and the text minikernel.

 

Also: just give it a try, and see what happens.

[EvoMikeUK]

I would be astounded if there was any incompatibility with that include and the text minikernel.

 

Also: just give it a try, and see what happens.

Ok, excellent, I'll report back when I know more

[EvoMikeUK]

I would be astounded if there was any incompatibility with that include and the text minikernel.

 

Also: just give it a try, and see what happens.

 

Ok, I am including the div_mul.asm and then dividing by 7, as to ensure my game can use pf = 7 so that I can use the text kernel and not go over my cycles.

 

This produced the error on compilation, but only then I actually try to divide by 7, not when I just include the div_mul include line.

 

--- Unresolved Symbol List

fontstyle 0000 ???? (R )

score_loop_height 1f48a ????

textscoreloop 0000 ???? (R )

SQUISH 0000 ???? (R )

div8 0000 ???? (R )

extendedtxt 0000 ???? (R )

FASTFETCH 0000 ???? (R )

scorebkcolor 0000 ???? (R )

Any ideas?

[+Karl G]

Try using inline instead of include for div_mul.asm, and do it in the same bank where you are making use of it, and see if that makes a difference.

[EvoMikeUK]

That mangles the screen when I do that, but it does compile and run.

[EvoMikeUK]

It only mangles when it calls the /7 line, runs fine until it hits that line.

[+Karl G]

I'm not sure what the issue would be, then. The "div8" in the compile error that you posted would indicate it wasn't finding the code from from the div_mul module. I thought that including it more explicitly in the same bank where you were doing the division would help. The mangling of the screen would happen if you did an inline in a different bank than the one where you did the division, so I'd double-check that to make sure that's not what happened.

[EvoMikeUK]

I'm not sure what the issue would be, then. The "div8" in the compile error that you posted would indicate it wasn't finding the code from from the div_mul module. I thought that including it more explicitly in the same bank where you were doing the division would help. The mangling of the screen would happen if you did an inline in a different bank than the one where you did the division, so I'd double-check that to make sure that's not what happened.

They are most certainly in the same bank. I feel we are getting closer, but as soon as I call that /7 the screen goes crazy.

[+Random Terrain]

When you first added "include div_mul.asm", was it near the beginning of your program in the first bank and before set romsize? Also look at the Did You Know? box here:

randomterrain.com/atari-2600-memories-batari-basic-commands.html#include

 

If none of that works, the bB page says "The division modules may not work properly on bankswitched games, and the 16-bit routines have not been fully tested."

[EvoMikeUK]

Hi, thanks again. No it was after set Rom size, its a 64kb RPG. Ill try again tomorrow, otherwise Ill have to just start cutting features to make the cycles. Im certain I want the text Kernel in the game so other sacrifices will have to made if I cant make pf = 7.

 

I am throwing a LOT at the Console even before adding the text.

[+Random Terrain]

Added the program to the bB page in case others need it in the future:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_sprite_collision_prevention_pfrowheight7

[EvoMikeUK]

Added the program to the bB page in case others need it in the future:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_sprite_collision_prevention_pfrowheight7

 

Great work!

 

Wish I could get it working in my game, your example is flawless though, I'll keep trying.

[+Karl G]

Here's an assembly routine to divide by 7, adapted from RevEng's site. You can use this instead of including div_mul.asm if that's the only thing you would need that module for.

 

This code assumes that the number to be divided is in temp1, and it puts the result in temp2. You can change temp1 and temp2 to any valid bB variable if you wish:

    asm
    lda temp1
    lsr
    lsr
    lsr
    adc temp1
    ror
    lsr
    lsr
    adc temp1
    ror
    lsr
    lsr
    sta temp2
end

[EvoMikeUK]

 

Here's an assembly routine to divide by 7, adapted from RevEng's site. You can use this instead of including div_mul.asm if that's the only thing you would need that module for.

 

This code assumes that the number to be divided is in temp1, and it puts the result in temp2. You can change temp1 and temp2 to any valid bB variable if you wish:

    asm
    lda temp1
    lsr
    lsr
    lsr
    adc temp1
    ror
    lsr
    lsr
    adc temp1
    ror
    lsr
    lsr
    sta temp2
end

 

Yes!!!! We are now in business it seems. Now I just need to reconfigure the whole game so far for this new amount of rows.

 

This community is a massive help, thank you!!

[EvoMikeUK]

Actually it works the first time, but the second time I call it, it doesnt, so I guess I can only use it once? Maybe use it in a sub?