DaveM

Thanks! Yeah, it's been a rough time, and I just didn't want to talk about it here. Every day for the past year and a half, anyone who's in my relative vicinity would always ask, "How's she doing? And how are YOU doing?" and that just gets old real quick. Since no one knows me here, this board turned into a real good place to not talk about it. Definitely! There's very, very few things left on my to-do list with this game. I'm dangerously close to having the 1 player game done, so I should be adding menu and 2 player options very soon! Oh, crap! I better release an update then! New in this update: Starting with Level 7, all enemies move vertically, not just the Purple Flappers. That said, I've never been able to make it to Level 7. But this will come into play more once I add the Level Select feature. The progress bar now tracks the number of targets shot during the Bonus Cave. The green marker will move a space to the right with each target shot, and will start flashing after 9 have been shot. When you shoot your 10th target, the bonus gem will appear, and the progress marker will move a space to the right again and continue flashing. If you ignore the gem and continue to shoot targets, the progress marker will not move any further to the right (but you still score 500 points each, so if you have lots of time remaining, rack up those points!) Picking up the gem and returning it to the top of the cave will cause the marker to move all the way to the right, completing the bonus cave. Previously, the marker sat on the left side of the progress bar until you rescued the gem, then it moved all the way to the right, with no way to tell how many targets you had left to shoot. I've re-written most of my enemy movement routine. You won't notice the difference playing the game, but the routine is much more efficient, and I freed up a lot of space. Numerous little bug fixes. Not sure I'll be able to catch ZPH live tomorrow night, but I'll do my best! At the very least, I'll definitely watch the archived show the next day! Thanks so much for featuring the game! Mr_Yo-Yo_B20210301.bin Mr_Yo-Yo_B20210301.a

New in this update: Snippers will now speed up if you shoot 2 of them in a round. Shooting a 3rd still triggers the bonus where the Snippers will no longer spawn and are replaced by coins. Reduced the number of targets you have to shoot in the Bonus Cave from 15 to 10. I don't know why, but for some reason, the bonus round seems much more difficult now. I just couldn't get to 15 no matter what. I'm thinking my old collision detection was just way too generous. There were some bugs I didn't notice before when you collided with or shot a coin or power-up. I didn't adjust for the new kernel properly. Those bugs have been fixed. Fixed a bug in the intermission which caused the hat and the Notelies to fly to the right when the Blob appeared on screen. I didn't notice this before, as I was testing the intermission by triggering it at start-up, which didn't allow for some variables to be set. So the intermission ran fine at start-up, but during game play, if you reached the intermission, things didn't quite work so well. Various other minor bug fixes and a bit of improved efficiency in some parts of the code. I also wanted to share some wonderful news. I don't want to be posting a lot of personal stuff here, and I realize no one here really knows me too well, but this is great news and I'm sharing it with everyone I can. Shortly after I started development of this game back in September of 2019, my fiancée was diagnosed with ovarian cancer. The initial prognosis was quite bad. As far as this game goes, she encouraged me to continue working on it, and doing so has been a nice distraction through a very tough time. Since it initially appeared her time left was limited, this sort of made me want to get the game finished as quickly as possible (well, I didn't do a good job there). Along the way, I tried to get her involved in anything I could, so she wrote the little tune you hear during the intermission. The piece itself is much longer than what you hear in the game, but naturally, I had to cut it down to fit it in there. Anyway, I did say it was good news... Last week, we got the word from her doctor that she is now in remission. Her original doctor gave her virtually zero chance of survival, but fortunately, we found the right guy for the job, and after a lot of chemo and a major surgery, she is now in remission and on the road to recovery. I can now take my time with the rest of the game. ? Mr_Yo-Yo_B20210225.bin Mr_Yo-Yo_B20210225.a

Found a few problems with my logic, so fixed them. My vertical position check was in the wrong place. I moved it to the start of the loop, rather than the end. Also added a check to make sure there was an enemy there to begin with. I was also missing a compare in another part of the code. For the most part, the game would've run fine anyway, I think, but might as well fix it as it was gnawing at my brain. Going to take a few days' break from the game to take care of other things. Should have more updates next week as we creep closer to the finished product. Mr_Yo-Yo_B20210217.bin Mr_Yo-Yo_B20210217.a

I think I got the string collision problem resolved. Added some logic starting at line 3639 that compares the bottom of the obstacle to the top of the Yo-Yo, and if the Yo-Yo is further down the screen, it loops back through the collision check. This seems to have fixed it. That's a few more compares and branches than I'd like to have there, but it works, and according to what I have, I'm still clocking at 262 lines per frame. I'm running a bit short of space in my 2nd bank though. I added a small data array to help with the string collisions, and between that and the extra code, that caused an overflow. So I had to shift around a bunch of data arrays to free up some space. Things still look very tight in that 2nd bank, so I don't know how much more I can squeeze in there. I'll probably need to review much of the code and see if I can make it more efficient before I start adding the final little tweaks to the game. Mr_Yo-Yo_B20210216.zip

I think we can reduce the RAM usage if needed. Yes, that sounds good. I'm going to need the RAM for variables to store the 2nd player's data once the 2 player option is added. I realize that I'll be able to combine multiple data points into one variable (for example, the inactive player's lives remaining and level number could be combined using the high and low bits of the same variable, then separated out when the players change), but I figure I still need a good 5 bytes to store the data for the inactive player. Yes, I thought testing for one collision per frame would suffice, but it obviously doesn't. My thinking was that the lower obstacle would still be in contact with the string one frame later, so it's collision would still register. Guess not. What puzzles me though is that I get the same error sometimes when there's only one obstacle on the screen. They'll still sometimes slip through. Oh well. Either way, my string collision solution didn't work. I'm quite happy with the player and missile collisions, so if we can come up with a string collision routine that doesn't involve eating up RAM, that would be ideal. I couldn't recreate this so not sure of the cause. Does this only occur in the new design of the Cave graphics? No, it occurs regardless of the playfield. It's not constant. The best way to see it is to just descend to the bucket at the bottom, stay there in one place, and closely watch the string. The gap will appear for a few frames every now and then. Now this worries me, because I'm showing the game is running at a constant 262. I really thought everything was solid as far as the frame count is concerned. Not sure why I show 262 and you're getting a fluctuating total. I have made a few more updates with the attached file: The intermission has been repaired, and now works with the new kernel! I think I've got all of Mr. Yo-Yo's special little facial expressions working again. The "Yo-Yo shift" error I mentioned a few posts back that occurs when the player rescues a Notely has been resolved. And since the new cave design appears popular, I went ahead and added it to this ROM. The game is mostly playable now! However, there's still a number of tweaks left to go, and of course, we have to fix that string collision issue. Also, the hoards of Blue Bouncers you get on the first screen are there only so that I could test that string collision better. Once the game is working properly, they won't start showing up until the 3rd round (and there won't be quite as many either). So, those first couple rounds right now are going to be a lot tougher than normal. Mr_Yo-Yo_B20210215.zip

I decided to go with a hybrid solution for the collision detection. I'm checking for the player collision within the kernel, and checking the missile and ball collisions outside the kernel. This ended up saving me a lot of RAM, which I'm running desperately short of. However, I have two small bugs that cropped up, that I just can't seem to solve. The first is there is now an occasional gap between the string and the Yo-Yo, as seen here: This does not appear all the time, but if you hold the button down and just sit at the bottom, it will pop up. This occurred after I added the collision logic, which resides at lines 1265 and 1615. I can't figure out what's causing it or how to fix it. The 2nd bug is that the blue bouncer enemies (the fish-looking guys) will occasionally slip through the string instead of bouncing off of it. If you open the attached binary, hold down the button from the very start, and keep holding it down. You'll hover at the bottom as blue fish start appearing above you. Shortly, the bottom three lanes will have the fish, and after a couple bounces, all three will slip through the string, rather than bounce off of it. The string is the ball object, and my ball object collision logic starts at line 3534. For those of you that have followed this game closely, you may notice the cave looks a lot different in the above pic. I'm experimenting with three different designs. The one I've been using up until now was done more or less out of necessity. The gaps in the cave walls were used in the previous kernel for other purposes. But with a new kernel, I no longer have to stick to that design. So I'm looking at three possible designs. Let me know which one you like best. If I knew how to set up a poll, I would, but I'll go with just the pics here and if you have a favorite, please reply and let me know. First, the old design: Second, the same basic design with the gaps filled in: And finally, a new design meant to look a little more like an actual cave: Which one do you like best? Mr_Yo-Yo_B20210213.zip

Changes made, and the missiles appear to be working again. Thanks! I went through the code, and wherever I could find the code removing an enemy, I've set it to also set that enemy's vertical position to -1. Yes, you are correct. That was a bug that creeped in there when I was trying to adjust all the code to fit the new kernel. I was setting the obstacle's vertical position improperly. It was comparing the vertical position to the bottom of that area, but if it got lower than that, it wasn't resetting it to the proper value. That caused the bouncing Notelies to fall right into the cave walls. I think I've got that fixed now. I think all these bugs are fixed. The missiles look good, and I'm not getting an extra scanline anymore (if anyone else sees extra scanlines creep in there, please let me know). There's still one bug, but it's been in the game a long time, and I'll try to figure this one out. Sometimes when Mr. Yo-Yo returns to the top of the screen to release a Notely, Mr. Yo-Yo will shift to the right a bit. I think that's a REFP1 setting issue. I'm not too concerned about it right now, I'm going to try to fix it before the next playable demo is ready. If all goes as planned, over the next week-plus, I'll finish putting the collision logic in there, and then work on getting the game back to a playable state, so we should have a 1 player demo ready relatively soon. Mr_Yo-Yo_B20210205.zip Mr_Yo-Yo_B20210205.bin

Thanks! I'm glad you like the game! It's always nice to hear that others are enjoying it. And thanks for the artwork! That made my night!

Trying to implement the "Inside kernel collision"... Having an issue with the missile vertical positions. I saw the kernel setup routine changed, and I thought I got everything, but I obviously missed something. Not sure what went wrong. Mr_Yo-Yo_B20210203.bin Mr_Yo-Yo_B20210203.a

Yes, that's exactly the problem I had. Then I think I messed up the code to figure out the zone later on, and that got me frustrated. Thanks! I'll have a look at them over the weekend. I actually had success earlier today with the missile collision detection outside the kernel. This wiped out an enormous amount of lines of code I had in there from my earlier manual method of collision checking. Got rid of an entire subroutine. So I'm pretty happy with how it turned out. Anyway, I'll check out your code over the weekend and see if I can't finish off the collisions. Mr_Yo-Yo_B20210127.a Mr_Yo-Yo_B20210127.bin

So it turns out that this isn't the place to check collisions after all. Looks like I'm checking for a collision before the enemy is drawn, and as a result, the collisions aren't registering properly. I just can't find anyplace in the kernel to put the collision detection. So I think I'll have to check the registers after the kernel, then go through the manual check anyway of finding out what collided. Does anyone see any other way of doing this?

Solved this problem. I thought I tried this before and it didn't work, but it worked now. So I moved those lines a little further up: But I still can't find a place to add a sta CXCLR anywhere. No matter where I add it, even if it appears that I have plenty of free cycles, it starts jumping to 263 scanlines. So I'm still stuck as to where to add the CXCLR, and where I would have space within the kernel to check the other CX registers. Mr_Yo-Yo_B20210123b.zip

That's the plan. Yes, I'm ok as far as coding how to check the CX registers. But here's the problem I'm running into. And I apologize, as I should've included this example with my previous post. Starting on line 1459 of the attached, I've added code to check for P0-P1 collisions. It looks like that part of the kernel is the only part where I'd have time to check. These lines bring me up to 61 cycles, as best I can tell. I've highlighted the lines I've added: Now when you run the binary, you'll see the issue. As soon as I add that bit instruction, a bunch of yellow lines appear on the right side of the screen, and when I fire missiles, four missiles appear - one in each horizontal zone. So why is that happening? I'm not modifying the missile position as far as I can tell. In addition, when any other line is added (for example, a sta CXCLR, just above the WSYNC), then it starts generating an extra scanline, even though I should be at 64 cycles, max. I see that immediately above the lines I've added, there's a cpy instruction. So that's telling me that maybe I'm adding these lines in the wrong spot. Where in this kernel are the best spots to check for the collisions? I'd really like the CXPPMM check to occur inside the kernel, and hopefully the CXP0FB check as well. If I can fit those two in, then I'm relatively ok with checking the missile collisions outside the register, and running some code to determine the zone for each missile, although, ideally, I'd like all four checks to occur inside the kernel. Mr_Yo-Yo_B20210123.zip

Well, so much for thinking I understood collisions. Actually, it's not so much how to use the CX registers, it's a matter of where to place them in the kernel so as to not cause timing issues. As best I can tell, there's only one place in the kernel where I can check collisions, and it's here: Right before the last sta WSYNC. I'm running into two issues. First, as soon as I add ANY instruction there, I get a series of yellow lines on the right side of the screen. Second, I just don't see how I can check what I need to with the remaining cycles. Even when I ignore the yellow lines (and ignore the other graphics glitches that show up as I continue to add code), I run out of cycles very quickly. So here's what I need to do: I need to check 4 registers, CXM0P, CXM1P, CXP0FB, and CXPPMM. For each, I also need to know which of the horizontal zones the collision occurred. So I'm assuming I need to check each register on each pass through the kernel loop, if a collision occurred, record the type of collision and which zone (tmpKernelSection) it occurred in (my plan is to use some equates to represent the collision type, and store those in the high 4 bits of a variable, and use the low 3 bits of the same variable to store the zone number), and then do a sta CXCLR before it loops through the next zone. I figure this method would only record one collision per frame (as a collision higher up the screen would be overwritten by one lower on the screen), but that should be good enough. There are other areas of the kernel where there's time to check collisions, but none of those seem to be part of the main loop through the four horizontal zones that make up the area where the collisions would occur. So I'm assuming checking for a collision in one of the areas after the four zones have been drawn wouldn't do me any good. I would then need logic in the overscan to figure out where a collision occurred, so I'd end up checking collisions manually anyway. Any suggestions? See the zip file a few posts up for the latest code.

As it turns out, there's actually a pretty simple solution to this... ??? Mr_Yo-Yo_Bx.bin

Thanks! I'll have to re-learn how to use the collision detection registers. I played around with them early in the game's development and felt comfortable using them, so I don't anticipate too many problems. But if there's one thing this whole process has taught me is that just when you think you understand how this stuff works, some bizarre unforeseen problem is sure to come up. I'll have to go back and re-read the stuff on fractional positioning you directed me to a while back. I'm not crazy about the idea of re-writing another major portion of the game though. This project has taken much, much longer than I had planned, and I'm far behind on almost all of my non-Atari projects around the house, so I kinda got to finish off this game and get to some other stuff. But I'll at least have a look at the fractional positioning before I finish it up, and I know I had planned on using that in my games going forward. I haven't looked into anything PAL-related so far, so PAL50 works for me. I don't want to create a completely different game for PAL though. I think the PAL and NTSC versions should be as close to each other as possible. If I've got extra scanlines to play with, I'll figure out something to do with them, maybe a little more room at the top, maybe some sort of logo at the bottom like Activision games have, but I'd like to keep the game pretty much the same. Well, like I said, I'd really like to finish this off rather than re-write it again. But if you want to have a crack at it, and it involves just a few minor changes to the current code, then go for it. Like you said, we'd have to have an extra check with the P0-P1 collision detection to see if the obstacle collided with the string or yo-yo portion of P1. Basically, if the obstacle's bottom scanline is at or below the yo-yo's top scanline, then it's a collision with the yo-yo, otherwise, it's a collision with the string. Sounds simple enough, which probably means it's quite complicated. I can't thank you enough for your help on this! Without it, I probably would've settled for a game with lots of flicker. I've learned a lot through this whole process, and I'm sure I'll use a lot of what I've learned going forward in future games.

The dead zone missile issue has been resolved! To quickly sum up, if a missile was fired in scanlines 54-56, 83-85, or 112-114, the missile wouldn't be drawn, as the kernel uses those scanlines to calculate stuff and position the next enemy, so there's no time to draw the missile. I came up with the following code to fix that issue. Now, if a missile is fired in one of these dead zones, it will be positioned to the lowest line in the section above the dead zone. In other words, a missile fired in lines 54-56 will be moved to line 53. Missiles in the other two dead zones will go to lines 82 and 111, respectively. So here's the logic I came up with. I tried to be as efficient as I could, but it still seems just a bit convoluted. Please take a look, and if you see where I could be more efficient or just plain write better code to accomplish the same thing, please let me know. This appears in the LoadMissile subroutine, down on line 2950. The #mRelocTop constant is equal to 86, which is the highest line available for missiles in the next-to-last horizontal zone. The A register holds the missile's vertical position at the start of the code, and the result is transferred over to Y at the end of the code. So it looks like all outstanding issues involving the new kernel have been resolved. I've got (as far as I can tell) a stable 262 scanlines, and two missiles that can fire anywhere while Mr. Yo-Yo is passing through the cave. Next up is adding collision detection back in, followed by restructuring the intermission to fit the new kernel, then a few gameplay tweaks, then I'll be ready to add the menu and various game options, and that should be it! Mr_Yo-Yo_B20210115.zip

Thanks guys! It looks like a solid 262 lines now! Will do. The editor I'm using includes the xmacro by default, so I keep forgetting to attach those. I'll just upload a zip with everything from now on. Done. As best I can tell, it's a stable 262 now. Next up is the dead zone missile issue. We had that fixed under the "one missile" kernel you did, but it looks like that logic gets overwritten in the new kernel. I went back to the most-recent mock up, and this logic is in there... That sets X to the zone the missile is in, and A to the missile position within the zone, and takes care of the whole "firing the missile when you're in between zones" thing. But then a little further down in the code, the missile position gets set again... And that overrides the earlier logic. I figured out that the earlier logic isn't used, and left it out of the game code, but didn't realize at the time that it takes care of the dead zone missile issue as well. So now I just have to figure out a new piece of logic that will work with the new missile positioning to take care of the issue. I've got the new logic all worked out in Excel, now I just have to translate it to assembly. ?? Mr_Yo-Yo_B20210114.zip

Thanks Karl! I've got some time set aside tomorrow and over the weekend to work on it, so I'll have a look then.

Tonight I tried moving a bulk of the vblank code to the end of the overscan to see if that helped. No luck. That extra scanline still pops up. No idea how to solve this.

...but I can't figure out how to fix that. I tried using the align command to align the kernel to the start of the page, but that causes all sorts of problems. So, I'm not sure what to do to fix this issue. Still stuck on this one. I've tried using align before the kernel, before the vblank code, at various points during the vblank code, and none of that worked. I tried moving parts of the vblank code off into a subroutine so that the display kernel could then move up in the code and line up with the start of a page, but that didn't work either. Everything I've tried either fails to compile, or creates bigger scanline count problems. So I'm at a complete loss with what to do next.

So freakin' close. Need a bit of help on a couple issues. First is that scanline problem. I'm at 262, occasionally jumps to 263. As Dennis mentioned above, this is due to crossing a page boundary... ...but I can't figure out how to fix that. I tried using the align command to align the kernel to the start of the page, but that causes all sorts of problems. So, I'm not sure what to do to fix this issue. The second problem has to do with some missile "dead zones". The enemies travel in one of four horizontal lanes. In between those lanes are some scanlines where the kernel is setting up the calcs for the enemy in the next zone, so the missiles cannot appear in those scanlines. Only the yo-yo and string can appear there, all other time is taken up setting up the next enemy lane. So if the player fires a missile while passing through those zones, the missile needs to be relocated either to the enemy lane directly above or below the dead zone. Instead, what's happening is that no missile appears. The scanlines where no missile can appear are lines 54-56, 83-85, and 112-114. If you look at the LoadMissile subroutine, you'll see this code: If you uncomment the highlighted line, and change the value to the scanline you want to test, you can see how no missile will show up in the lines I mentioned above. So the question is this... What's the most efficient way of testing for those values and relocating the missile 1-2 scanlines up or down? I could easily do a series of compares, but it seems like it would take a lot of processing time to go through 9 compares each time a missile is fired. Is there a better way to do this? Thanks! Mr_Yo-Yo_B20210109.bin Mr_Yo-Yo_B20210109.a

Thanks! That's very good to know. I knew about not wanting to cross page boundaries when reading data from an array, but I didn't know that could affect other parts of the code as well. I'm going to try to take care of the other issues first, then I'll leave this one until last. Got it. Over the past few days, I've been slowly going through the kernel mock-up line by line and making corrections in my code. So I've been able to resolve a number of issues. I think I only have two left - one is the extra scanline, which I've yet to tackle, but will get to; and the other is the missiles are now firing from above the yo-yo instead of in the middle of it. But... I haven't gone through everything yet, so I'm hoping that will take care of itself as I continue along. I'm also pretty sure I now have extra useless code sitting above the kernel - old code that the new kernel code makes obsolete. So once I get the other stuff working, I'll go back through and see what's no longer needed up there and get rid of it. So I think I'm making a lot of good progress, and I'm hoping to find enough time this week so that I can complete the kernel integration by the end of the weekend. It's really just a matter of finding the time to take care of things at this point. Updates attached for those that are interested. Mr_Yo-Yo_B20210105.a Mr_Yo-Yo_B20210105.bin

I got a bit sidetracked by work and the holidays, but still working on this. Here's the first pass. Some progress. It's buggy, but I haven't yet gone back through to see what I screwed up. If anyone wants to have a look and fix some bugs, you're more than welcome to it. Looks like there are 2 missiles drawn on the screen, so that's not a problem. The rest of it though, a little buggy. I've got an extra scanline popping in and out of there, the fine horizontal motion on the top enemy isn't working, the missiles move vertically with the player, and the horizontal positioning of the missiles is erratic. I think there were more changes to the VBLANK area of the the code than I thought at first glance. I kinda just rushed through that part, trying to keep as much of the previous code as I could, assuming the setup would be quite similar. I think I was wrong in that assessment, and I think that's what's causing the issues. So I'll get back to this later in the week, and hope to make more progress. I hope everyone is having a wonderful holiday season, and have a Happy New Year! Mr_Yo-Yo_B20201230.a Mr_Yo-Yo_B20201230.bin

Thanks! I'll work with this over the next few days or so and try to implement it into the game. I'll let you know if I have any questions.