Jump to content

Photo

PF Collision detection changes when const pfrowheight=7


25 replies to this topic

#1 EvoMikeUK OFFLINE  

EvoMikeUK

    Star Raider

  • 85 posts

Posted Tue Feb 12, 2019 2:19 PM

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?

 



#2 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,956 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Tue Feb 12, 2019 2:42 PM

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.



#3 EvoMikeUK OFFLINE  

EvoMikeUK

    Star Raider

  • Topic Starter
  • 85 posts

Posted Tue Feb 12, 2019 2:46 PM

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



#4 EvoMikeUK OFFLINE  

EvoMikeUK

    Star Raider

  • Topic Starter
  • 85 posts

Posted Tue Feb 12, 2019 2:47 PM

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?


#5 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,956 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Tue Feb 12, 2019 3:22 PM

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.



#6 EvoMikeUK OFFLINE  

EvoMikeUK

    Star Raider

  • Topic Starter
  • 85 posts

Posted Tue Feb 12, 2019 4:27 PM

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

#7 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,956 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Wed Feb 13, 2019 4:34 AM

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:

 

Attached File  ex_sprite_with_collision_prevention_and_pfrowheight7_2019y_02m_13d_0341t.bas   12.24KB   9 downloads

 

Attached File  ex_sprite_with_collision_prevention_and_pfrowheight7_2019y_02m_13d_0341t.bin   4KB   13 downloads

 

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.



#8 EvoMikeUK OFFLINE  

EvoMikeUK

    Star Raider

  • Topic Starter
  • 85 posts

Posted Wed Feb 13, 2019 5:27 AM

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:

 

attachicon.gifex_sprite_with_collision_prevention_and_pfrowheight7_2019y_02m_13d_0341t.bas

 

attachicon.gifex_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!!



#9 EvoMikeUK OFFLINE  

EvoMikeUK

    Star Raider

  • Topic Starter
  • 85 posts

Posted Wed Feb 13, 2019 5:38 AM

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:

 

attachicon.gifex_sprite_with_collision_prevention_and_pfrowheight7_2019y_02m_13d_0341t.bas

 

attachicon.gifex_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



#10 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,956 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Wed Feb 13, 2019 6:29 AM

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.

#11 Karl G ONLINE  

Karl G

    Dragonstomper

  • 792 posts

Posted Wed Feb 13, 2019 6:31 AM

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.

#12 EvoMikeUK OFFLINE  

EvoMikeUK

    Star Raider

  • Topic Starter
  • 85 posts

Posted Wed Feb 13, 2019 6:39 AM

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 :)



#13 EvoMikeUK OFFLINE  

EvoMikeUK

    Star Raider

  • Topic Starter
  • 85 posts

Posted Wed Feb 13, 2019 11:11 AM

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?


#14 Karl G ONLINE  

Karl G

    Dragonstomper

  • 792 posts

Posted Wed Feb 13, 2019 11:42 AM

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.



#15 EvoMikeUK OFFLINE  

EvoMikeUK

    Star Raider

  • Topic Starter
  • 85 posts

Posted Wed Feb 13, 2019 11:49 AM

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



#16 EvoMikeUK OFFLINE  

EvoMikeUK

    Star Raider

  • Topic Starter
  • 85 posts

Posted Wed Feb 13, 2019 11:51 AM

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



#17 Karl G ONLINE  

Karl G

    Dragonstomper

  • 792 posts

Posted Wed Feb 13, 2019 11:56 AM

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.



#18 EvoMikeUK OFFLINE  

EvoMikeUK

    Star Raider

  • Topic Starter
  • 85 posts

Posted Wed Feb 13, 2019 12:01 PM

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.



#19 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,956 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Wed Feb 13, 2019 3:30 PM

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."



#20 EvoMikeUK OFFLINE  

EvoMikeUK

    Star Raider

  • Topic Starter
  • 85 posts

Posted Wed Feb 13, 2019 3:36 PM

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.

#21 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,956 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Wed Feb 13, 2019 8:06 PM

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



#22 EvoMikeUK OFFLINE  

EvoMikeUK

    Star Raider

  • Topic Starter
  • 85 posts

Posted Thu Feb 14, 2019 4:06 AM

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.



#23 Karl G ONLINE  

Karl G

    Dragonstomper

  • 792 posts

Posted Thu Feb 14, 2019 9:21 AM

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


#24 EvoMikeUK OFFLINE  

EvoMikeUK

    Star Raider

  • Topic Starter
  • 85 posts

Posted Thu Feb 14, 2019 12:05 PM

 

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!!



#25 EvoMikeUK OFFLINE  

EvoMikeUK

    Star Raider

  • Topic Starter
  • 85 posts

Posted Thu Feb 14, 2019 12:07 PM

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?






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users