KevKelley

Nevermind! I just realized my mistake! I just reread the RT's site one last time and saw that if I change it to "inline" instead of "includes" and move it to the last bank it should be fine... and it was!

I noticed I was running low on space so I decided to switch to 8k with a standard kernel. At first it crashed but then i read about the order of which include and includesfile should be before the set rom size. So I went through and noticed I had two includes: include div_mul.asm and include 6lives_statusbar.asm. I first moved the div_mul and everything seemed to work but then I noticed I did not have the lives and status bar so I moved that before the set rom size and the screen went crazy. I tried moving it around in all sorts of different spots to see if it would work but nothing... So my question is when using includes and bankswitching, is there a limit or accepted combinations of includes (like the kernel options)? I was curious if I was missing something. Here is the .bas file (with the include 6lives_statusbar.asm in its original spot): CD_03_31_2020_3.bas

Wow. I will have to check this out. Today was my day off so I was gonna take a good hard look at it. The pillars at the top are actually the truck bays so my plan was that one to use pfhline across each space once a full pallet (missile1) crosses over it.

I still cannot thank you enough with that code. I can see what you mean by me requiring a lot more checks than my single check I had started with. I had thought that since collision with the pfpixels was only needed on the bottom of the screen I could make a bounding box and when in that box I would have collision detection, otherwise collision detection would be turned off so that you would not inadvertently remove the playfield. The sticky collision only resulted when I moved the drawscreen, otherwise it seemed to work as intended. I am still trying to wrap my head it, as the checks are more complex than anything I had done before and it is taking me a bit to follow the code to see how each line affects the interactions on screen. I think i get the principles behind it all but I had a question: I notice the movement of the player0 sprite stops halfway up. If I were to have it continue moving up, would I have to perform more checks because the pfheights are different? Would it still be possible to use a method similar to the one I initially used since the only real interactions occur on the bottom, only getting conversions for the when the player is on the bottom of the screen near the generating pfpixels? I was looking at the checks for each direction like this: up if !joy0up then goto movedone temp3 = (player0x - 17) / 4 ;player xPos temp6 = (player0x - 10) / 4 ;xPos +7, rightmost pixel of sprite temp4 = ((player0y - 9) - hmm2) / hmm ;yPos above player, using 8 looks wrong since the player can only be placed every 2nd scanline if temp6 > 19 then temp1=100 else temp1=3 ;after that xpos, the floor is the 8th pfrow, else it's 10 if temp4 > temp1 && temp4 < 10 then goto _box4 _playfield4 if pfread(temp3, temp4) then player0y = (temp4 * hmm) + 16 + hmm2 - 4 : goto movedone temp3=temp3+1 if pfread(temp3, temp4) then player0y = (temp4 * hmm) + 16 + hmm2 - 4 : goto movedone if pfread(temp6, temp4) then player0y = (temp4 * hmm) + 16 + hmm2 - 4 : goto movedone goto _skip_box4 _box4 if d{0} then _playfield4 if pfread(temp3, temp4) then pfpixel temp3 temp4 off : d{0}=1 : goto movedone temp3=temp3+1 if pfread(temp3, temp4) then pfpixel temp3 temp4 off : d{0}=1 : goto movedone if pfread(temp6, temp4) then pfpixel temp6 temp4 off : d{0}=1 : goto movedone _skip_box4 if _player0y - speed > 50 then _player0y = _player0y - speed else _player0y = 50

That probably would have taken me a lot longer to figure out. The code you posted before is very interesting to look at and I was checking it out on my lunch. Thank you for your explanation. I was a little fuzzy after reading the forums and programs, as I knew there was conversion that needed to happen but didn't realize the other checks that would be needed to make it run smoothly.

Ah! I didn't think about the difference of pixel heights! I guess that would explain why seemingly random pixels would turn off? So if I understand this, the conversion for the y coordinate (y-8-34) is to account for all the odd shaped pixels while the last part is for the pfpixels with a height of four? Thanks!

I had moved the drawscreen in a different spot to check on if that was the reason but it didn't work and came with its own problems, namely the player1 sticking to the playfield. I had never really used that method of movement before so I had considered changing that whole segment (I had copied that from an example program and thought it seemed straightforward and simple. I had considered that might be an issue though. I had thought that the collision check in the movement was interfering with the collision of the playfield blocks which is why I tried to make a bounding box for the affected pfpixels. I may not have implemented it correctly though but I'll go through it later today and check. Thanks for the tips.

I had originally mentioned this issue in the Moving pfpixels thread but since that post was focused more on moving the pfpixels and this issue dealt more with the collision detection of them, I made this separate post. I seem to be at an impasse with trying to figure out how to get these pfpixels to dissappear! I followed the forums and code examples from RT's site and for the most part I got the code to work... except when it wouldn't. As I posted in the other thread, the goal was to hit a pfpixel, turn it off, and immediately replace it with a ball so that the player1 can move around with the ball giving it a smoother movement. When the ball hits the missile1 it disappears and player1 must go grab another pfpixel. The only pfpixels that would be allowed to be affected are the smaller ones on the bottom left half of the screen (I use pfheights). The issue I seem to be experiencing is that they would inconsistently disappear. Sometimes a ball would appear. Sometimes it wouldn't. Sometimes the pfpixel would disappear. I rewrote the code in various ways to see if I can tweak it to get it to work. Some iterations would work better than others. Sometimes things would go haywire and random playfield pixels would dissappear. I thought maybe it was an issue with where the collision detection appeared in the code so moved it around a bit or that I was using temp variables so I changed that too but to no avail. I tried the suggestions mentioned but can't seem to wrap my head around this. Was curious if anyone had any ideas where I went wrong with this issue! Here are a couple of the files I had worked with to see if I could get different results. CD_03_18_2020.bas CD_03_15_2020.bas

I plan on working on my games. I hope to practice some batari Basic and learn some things.

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.

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.

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

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.

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

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.

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

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.

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

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

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.

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?

Makes you really appreciate how much these programmers crammed with such little space.

Thanks! I was hoping on working on it last week on vacation but my kid was sick. Hoping to make some progress real soon on both BB and MM. Glad to see the positive responses. I tend to have a bit of self doubt due to my lack of experience.

Some of the details were a result of playing around to see what worked and how I can use the code elsewhere. The grass came from me working on collisions with copies of sprites. I wanted to use this with the car collisions in BB but in this game, I found you could just sweep the bottom for points. I eliminated the copies and instead made it grow in random locations to give time in between scoring. The alligator attack resulted from them closing in on the manatee. I felt that it got to the point where the manatee would kind of get cornered. I also wanted to limit flicker so I try to keep the two sprites separated as long as possible but I figured if the alligator quickly took out the diver and reset their positions it would help balance gameplay and flicker. The head popping out of the water is one of my favorites. I needed a way to clearly defined how the manatee gets oxygen. I didn't want someone to just go above the y coordinates and quickly replenish their health, especially if they must dodge boats and swimmers. I have it where you have to keep hitting the fire button to swim above that point so you have to plan your surfacing. I also liked going behind the playfield to add dimension with the playfield grass at the bottom. But because I use the playfield, this is why the manatees movement is limited to the center of the screen. One other small detail I added were fireflies at night. I was trying to play around with sprites having gradual color changes when I thought to use fireflies at the top but when considering the size of the Sprite being a single pixel and the duration it is on the screen I thought having it fade in and out wasn't necessary.

I got all the pieces in play. I just gotta figure out how they work but I have an idea: In the morning you have the gator and the swimmer. They both move in your direction but I'm thinking the gator may "bite" you while the swimmer will try to "grab" you causing you to break free. In the early afternoon you have the tubes drifting back and forth obstructing the top while red tide bounces back and forth below. If you touch it in thinking it would reduce oxygen levels. In the late afternoon you would still have red tide but now a speedboat. While it obstructs the surface in a different movement, the propeller can injure the manatee. In the evening I have the fisherman. He will move around and drop his line. Currently, if you touch his fishing line you get stuck and have to drop down to get free. At night you have jellyfish that will have more erratic swimming patterns to dodge. All this occurs while you go back and forth from eating and surfacing. I am trying to figure out how the good diver works. Im thinking he comes by at random and drops benefits, like bonuses or health benefits. Once a day is complete it starts back over. Then I may increase difficulty by increasing speed or increase the copies of the sprites like the tubes or the jellyfish or red tide. I haven't gotten that far...