Moving pfpixels

[KevKelley]

I was looking into doing something with pfpixels and was trying to figure out the best way to do it. I got the turning on and off part down And I think I understand that but my idea involved the following:

 

Having a pfpixels behave similar to missile. So let's say in this example the pfpixels is dropped, would you simply plug variables in place for the x and y position (pfpixels a b)  and then have those equal something based on an if/then statement? 

 

My other question would regard cycle counts. I had read that this could be cycle intensive, but does that only refer to the act of turning pfpixels on and off? So once it is drawn it does not use more, making activating them more of a one time cost?

[+TwentySixHundred]

Personally i use variables when wanting a moving pfpixel to behave like a missile. Depends on the application in mind and if it's worth using variables or just pushing values. Im interested as to how others tackle this feature so i will wait till others respond before giving too much advice.

 

As for cost, once the pixel is turned on/off it's a one time deal if your code doesn't need to execute redundant routines. Also from my experience the highest cost is when trying to draw large chunks of playfield using the push method without using data tables. Pushing many pixels manually takes alot of ROM space and chews cycles requiring a drawscreen call often.

 

Having said that making a single mid resolution pixel turn on and remove redundant pixels in it's wake i find not very costly. As long as the pixel placement is updated once every frame.

 

However what works for me may not for others so probably best to wait for others to chime in.

[+Karl G]

1 hour ago, KevKelley said:

My other question would regard cycle counts. I had read that this could be cycle intensive, but does that only refer to the act of turning pfpixels on and off? So once it is drawn it does not use more, making activating them more of a one time cost?

 

That is correct - having pixels stay on doesn't consume any more CPU time than not displaying them.

[KevKelley]

I had two functions I wanted to do. For one, I was using the standard kernel and wanted to have several random pfpixels appear on the screen where you would then move them to another place. 

 

I was thinking of implementing it by having a random number generator to determine how many pfpixels to draw, and then randomly place those pfpixels. 

 

If moving pfpixels were to take too many cycles, I had considered flipping the pfpixel off when collision is detected and then using a missile or ball to move around and then flipping a pixel back on when in the right spot.

[KevKelley]

Thanks (about the cycle question). When reading I was worried that flipping a couple on would not be feasible

[orange808]

You might consider abandoning bB entirely.  Switch to Unocart and use C++.  You can write your own kernel (without worrying about page crossing or branching) and get direct access to the playfield RAM using ARM.

 

Using the 6507 to make calls and manipulate the ARM playfield RAM is painfully slow.  You would rather use the ARM to manipulate RAM directly and race the 6507.

[KevKelley]

I do not know C++. I'm sure I could learn it but I am kind of having fun with bB. Reminds me of when I tried to make games when I was younger so there is a bit of a nostalgia factor involved too...

[+TwentySixHundred]

So i am assuming you're after something like this (excuse the bugs)?

 

You can see in this example the pfpixel moves much like the ball would when bouncing off the player. In this example the player can only push the pixels upwards. It's a rough demo with a bug however shows the concept.

 

move_pfpixels.bin

[KevKelley]

11 hours ago, TwentySixHundred said:

So i am assuming you're after something like this (excuse the bugs)?

 

You can see in this example the pfpixel moves much like the ball would when bouncing off the player. In this example the player can only push the pixels upwards. It's a rough demo with a bug however shows the concept.

 

move_pfpixels.bin 32 kB · 1 download

This is essentially what I was looking for. I was still working out some of the gameplay details but essentially I would need the pfpixels to behave like this.  

[KevKelley]

Here is the basic gameplay of what i was working on.  You walk around. If you collide with and press fire you grab the pallet jack.  I wanted to use pfpixels as boxes that come in through a backdoor that you pick up and put on pallets (missile).  Once pallets are full you move the pallet with the pallet jack to a dock (top of screen).

 

I haven't quite figured out all the details.  I was thinking of having the pfpixels appear on the bottom, maybe use the ball as the pallet, and then once full drop off pallets at the top using NUSIZ copies to fill up the bays (like the top in Frogger)   

CD_03_12_2020.bas

[+TwentySixHundred]

13 hours ago, KevKelley said:

Here is the basic gameplay of what i was working on.  You walk around. If you collide with and press fire you grab the pallet jack.  I wanted to use pfpixels as boxes that come in through a backdoor that you pick up and put on pallets (missile).  Once pallets are full you move the pallet with the pallet jack to a dock (top of screen).

 

I haven't quite figured out all the details.  I was thinking of having the pfpixels appear on the bottom, maybe use the ball as the pallet, and then once full drop off pallets at the top using NUSIZ copies to fill up the bays (like the top in Frogger)   

CD_03_12_2020.bas 3.85 kB · 2 downloads

Ah, i see so for something like that i would go with your first idea of using the ball. Basically i would push values using a global timer to switch on or off pfpixels for the "conveyor"? belt animation. All you would need to do from there is check for collision with playfield in certain locations and switch the pixels on/off and replace some with the ball when selecting the box. Same with when storing the "box" once the box is released within the correct area you can just flip that playfield pixel on again and remove the ball.

 

Reason as to why i would use the ball is for smoother movement because the pfpixels move in a very coarse manner. Especially as the player sprite and pallet jack will both have smooth movements. Secondly ironing out the bugs will be alot easier with the ball. You can basically set the ball to the pallet jack and forget about it. No updates - no bugs - little cost - no drama ?

[KevKelley]

Thanks. I had considered a conveyor belt. I was a bit undecided how I may start things out. This game was an exercise on using pfpixels. I wasn't sure if I would have them slide down the screen and land on the floor. 

 

I think you are right about using the ball. I may rework the playfield since I lost a missile using no_blank_lines.

 

So I guess I can play around with the configuration but I'm thinking use one missile (and copies) for the pallets in the bays up top and another missile as a pallet below. When you "grab" a pfpixel it will flip off and turn into the ball where you can walk it over to the missile and set it down. I'd just have to figure out how to indicate a pallet is full.

[KevKelley]

I made some changes eliminating the no_blank_lines but changing pfheights so that the bottom of the screen will be for the "boxes" and swapping the background and playfield colors.

 

So this is what I worked out so far for what I will work on for gameplay:

 

The bottom right is the conveyor belt. New pfpixels will scroll from the right and then be distributed randomly on the playfield to the left.  The "pallets" come from the top right.  The player can grab the pfpixel boxes (turning them into a ball) and walk them to the pallet.  They can also drag the pallet closer using the jack.  Once the pallets are full (i'm thinking 8 pfpixels) you then bring a pallet to a bay up top. Once all bays are full before the timer runs out you move on to the next wave.

 

The thing I couldn't quite figure out how to get the player position to match the pfpixel position.  I also would want to lock out picking up other pfpixels when you have the ball. I had read the equations online but when I put in into practice it wouldn't quite work. Also moving the pfpixels on the conveyor belt, but I suppose that wouldn't be as hard to figure out.

 

Some of the examples I saw use two temp variables to determine the position.  I was thinking of having the conveyor belt start back up when a couple pfpixels remain. Or possibly assign a bit to each so as each pfpixel is picked up another starts rolling down. I had also considered making a bounding box on the bottom left so that the player doesn't inadvertently erase the rest of the playfield. These are all things I was trying to figure out but overall I kind of like the direction this took. 

 

I was also trying to figure out why the missile0 is just a line.  When I looked at the kernel combos, I did not see my combo having any exclusions but I also wouldn't know what to use the missile for, except maybe a bonus box every once and a while.

CD_03_13_2020.bas

[+TwentySixHundred]

Nice work mate, yeah obviously it will take alot of tweaking to get things right. It's just a matter of experimenting and learning as you go to find what works for you. Many ways alot of this can be done and i do think you have the right idea with using the ball as a 'box'. You want that 'box' (ball) to have smooth movement like the other sprites as it's the one being moved. After all, games are just an illusion and all that matters is what the player see's on screen. Good thing about the ball is it's the same colour as the playfield so the player thinks it's actually a pfpixel however you will have smooth movement.

 

As for finding the right placement for player vs pfpixels and what pixels can be used/taken. All you really need to do is add coordinates conditions to the collision statement/s. If that condition is not met then the rest of the code isn't executed thus making only certain pfpixel locations having the ability to flip the pixel and replace with the ball. This will also help making the player get the correct alignment in order to pick up the 'box' (we all know you can't pick up a pallet with one tine ;).

[KevKelley]

I was thinking of using a bit to check if you are carrying a box. If you are then it will skip the collision check. If it works the way it does in my head then I wouldn't have to make a bunch of conditional statements - I would just have the one.  I would imagine that could make thinks simpler... If it works.

[KevKelley]

So I got the generation of the pfpixels working (I hadn't made the animation of them moving down the conveyor belt but they do generate).

 

I also got the swap kind of working but it is very inconsistent.  Sometimes a pfpixel swaps smoothly, sometimes the ball appears but the pfpixel stays, and sometimes it stays and no ball swaps.  

 

I can't quite figure it out.

 

This code is what I had worked out so far:

   if Bitop_Joy_Direction{0} then temp3=((player1x - 16) / 4) :temp4=(player1y - 8) / 8
   if Bitop_Joy_Direction{1} then temp3=((player1x - 16) / 4) :temp4=(player1y - 8) / 8
   if Bitop_Joy_Direction{2} then temp3=((player1x - 16) / 4) :temp4=((player1y - 8) / 8) 
   if Bitop_Joy_Direction{3} then temp3=((player1x - 16) / 4) :temp4=((player1y - 8 ) / 8)

 if d{0} then ballx=player1x+6:bally=player1y-5:goto SKIP_BALL_SWAP
 if !d{0} then bally=200
 
BALL_SWAP

 if collision(player1,playfield) && player1x>22 && player1x<100 && player1y>50 && player1y<75  then pfpixel temp3 temp4 off: d{0}=1
 if d{0} then ballx=player1x+6:bally=player1y-5

SKIP_BALL_SWAP

 rem box hit pallet
 
 if collision(ball,missile1) then d{0}=0: missile1height=missile1height+1
 if missile1height>10 then missile1height=10

 

Are there any pointers for what I am overlooking?  I feel like I am on the right path being that the interactions I want occur some of the time but I cannot figure it out for the life of me!

CD_03_14_2020.bas

[+TwentySixHundred]

From having a quick look i see you're using player0 for the pallet jack.

 

I threw this line of code in:

if collision(player0,playfield) then temp3 = (player0x - 16) / 4 : temp4 = (player0y/8) - 1 : pfpixel temp3 temp4 off

 

Commented out this:

if collision(player1,playfield) && player1x>22 && player1x<100 && player1y>50 && player1y<75  then pfpixel temp3

 

And it removes the pfpixels without a worry, only problems is one it would need some tweaks and further checks to iron out the bugs. Obviously the ball didn't appear as i had removed that d{0} bit and you would need to shuffle some code around. Anyway i hope this steers you in the right direction.

 

I used player0 collision detection because it's easier to determine when and where the pixel should be turned off in accordance to the pallet jack. Basically i would go on to make the program skip this condition if the ball is greater then 200 or whatever ?

 

I used a very similar method to this for the destruction of the city buildings in City Defence

[+Gemintronic]

SeaGtGruff came up with a library to move playfield pixels around.   Download is in this topic:

 

[KevKelley]

7 hours ago, TwentySixHundred said:

 

Thanks. I will have to check this out on my break to see how it works. Just reading it on my phone I'm having a hard time picturing how it operates differently than what I have. It started to drive me crazy because I would tweak the code every which way and try to pay attention to difference in interactions. On the plus side I was able to clean up the code from what I originally had. 

[KevKelley]

7 hours ago, Gemintronic said:

SeaGtGruff came up with a library to move playfield pixels around.   Download is in this topic:

 

Thanks! I wouldn't have thought to look in that thread. I was mostly looking at the pfpixel to sprite thread, which I think gave me a decent idea of what needs to be done. It is just taking me some time to practice how to code it. I had also been looking at the pfpixel destruction sample program from RT's page as a reference, but I found when I used !pfread as a check I had a lot of unintended actions.