Turning Off 3 vertical pixels

[KevKelley]

So I am a bit stumped on this one. I was going to use the playfield pixels as an element in a game. I would draw 3 pixels, one on top of the other. That seems easy enough.

 

But what was stumping me was the best or most efficient way to remove the three vertical pixels. My thoughts are have one spot that will be read (like a part of the player0 sprite) and then turn off 3 in both up or down direction to cover all possible spots but didn’t know if there was a better way. 

Edited August 7 by KevKelley

[+Random Terrain]

I might be misunderstanding, but if you are talking about three vertical pixels that will move with joystick position, seems like you wouldn't have to read anything. If the player moves right, you delete the three pixels and move them one space to the right. If the player moves up, only one pixel will have to be moved up and one pixel removed at the bottom. You'd just do a similar thing for all valid moves.

 

But like I said, I'm probably misunderstanding.

[KevKelley]

Sorry if I described the situation poorly. 
 

Here is a link to a video to better explain. 
 

The white square is 3 pfpixels high. I am aiming to have all 3 disappear should the Goose walk over them, regardless of which pfpixel the Goose touches. 

 

My thought would if I read one pixel, I will just automatically read 2 above and 2 below and turn them off but I did not know if there was a better solution. 

[+Random Terrain]

If you have the spare variables, you could store where the pixels are, then delete them when touched without needing to do any fancy calculations.

[KevKelley]

4 hours ago, Random Terrain said:

If you have the spare variables, you could store where the pixels are, then delete them when touched without needing to do any fancy calculations.

I thought about that. I am using DPC+… but I also plan on having multiple blocks throughout the screen… like maybe 10.

 

 

[+Random Terrain]

3 hours ago, KevKelley said:

I thought about that. I am using DPC+… but I also plan on having multiple blocks throughout the screen… like maybe 10.

 

 

 

That would be too many variables even if you just remembered the top pixel. Since you'll have to go at it another way, you'll need to make sure that the sets are far enough apart so the sprite can't touch two sets at the same time.

[KevKelley]

1 hour ago, Random Terrain said:

 

That would be too many variables even if you just remembered the top pixel. Since you'll have to go at it another way, you'll need to make sure that the sets are far enough apart so the sprite can't touch two sets at the same time.

So far I am working with having each horizontal plane separated by two playfield pixels. 
 

I may just have to perform these checks as I plan on having them randomly spawn. That would be a lot to track. 

[KevKelley]

I had made a data table for spawning for the y-coordinates. I could possibly make one for the removal. That could make things a little easier. 

[+Karl G]

I'm wondering if a pfvline would be better cycle-wise than 5 pfpixel statements. 

 

Also, is this an untitled goose game? 

[KevKelley]

3 hours ago, Karl G said:

I'm wondering if a pfvline would be better cycle-wise than 5 pfpixel statements. 

 

Also, is this an untitled goose game? 

I forgot about pfvline. I forgot it was a thing! I always remember pvhline but I had always thought best to avoid them because they use a lot. The only problem I see with using it for removal is I would still have to determine which of the 3 pixels contact is made with to figure out which are removed.

 

As for the untitled aspect, my little one is obsessed with that game and wants me to make this a sequel. While I also love that game, this is really inspired by a real life duck and goose. 😂 

[+Karl G]

13 minutes ago, KevKelley said:

The only problem I see with using it for removal is I would still have to determine which of the 3 pixels contact is made with to figure out which are removed.

Right. Since I didn't have a good suggestion for that, I figured instead of removing the two above and below like you were talking about, you could do a line of 5 to accomplish the same thing, but possibly more efficiently (though I'd have to test and see if it really was more efficient).

[KevKelley]

46 minutes ago, Karl G said:

Right. Since I didn't have a good suggestion for that, I figured instead of removing the two above and below like you were talking about, you could do a line of 5 to accomplish the same thing, but possibly more efficiently (though I'd have to test and see if it really was more efficient).

I think I have a total of 5 rows of 3 pixels, so 25 total y-coordinates. I had thought I could make a data table that would sort it out. I had considered that might take up less space then making several lines checking what line and then removing x amount of pixels up and down. 

[KevKelley]

So my solution was when the player position is converted to playfield coordinates that number is used with a data table to make a vertical range to use with a pfvline statement. 
 

So if you happen to be on playfield y position of a 20 through 25 it would read as 20 and remove all the pixels without multiple pfpixel statements. I also thought using a data table was good in creating a kind of hit box.

 

Here is a video of the result.