Jump to content
IGNORED

Collision detection with a scrolling playfield


atari2600land

Recommended Posts

This is driving me crazy. I have this code that works fine when it's not scrolling, but when it is scrolling, the guy can move through the playfield (he's not supposed to.) I spent hours and hours trying to get it to work but to no avail. The area I'm working on starts at line 444 and goes to the end. Variable p controls the timer for the scrolling and variable q controls when to move the bar up.

 

wwm15.bas

Link to comment
Share on other sites

I'll try to look at it tonight if nobody else does. My sister had to take her father to the emergency room last night and I'll have to help her with random things tonight so she can go back to the hospital. I'll probably be free to look at the program in around 3 to 4 hours.

Link to comment
Share on other sites

I'm looking at the code now. I see that you're using some low temp variables. If scrolling uses them, they could be getting corrupted. Do you think that might have anything to do with it? I'll keep looking in case that's not the problem.

Link to comment
Share on other sites

Right now I know what f, k, p, q are for. Can you post the rest of the variables you use in alphabetical order and say what they do?

 

Example:

 

a = Counter for cat juggler animation.

b = Remembers how many monkeys were eaten by rabid goat.

c = Counter for alien tickle fight IN SPACE.

Link to comment
Share on other sites

That's a little better, but when the guy is below the bar and near it, it acts weird and jerky.

 

s - bar height

m - bar space middle (used to determine how big the bar space is)

n - bar space ending

o - lives counter

x & y, l{0} - collision detection

v - REFP0

a-d, h, i - canoe paddling guy animation

Edited by atari2600land
  • Like 1
Link to comment
Share on other sites

That's a little better, but when the guy is below the bar and near it, it acts weird and jerky.

 

s - bar height

m - bar space middle (used to determine how big the bar space is)

n - bar space ending

o - lives counter

x & y, l{0} - collision detection

v - REFP0

a-d, h, i - canoe paddling guy animation

Maybe I can slap in a check of playfieldpos or something. I have to go eat, but then I'll come back and see what I can do.

Link to comment
Share on other sites

The collision prevention that keeps the canoe from sticking on top of the bar was seeing the bottom of the bar as though it was lower because it was, it just hadn't scrolled out of the row area yet. Once the last bit of the bar scrolls out of the way, too much time has gone by, so it looks like the sprite is hitting against nothing. After yanking out some code and putting a little in, it seems to be working better than the previous versions:

 

wwm15_2019y_02m_16d_0551t.bin

Link to comment
Share on other sites

The variable x is free to use now. The variable y was free until I used bit 7 of it. You can move that bit to r (since you are only using bit 0 and bit 1, but you won't be able to use r = 0 like you have in the program. Once you move bit 7 of y to r, the variable y will be free to use.

 

Seems like you have a lot of redundant collision checks. You might be able to combine some of them and save cycles. I started making variable aliases so I could tell exactly what is going on, but I didn't have all of the variable information, so it's unfinished.

 

wwm15_2019y_02m_16d_1602t.bin

 

wwm15_2019y_02m_16d_1602t.bas

Link to comment
Share on other sites

If the canoe hits the playfield in the gap, then the canoe goes up. Is there a way to stop this?

 

I tried a few things, but it made other things worse. As it is now, players can press diagonally down (left or right) and the canoe won't stick to the bar as they make their way to the opening. If players want to go under the bar and rub their heads against it for some some strange reason, they can do that too. If players shove against the sides of the gap, there is a chance that they will get sucked up into the eddy behind the bar. Sounds like a feature, not a bug. Instead of trying to fix it, you might want to embrace it.

Link to comment
Share on other sites

I worked on this for a few more hours. As a result, things look drastically different. Why? Because of the playfield. I wanted it to give me a different hole, but the bottom kept showing up in a height of 1 pixel before reverting to the correct hole placement. So I decided to make the pfcolor be blue to hide this fact. That made the ends flicker, so I decided to use missile 1 for the boundary ends. Which meant that the guy no longer was in a boat because if I used the ball for a boat, it would flicker too.

 

So this is a level where the guy fell out of the kayak and the tide is sweeping him away. Which is fine because it looked silly with him paddling while the tide is sweeping him away.

And a few times I kept getting this weird bug where part of the screen was green. Don't know why. And since the pfblocks were scrolling, that meant that the title screen's pfpixel's y locations were all screwed up when the guy died. I fixed this as well.

wwm16.bin

  • Like 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...