EvoMikeUK Posted February 12, 2019 Share Posted February 12, 2019 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? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 12, 2019 Share Posted February 12, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 12, 2019 Author Share Posted February 12, 2019 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 Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 12, 2019 Author Share Posted February 12, 2019 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? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 12, 2019 Share Posted February 12, 2019 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. Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 12, 2019 Author Share Posted February 12, 2019 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 13, 2019 Share Posted February 13, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 13, 2019 Author Share Posted February 13, 2019 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!! Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 13, 2019 Author Share Posted February 13, 2019 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 13, 2019 Share Posted February 13, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
+Karl G Posted February 13, 2019 Share Posted February 13, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 13, 2019 Author Share Posted February 13, 2019 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 Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 13, 2019 Author Share Posted February 13, 2019 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? Quote Link to comment Share on other sites More sharing options...
+Karl G Posted February 13, 2019 Share Posted February 13, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 13, 2019 Author Share Posted February 13, 2019 That mangles the screen when I do that, but it does compile and run. Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 13, 2019 Author Share Posted February 13, 2019 It only mangles when it calls the /7 line, runs fine until it hits that line. Quote Link to comment Share on other sites More sharing options...
+Karl G Posted February 13, 2019 Share Posted February 13, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 13, 2019 Author Share Posted February 13, 2019 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 13, 2019 Share Posted February 13, 2019 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." 2 Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 13, 2019 Author Share Posted February 13, 2019 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 14, 2019 Share Posted February 14, 2019 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 3 Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 14, 2019 Author Share Posted February 14, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
+Karl G Posted February 14, 2019 Share Posted February 14, 2019 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 1 Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 14, 2019 Author Share Posted February 14, 2019 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!! Quote Link to comment Share on other sites More sharing options...
EvoMikeUK Posted February 14, 2019 Author Share Posted February 14, 2019 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? 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.