+atari2600land Posted February 14, 2019 Share Posted February 14, 2019 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 15, 2019 Share Posted February 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 15, 2019 Share Posted February 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 15, 2019 Share Posted February 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 15, 2019 Share Posted February 15, 2019 See if this is acting the way you want it to: wwm15_2019y_02m_15d_0557t.bin Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted February 15, 2019 Author Share Posted February 15, 2019 (edited) 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 February 15, 2019 by atari2600land 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 15, 2019 Share Posted February 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 15, 2019 Share Posted February 15, 2019 See if this is better: wwm15_2019y_02m_15d_0953t.bin Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted February 15, 2019 Author Share Posted February 15, 2019 That's better, but when the guy is below the bar and moves horizontally closer to the hole, he stops until the bar is farther away. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 15, 2019 Share Posted February 15, 2019 That's better, but when the guy is below the bar and moves horizontally closer to the hole, he stops until the bar is farther away. I'll play with the code some more and see if there's anything I can do. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 16, 2019 Share Posted February 16, 2019 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 Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted February 16, 2019 Author Share Posted February 16, 2019 If you get up near the top and hold up, the guy goes through the bar. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 16, 2019 Share Posted February 16, 2019 If you get up near the top and hold up, the guy goes through the bar. Thanks. That shouldn't be a difficult fix. Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted February 16, 2019 Author Share Posted February 16, 2019 I think I did it myself. Let me know if any bugs pop up. wwm15a.zip Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 16, 2019 Share Posted February 16, 2019 I think I did it myself. Let me know if any bugs pop up. The problem with that one is that the guy sticks to the bar as if it's covered with glue, broken glass, and rusty nails. I'll adjust the one I was working on and post it. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 16, 2019 Share Posted February 16, 2019 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 Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted February 17, 2019 Author Share Posted February 17, 2019 If the canoe hits the playfield in the gap, then the canoe goes up. Is there a way to stop this? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 17, 2019 Share Posted February 17, 2019 If the canoe hits the playfield in the gap, then the canoe goes up. Is there a way to stop this? Probably. The scrolling changes everything so putting out one fire causes three more. I can see what I can do in 3 or 4 hours. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted February 17, 2019 Share Posted February 17, 2019 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. Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted February 17, 2019 Author Share Posted February 17, 2019 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 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.