Multisprite Superchip pfread- Sprite Coordinates

[KevKelley]

I am getting stumped on the exact equation to use for coming up with a collision detection using pfread.  

 

I am using Superchip and the Multisprite kernel with the following settings with the playfield being 40 rows:

const screenheight=88
const pfres=32
pfheight=1

I was also curious if I comment out the screenheight constant I get a little graphical glitch on the top that seems to take some of the playfield data from somewhere else but it also looked pretty neat, as it kind of fit in with what I was trying to make so I was curious how much the pfread would differ should I use that because just looking at the two screens side by side it looks like I am getting more on the screen. Obviously I would have to change the coordinates for all the sprites if I play around with that. Or should I not do that because it can cause more issues than what it is worth?

 

I was just trying to squeeze out as much into the playfield as I could for a simple idea which is what had me playing around with the playfield resolution.

 

Top with ";const screenheight=88" and bottom with "const screenheght=88".

 

 

PIZZBOY_2022_01_23.bas

Edited January 23, 2022 by KevKelley

[KevKelley]

I guess preferably I'd prefer to use the one with the larger playfield, with the two little buildings on top. 

 

I will play around with this later. I was working on the collision through trial and error earlier trying to get the best fit. Ideally I want to make it where the player sprite bottom limit on each row would be the buildings but would overlap the doorway by a couple pixels, since the ball is the pizza box and I use it's collision with the missile to determine if the pizza was delivered.

[+Dave C]

If I read this right - your idea is to make the player be blocked by buildings - but not all the time?

We are having a lot of the same ideas for the kid_snz delivery concept... 
 
In my latest I tried to play with this by using playfield collision but immediately skipping if it takes place in certain horizontal bands  (which I figured out by guesstimate / trial and error). This takes advantage of the playfield design having the streets run horizontally.

It feels odd turning around corners though, it's very easy to get stuck on corners - and if the numbers are off you get some side weird effects.
 

   if !collision(playfield, player0) then goto __Skip_PF_Collision 
   
   ; skip collision if it takes place in these horizontal bands
   if player0y < STREET_FRONT_0_Y_MAX && player0y >= STREET_FRONT_0_Y_MIN then goto __Skip_PF_Collision
   if player0y < STREET_FRONT_1_Y_MAX && player0y >= STREET_FRONT_1_Y_MIN then goto __Skip_PF_Collision
   if player0y < STREET_FRONT_2_Y_MAX && player0y >= STREET_FRONT_2_Y_MIN then goto __Skip_PF_Collision

I really like the way delivery works in your demo. And your title screen - I borrowed the idea of your title screen but mine is pretty weird looking r/n.

 

Edited January 24, 2022 by Dave C

[KevKelley]

4 hours ago, Dave C said:

If I read this right - your idea is to make the player be blocked by buildings - but not all the time?

We are having a lot of the same ideas for the kid_snz delivery concept... 
 
In my latest I tried to play with this by using playfield collision but immediately skipping if it takes place in certain horizontal bands  (which I figured out by guesstimate / trial and error). This takes advantage of the playfield design having the streets run horizontally.

It feels odd turning around corners though, it's very easy to get stuck on corners - and if the numbers are off you get some side weird effects.
 

   if !collision(playfield, player0) then goto __Skip_PF_Collision 
   
   ; skip collision if it takes place in these horizontal bands
   if player0y < STREET_FRONT_0_Y_MAX && player0y >= STREET_FRONT_0_Y_MIN then goto __Skip_PF_Collision
   if player0y < STREET_FRONT_1_Y_MAX && player0y >= STREET_FRONT_1_Y_MIN then goto __Skip_PF_Collision
   if player0y < STREET_FRONT_2_Y_MAX && player0y >= STREET_FRONT_2_Y_MIN then goto __Skip_PF_Collision

I really like the way delivery works in your demo. And your title screen - I borrowed the idea of your title screen but mine is pretty weird looking r/n.

 

I was originally going to do a collision detection for just the buildings doing something similar with what you did but I kept screwing something up so decided to do pfread instead but I couldn't quite figure it out because of the different pfres and playfield... But that is what got me thinking about changing values. 

 

When I eliminated the screen height constant it looks as if the status bar and playfield drop and I get those two extra buildings up top. If I can make it work that would be cool because it seems to increase the playable field just a bit and I thought the graphics up top work for this. I just want to figure out if the screen height thing messes up anything and how I can change the graphical glitch up top. It looks like part of the title screen.

[KevKelley]

So after playing around with removing the constant, I saw that it essentially adds 4 rows to the playfield but if I don't define those four rows in my playfield statement it just makes up the data from somewhere.  This is really nice because it adds just a little bit more to the playfield to play around with.

 

So now I edited the playfield to accommodate those extra rows, making the playfield 44 rows high and 32 across (mirrored, of course).

 

Now I just have to wake up my brain and do some math to figure out how to turn player coordinates into ones for pfread.

[+Karl G]

18 minutes ago, KevKelley said:

Now I just have to wake up my brain and do some math to figure out how to turn player coordinates into ones for pfread.

Well, you will probably want to use the pfread_msk.asm module so that the pfread y axis will be reversed to match the reversed y axis of the player sprites in the Multisprite kernel.

 

Why do you want to use pfread, though? If you just want to know what house you are at then there are probably cleaner ways to do that.

[KevKelley]

31 minutes ago, Karl G said:

Well, you will probably want to use the pfread_msk.asm module so that the pfread y axis will be reversed to match the reversed y axis of the player sprites in the Multisprite kernel.

 

Why do you want to use pfread, though? If you just want to know what house you are at then there are probably cleaner ways to do that.

I was trying to use it for a collision detection. I think I overlooked the sprite y axis being reversed.

 

I also noticed that each pfpixels is 2 pixels high.

[KevKelley]

I already have the multisprites pfread assembly in the code.

[KevKelley]

In the code, I check for which house by using the missile for indicating destination and then collision between the ball and the missile but I want to use pfread for collision detection for the players and the houses. So you can only stay on the street (I was trying to have only a slight overlap of the sprite and playfield when moving up so that the ball can touch the missile). 

 

I figured this method would be easier then defining the area of the streets and making hit boxes for each building or checking for collision with the playfield when outside of the safe zones... But seeing how Dave C did it, I do like how that method worked but I wanted to try and figure out this way as well. 

Edited January 25, 2022 by KevKelley

[+Gemintronic]

I would love to see the pfread extension for multisprite working.  Bogax did some fine work but I never personally got it to go.

 

My work around was to use a missile hidden inside the matching player for playfield/player collision.  Being in the middle of the player sprite hid the rebound when you reverted the position due to playfield collision. 

[KevKelley]

1 hour ago, Gemintronic said:

I would love to see the pfread extension for multisprite working.  Bogax did some fine work but I never personally got it to go.

 

My work around was to use a missile hidden inside the matching player for playfield/player collision.  Being in the middle of the player sprite hid the rebound when you reverted the position due to playfield collision. 

I thought about that since I have one missile and it is limited to a single pixel but for now I went with a variation of Dave C's method. When ever I thought I had the pfread conversion right it just always seemed off.

[KevKelley]

On 1/24/2022 at 12:09 PM, Dave C said:

If I read this right - your idea is to make the player be blocked by buildings - but not all the time?

We are having a lot of the same ideas for the kid_snz delivery concept... 
 
In my latest I tried to play with this by using playfield collision but immediately skipping if it takes place in certain horizontal bands  (which I figured out by guesstimate / trial and error). This takes advantage of the playfield design having the streets run horizontally.

It feels odd turning around corners though, it's very easy to get stuck on corners - and if the numbers are off you get some side weird effects.
 

   if !collision(playfield, player0) then goto __Skip_PF_Collision 
   
   ; skip collision if it takes place in these horizontal bands
   if player0y < STREET_FRONT_0_Y_MAX && player0y >= STREET_FRONT_0_Y_MIN then goto __Skip_PF_Collision
   if player0y < STREET_FRONT_1_Y_MAX && player0y >= STREET_FRONT_1_Y_MIN then goto __Skip_PF_Collision
   if player0y < STREET_FRONT_2_Y_MAX && player0y >= STREET_FRONT_2_Y_MIN then goto __Skip_PF_Collision

I really like the way delivery works in your demo. And your title screen - I borrowed the idea of your title screen but mine is pretty weird looking r/n.

 

I implemented something like what you suggested.  I had a bit of hassle trying to make pfread work but I played around with your code.  I looked at your .bas file and I was impressed.  Very neat and orderly, unlike my sloppy code.  

 

I wound up popping in this simple code in:

  if !collision(playfield, player0) then goto __Skip_PF_Collision 
   
   ; skip collision if it takes place in these horizontal bands
   if player0y < 31 && player0y >= 23 then goto __Skip_PF_Collision
   if player0y < 51 && player0y >= 38 then goto __Skip_PF_Collision
   if player0y < 71 && player0y >= 63 then goto __Skip_PF_Collision
   if player0y < 90 && player0y >= 80 then goto __Skip_PF_Collision
   if player0y<12 && player0x>93 && player0x<65 then goto __Skip_PF_Collision

 if joy0down then player0y=player0y+2:goto SLR
 if joy0up then player0y=player0y-2:goto SLR
 if joy0right then player0x=player0x-3
 if joy0left then player0x=player0x+3
SLR
__Skip_PF_Collision

I cannot remember what else you had done in your code but I added the skip the left and right check after if pressing up or down because I kept getting some gliding action if the joystick combo and coordinates hit just right.  I also changed my old code up a bit to tie the REFP0 to a bit so that the sprite stays in the last pushed direction.  I didn't think much about doing this at first but since the sprite is not even in all locations, I found that it could sometimes transport through walls.  I haven't gotten stuck on anything yet but on occasion if you are near a corner you may whip around the corner but that is the extent of it.  I only applied this to the bike ride code and not the walking code so far.

 

I figured I'd move on from this for now since I have the same desired effect. 

 

PIZZBOY_2022_01_26.bas.bin

[KevKelley]

The only issue I have been having is coming up with a good check for the bottom around the pizza place. For the most part thinks work pretty good for what it is. 

[+Dave C]

7 hours ago, KevKelley said:

Very neat and orderly

Thanks, it's partly OCD but also in actuality if I didn't name everything I would lose track of what I was doing - especially keeping track of the numbers. 

I always like to remember / be reminded - the computer does not care if code is good or bad it flows either way.

Edited January 26, 2022 by Dave C

[Erik Zimmermann]

Hi KevKelly! The PizzaBoy are very nice. Now also use multisprite. PizzaBoy helped me a lot.