My 1st Homebrew - Mr. Yo-Yo, WIP

[Nukey Shay]

Depends on the size of the routine, I'd imagine.  And whether it can take advantage of "sharable" code or data in the other bank.  Using a duplicate routine for this is fine for now (until memory begins to get scarce).

[DaveM]

On 1/9/2020 at 10:08 PM, ZeroPage Homebrew said:

We'll be playing Mr. Yo-Yo LIVE on TOMORROW's (Friday) ZeroPage Homebrew stream on Twitch at 12PM PT | 3PM ET | 8PM GMT! Hope everyone can watch!

Good show!  I was able to watch it tonight, but couldn't participate in the live chat.  Looked like the two of you had fun with it, even if it did get frustrating at times, so I'm glad you enjoyed it!  Great feedback too!  This was the first time I got to see someone else play the game other than my 73-year old mother who insisted on giving it a try over the Christmas holiday, and that turned into a disaster that I can't even begin to describe.  So it was nice to see people who know video games play the thing and provide some good feedback.  Anyway, since I couldn't join the chat, I thought I'd respond here to some of the issues brought up on the show.

 

Pressing the button to start a new game instead of the reset switch - Yup. That will be in the final product, just haven't added it yet.  Since the game has no true "game over" sequence yet, at this point, it's sometimes hard to tell when the game ends.  So I didn't implement that yet in order to prevent myself from starting a new game without realizing the previous one had finished.  So you're stuck with the reset switch until I'm ready with a release candidate.

 

The little note guys are "Notelies," the singular of which is "Notely."  Anything else was a typo. ?

 

Some enemies moving too fast - Right now, I have the various enemies moving at a certain number of pixels per frame.  The Blobs move at 1 pixel per frame, while the purple Flappers move at 2 pixels per frame.  The coins move at 3, and the blue Bouncers start off at 1, then increase to 2 after their first bounce, then 3 after their second bounce, where they remain.  The Stunners and the Snippers, which you didn't get to, move at 2 pixels/frame, just for the record.  I was thinking the coins are way too fast, as it's almost pure luck that you pick one up.  And when those red Snippers come out, there's times when you're just screwed.  I don't want everything moving 1 pixel/frame, so I'll have to work in a way to do fractions of a pixel.  Alternating between moving 2 pixels one frame, then 1 the next, for example.  So that's good feedback there, and that's something I can work into the game.

 

2 players - I was thinking of just doing 2 players alternating turns.  The idea of having 2 players go at the same time as you mentioned in the show did occur to me, but I think I'm going to leave that for a possible sequel.  I'm thinking that game will have a female protagonist and be called "Yo-Yo Mama." ?

 

The Blue Bouncers - Yes, those guys are a pain in the ass.  Good catch on the bug with them on the left side of the screen.  I've noticed that enemies will "jump" a bit on that side, so I need to look at my code and figure out why that's happening.  I'll add that to the list of known issues, along with the flicker, and the score digit spacing, and all those damn nightmares I'm having of large blue fish with propellers sticking out of their butts.  

 

Left side of the screen bug aside, simply having them bounce off the string then go away would make them too easy.  I actually like the challenge they present to the player.  You have to get rid of them.  You can't ignore them like the other enemies.  Get to them early before they speed up or you get a whole screen full of them.  It took me a few games to figure out how to deal with them, so I understand the frustration.  But with practice, they can be beaten!

 

So where was that orange cave?  In one of your last games, you beat the green cave, and you were expecting the orange cave, but you got the purple cave, so what happened?  Well, I changed things around a bit since I posted the instructions that you read.  The cave order in the first level now goes like this:  Blue/Purple/Green/Bonus.  After that, level 2 (and every level thereafter) goes like this:  Purple/Green/Orange/Bonus.  So now you're thinking, "OK, I beat the green cave, then went straight to purple.  What happened to that Bonus cave?"  Well, the timer ran out on the green cave.  In order to get the bonus cave, you have to complete all three caves before their timers run out.  So you beat the green cave, but the timer expired so the bonus cave was skipped, and wound up in the next purple cave.  Too bad you didn't get past that one, as the Stunners make their debut in the cave after that, and the Snippers first come out in that orange cave.

 

I probably should've given some strategy tips before the show, but I wanted to see how someone would play the game picking it up for the first time.  It looked like you were starting to hit on a good strategy towards the end of your time with the game.  I've found that the best way to play it is to hang out up top, then when you see an enemy you want to hit, drop down, take one shot at him, and zip back up to the top.  Holding the stick for continuous fire makes it very difficult to aim (you'll almost never hit an enemy moving in the top row), and trying to quickly bob up and down in the middle of the playfield is too tough to control, and almost always sends you straight into an enemy.  But popping out from behind cover to take a quick shot at them, then heading back to the top seems to work pretty well.

 

Thanks so much for having the game on the show and providing the feedback!  Hopefully I can make a number of improvements to it, and a more complete version might be able to make an appearance later on!

Edited January 11, 2020 by DaveM

[+ZeroPage Homebrew]

11 hours ago, DaveM said:

Thanks so much for having the game on the show and providing the feedback!  Hopefully I can make a number of improvements to it, and a more complete version might be able to make an appearance later on!

 

You're welcome, extremely fun game! I can't wait to play an updated version of it down the road. I'll be keeping an eye on the development!

 

- James

[DEBRO]

Hi there,

 

I saw your game on James' show last night. This looks to be a fun and interesting concept. Also congratulations on your first 2600 ASM homebrew! I remember the feeling I had figuring out a 1LK for Climber5.

 

I may be missing something here but the references to Thomas' .skipDraw routine seem to be missing the need to control where in the ROM the sprite data resides.

 

To use .skipDraw properly (as I remember it) you have to ensure your sprite data starts at least the height of the kernel bytes within a page. I know that doesn't read well...sorry. Let's say your kernel is 160 scan lines high (i.e. A0h). That would mean your sprite data would have to start at $xxA0 on a page. You also want to ensure your data doesn't cross a page boundary so you don't end up with an extra cycle when you're looking for a constant cycle kernel.

 

This starting address could be manipulated if you know the limitations of your sprite. For instance, in Pacman4K, my kernel height is 166 (i.e. A6h). The first 4 scan lines are for drawing the playfield so no sprites would be in that area. Knowing that; it should be safe for my sprite definition to start at A2h or anywhere below A2h within the page.

 

Keep up the great work.

 

I'll be watching this progress as I can.

[DaveM]

10 hours ago, DEBRO said:

Hi there,

 

I saw your game on James' show last night. This looks to be a fun and interesting concept. Also congratulations on your first 2600 ASM homebrew! I remember the feeling I had figuring out a 1LK for Climber5.

 

I may be missing something here but the references to Thomas' .skipDraw routine seem to be missing the need to control where in the ROM the sprite data resides.

 

To use .skipDraw properly (as I remember it) you have to ensure your sprite data starts at least the height of the kernel bytes within a page. I know that doesn't read well...sorry. Let's say your kernel is 160 scan lines high (i.e. A0h). That would mean your sprite data would have to start at $xxA0 on a page. You also want to ensure your data doesn't cross a page boundary so you don't end up with an extra cycle when you're looking for a constant cycle kernel.

 

This starting address could be manipulated if you know the limitations of your sprite. For instance, in Pacman4K, my kernel height is 166 (i.e. A6h). The first 4 scan lines are for drawing the playfield so no sprites would be in that area. Knowing that; it should be safe for my sprite definition to start at A2h or anywhere below A2h within the page.

 

Keep up the great work.

 

I'll be watching this progress as I can.

First off, thanks!  This is something I've wanted to do for a very, very long time, and I'm glad that I'm finally getting around to doing it, and it's (sorta) working.

 

As for the rest, I think you flew way over my head there.  I don't quite understand, but that could explain why my sprites would occasionally disappear completely, or a bunch of garbage would show up instead as I was coding the various sections of the game.  So I'd just start moving the sprite data around, almost randomly, until everything would show up again.  I never understood why that stuff happened.

 

I'm sure what I don't know far outweighs what I do know, but if I get things to work, I don't question it. ?

[DEBRO]

Hi David,

 

On 1/12/2020 at 2:05 AM, DaveM said:

As for the rest, I think you flew way over my head there.  I don't quite understand, but that could explain why my sprites would occasionally disappear completely, or a bunch of garbage would show up instead as I was coding the various sections of the game.  So I'd just start moving the sprite data around, almost randomly, until everything would show up again.  I never understood why that stuff happened.

I assembled your code and yes...now you're safe. The sprite data starts 164 (i.e. A4h) bytes within the page. I see your kernel starts with 163. I hadn't spent a lot of time with this to know exactly where your sprites need to reside within a page but for now...A4h is safe.

 

I'd suggest using constants for this and other values. Trust me, it will help you as you progress in your development. It is a whole lot easier changing a value in your constant section than it is hunting down every where you use it to adjust the value. As an example...

 

;===============================================================================
; U S E R - C O N S T A N T S
;===============================================================================

ROM_BASE                = $F000
STACK_POINTER           = $FF

H_KERNEL                = 163

 

Also, as I watched James play your game, I'd suggest using fractional positioning for your sprites. It will help with sprites moving too fast because you'll have more control over their speed. Your PAL50 customers will thank you for it as well. It would help so their game is not 17% slower than the NTSC or PAL60 players.

 

@Andrew Davie and @Thomas Jentzsch helped me with this when I was working on Climber 5. I was adjusting my sprite position the same as you are. This caused my climber to overshoot ladders. Andrew and Thomas came to the rescue. Here is Andrew's explanation on [stella].

 

In this method you would use 2 bytes for the sprites position. One (the low byte) would be the fraction or decimal portion. This is the portion you would manipulate (+/-). The result of this manipulation would affect the carry flag. You would then adjust the high byte based on the carry. This would be the sprite's horizontal position on the screen.

[DaveM]

Big thanks to Nukey Shay for the help with the bankswitching!  I was able to get it to work tonight.  I've attached the working 8k code.  The only other change I had to make was relocating the array the graphics for the coins are in.  A big thanks to Debro for helping me understand why the sprites weren't working sometimes.  Once I got the bankswitching working, the coins would only appear as a player 0 object in the top row.  But I was able to find a new safe space for that array (they're separate from the enemy graphics array, as I couldn't get them to show up when they were all part of the same array, and now I know why), and now they all show up properly.  I didn't bother with a new compiled ROM, since the game plays exactly the same right now.  I'll wait until there's a significant update in the game play before I post the next ROM.  In the meantime, here's a new score to beat: 115,430 ?

 

2 hours ago, DEBRO said:

Also, as I watched James play your game, I'd suggest using fractional positioning for your sprites. It will help with sprites moving too fast because you'll have more control over their speed. Your PAL50 customers will thank you for it as well. It would help so their game is not 17% slower than the NTSC or PAL60 players.

 

@Andrew Davie and @Thomas Jentzsch helped me with this when I was working on Climber 5. I was adjusting my sprite position the same as you are. This caused my climber to overshoot ladders. Andrew and Thomas came to the rescue. Here is Andrew's explanation on [stella].

 

In this method you would use 2 bytes for the sprites position. One (the low byte) would be the fraction or decimal portion. This is the portion you would manipulate (+/-). The result of this manipulation would affect the carry flag. You would then adjust the high byte based on the carry. This would be the sprite's horizontal position on the screen.

Thanks!  I was trying to think of ways to do this, and actually came up with a very similar idea.  So I'll definitely be implementing some sort of fractional positioning as I adjust the enemy speed.

 

I got a couple other ideas for things I'd like to throw in there, including a new power-up.  I'm going to try not to overload the game with that stuff though.  I really want to get to work on adding some audio and finishing off the game, and I don't want to expand beyond 8k.  

mr_yo_yo 0.13.a

[DaveM]

I wanted to go just a bit off topic for a minute.  As some of you know, almost 20 years ago or so, I did a few hacks, including the original Fat Albert hack.  Then I disappeared completely only to resurface a few months back to say I'm working on a new game.  So, I only just learned that someone hacked my hack and created an updated Fat Albert.  I kinda wish someone had checked with me first, but hey, I was nowhere to be found, I didn't own the rights to either Fast Food (the game that I hacked), or the Fat Albert cartoon series, so nothing I could do about it anyway.  And besides, he did a much better job than I, and really improved the game.  

 

The only thing I knew how to do back then was change the shape of the sprites.  That's why my Fat Albert hack has a purple head.  I didn't know how to change colors, only shapes.  Whatever program I was using to alter the ROMs only gave me binary data, and besides, I didn't know a darn thing about coding this stuff anyway.  So I just wanted to defend my version of the game just a bit. ?

 

Why even bring this up?  Well, between football games over the weekend, I came across two other hacks I did way back then that I never released.  Thought I'd finally share them with everyone.  I actually forgot about these until I was going through an old hard drive and stumbled across them.  

 

The first is labelled "Defender Arcade."  IIRC, someone else did a much better Defender Arcade, as a hack of Stargate, so I didn't release mine.  Mine is simply Defender with some of the enemies updated to look more like their arcade counterparts, and the city replaced by some very blocky mountains.  

 

The other hack was "Sub Scan Deluxe."  Basically, I just changed the subs to actually look like subs and updated the numbers so they weren't so blocky.  I think by the time I did this one, I was just so bored with making hacks, I never bothered releasing it.

 

I had one other that I did, but I can't find it.  It was a hack of Atari Video Cube called "Ringo's Groovy Cube."  I updated the main character to look like a caricature of Ringo Starr, and changed the on-screen text to match the updated title, but without being able to figure out how to alter the music into something more Beatles-like, it wasn't worth releasing.

 

Anyway, hope you enjoy these 20-year old never before released hacks! 

Defender Arcade.bin Subscndx.bin

[DEBRO]

Hi David,

 

2 hours ago, DaveM said:

Big thanks to Nukey Shay for the help with the bankswitching!

I'm glad to see you were able to understand and get the bankswitching working but why for this game? There is so much room left in the 4K ROM and opportunities to optimize to claim more space.

[DaveM]

2 hours ago, DEBRO said:

Hi David,

 

I'm glad to see you were able to understand and get the bankswitching working but why for this game? There is so much room left in the 4K ROM and opportunities to optimize to claim more space.

I thought I ran out of room.  As I was adding more code to one of my routines, it caused my arrays to be pushed back from $FB00 to $FC00, and I got an error message saying "No symbol table generated, maybe segment overflow?" So, my lack of experience told me that I ran out of room and had to expand to 8k.  

 

Now, as I'm typing this, I'm thinking I could take some of my subroutines and mix them in between some of my arrays, but I'm not sure where else I can open up more space. 

[DEBRO]

Hi David,

5 hours ago, DaveM said:

but I'm not sure where else I can open up more space. 

As Thomas once told me...just ask  There are a number of talented developers on this board that will be willing to help you.

 

How tied are you to your 2LK? I haven't looked too deeply in the code or implementation but based on other games with similar models...we should be able to get this in a 1LK and without the flicker.

[DaveM]

4 hours ago, DEBRO said:

Hi David,

As Thomas once told me...just ask  There are a number of talented developers on this board that will be willing to help you.

 

How tied are you to your 2LK? I haven't looked too deeply in the code or implementation but based on other games with similar models...we should be able to get this in a 1LK and without the flicker.

Not tied at all.  If there's a flicker-less solution, I'd like to learn it.  I'm planning on doing more games after this one, so the more ways I can learn how to do things, the better.

[R. Jones]

On 1/11/2020 at 2:21 AM, DaveM said:

[ . . . ]

 

I probably should've given some strategy tips before the show, but I wanted to see how someone would play the game picking it up for the first time.  It looked like you were starting to hit on a good strategy towards the end of your time with the game.  I've found that the best way to play it is to hang out up top, then when you see an enemy you want to hit, drop down, take one shot at him, and zip back up to the top.  Holding the stick for continuous fire makes it very difficult to aim (you'll almost never hit an enemy moving in the top row), and trying to quickly bob up and down in the middle of the playfield is too tough to control, and almost always sends you straight into an enemy.  But popping out from behind cover to take a quick shot at them, then heading back to the top seems to work pretty well.

 

[ . . . ]

I think I wanted to start with this, because it's the only thing that really felt off to me. If the yo-yo drops down firing, it leaves a bunch of gaps. The way that it works, for example, in Turmoil feels much more natural. The other difficult things felt they would feel much more fair if the yo yo fired a stream of bullets. The fish made me feel like that scene in pulp fiction where the intern-level gangster tries to shoot Samuel Jackson and John Travolta from point blank and misses every single bullet.

 

And some things I liked about it:

• very unique. I can't remember playing or seeing anything quite like this.
• I love all the animations. It feels really polished and alive
• There's a safe nook that you're diving into, but the fish (?) and scissors make this nook less and less safe
• Variety of enemies

One last thought regarding multiplayer. Space Invaders (and probably some other games) offered bizarre 2-player modes where both players controlled the same cannon. These were really weird to be honest, but just something to think about regarding multiplayer modes that don't require a whole new kernel.

 

Good luck and thanks for creating/sharing this,

- Robert

[DaveM]

6 hours ago, R. Jones said:

I think I wanted to start with this, because it's the only thing that really felt off to me. If the yo-yo drops down firing, it leaves a bunch of gaps. The way that it works, for example, in Turmoil feels much more natural. The other difficult things felt they would feel much more fair if the yo yo fired a stream of bullets. The fish made me feel like that scene in pulp fiction where the intern-level gangster tries to shoot Samuel Jackson and John Travolta from point blank and misses every single bullet.

Thanks for the feedback.  I can work on tweaking that.  Currently, the game allows for 2 shots on the screen at once, with a reload time of 12 frames in between.  The kernel, as it currently stands, only has time to draw one missile object, so I alternate frames between the two missiles.  I could see allowing 3 or 4 shots on the screen at once, but I'd like to see if we stick with the current kernel first.  In the meantime, I can reduce the reload time and see if that helps.

 

The one advantage Turmoil has is that your ship jumps from lane to lane, so the shots are always perfectly lined up in the middle of each lane.  I'm sure that sort of movement has its advantages in writing a kernel for the game, making it easier to reuse the missile objects.  So of course with the yo-yo rolling up and down his string, aiming would be much more difficult.  It's all about finding the right balance, where you're giving the player enough ammo, yet not so much to where the game gets too easy.  I do still think the game is just a bit on the "too difficult" side of things, so I'll continue to tweak things.

6 hours ago, R. Jones said:

And some things I liked about it:

• very unique. I can't remember playing or seeing anything quite like this.
• I love all the animations. It feels really polished and alive
• There's a safe nook that you're diving into, but the fish (?) and scissors make this nook less and less safe
• Variety of enemies

Thanks!  It borrows some ideas from a lot of games, but I hoped I had thrown enough in there to make it unique.  I was a bit worried that having only two bitmaps of animation for each of the enemies wouldn't be enough, but I'm happy with how it turned out.  I actually had another enemy that I cut from the game early on.  He was called the "Bull-it," and looked a bit like a bullet with bull horns.  He just didn't look good, and performed the exact same function as the scissors guy, so I dropped him.  

6 hours ago, R. Jones said:

One last thought regarding multiplayer. Space Invaders (and probably some other games) offered bizarre 2-player modes where both players controlled the same cannon. These were really weird to be honest, but just something to think about regarding multiplayer modes that don't require a whole new kernel.

Yeah, I was never a fan of those modes, but it is something I had considered.  It would probably be very easy to implement, so it's still a possibility.

 

Thanks again for the feedback!

[DaveM]

Latest update...

 

I've condensed the game back to 4K.  I moved a number of my subroutines around, finding spaces in between my various arrays, thereby freeing up a lot of room.  I'm not sure I freed up enough space to keep the game at 4K in the long run, but I'm good for now.

 

Other changes I made:

• Reduced the number of frames between shots from 12 to 9.  This reduces the space between shots, and of course, you can get off shots much quicker.  I played around with various values, and tried less than 9 frames between shots, but I felt that made the game far too easy.  I don't want the game to be where all a player has to do is hold the joystick in one direction, and he mows down every enemy in his path.  Where's the challenge in that?  But at 9 frames between shots instead of 12, it does make things a bit easier to hit if you use continuous fire.  I still contend that the best way to play it though is to fire off one well-aimed shot at a time.
• Implemented some fractional positioning, which slows down all non-blobs in the lower levels.  The enemies now move at a slower pace in levels 1-3 (or levels 0-2 if you're looking through the code).  They return to their "normal" speed for levels 4-6, and they go faster starting with level 7.  Even with the slower pace, no object will move slower than 1 pixel/frame.  I tried it with the blob moving at a half pixel/frame, and it was just too dang slow.
• The right difficulty switch now controls the speed of the enemies.  Setting it to the "A" position will speed things up.

All these changes made the bonus round way too easy.  So I made a number of changes there:

• You now have to shoot 15 targets instead of 12 in order to trigger the bonus gem.
• The bonus targets now move at different random speeds, some moving extremely fast.
• Starting with the level 2 bonus round, the targets will also move vertically; which, if nothing else, is sure to induce a seizure somewhere.

I've got a ridiculously busy weekend ahead of me, so I'll start addressing some of the other issues later next week.  Hopefully, I can get to adding some audio soon.

mr_yo_yo 0.14.1.a mr_yo_yo.0.14.1.bin

[DaveM]

Bouncer bug fixed!  

 

I've fixed the bug that James pointed out on his show a few weeks back, which caused the Bouncer to jump from the left edge of the screen to almost halfway over towards the middle of the screen each time it bounced off the left side.  I was storing the enemy's new horizontal position in the accumulator, then calling the subroutine which reverses the bouncer; however, the accumulator was modified within the subroutine, so when the updated horizontal position was set after exiting the subroutine, it was using the wrong value.  Strangely enough, it was doing the same thing when the Bouncer bounced off the right wall, but the value assigned to the accumulator within the subroutine was coincidentally very close to what the horizontal position should've been anyway, so the error wasn't noticed when bouncing off the right wall.  So now, the correct value is stored to a temp variable prior to calling the routine, and restored after returning.

 

Aside from fixing that bug, I've moved the left wall in a little bit.  I've noticed that the enemies tended to jump a few pixels when they approached the left side of the screen.  They'd seem to hit the left side, then jump a few pixels to the right, then continue to the left.  I couldn't figure out why that was happening, so I pushed in the left wall a few pixels (from 6 to 14), and that seemed to fix it.

 

Hoping to add some power-ups later this week, and to start getting some sounds in there.

mr_yo_yo 0.14.2.a mr_yo_yo.0.14.2.bin

[R. Jones]

Just tried the last build, and that's way more playable. I'm finding that even trying to snipe, I like the shooting a lot more. In the earlier build, I took guys out almost exclusively from behind, but I'm getting more gutsy now.

 

Good luck on the power ups and sound

[DaveM]

Another bug fix, and power-up added.

 

In fixing the last bug, a new bug was created.  Sometimes the blue guys would slowly force their way through the string.  It was actually kinda funny to watch.  If you have the previous rom, get to the green cave (the first board where the Bouncers appear), extend to the bottom of the screen and stay there.  Let the screen fill up with Bouncers.  Eventually, one of them will start forcing his way through the string.  Anyway, that bug has been fixed.

 

I've also added a power-up, which I'm going to call the "Power Pod."  It's a round, white object with a "P" on it.  It appears very rarely, so don't miss it!  It has two functions, but I think I'll let you figure out what those are.  If you shoot it, you get 300 points, and it does one thing.  If you collect it, you get 3,000 points and it does something else.

 

I was going to add a couple other power-ups, but I'm running out of room again, and I didn't think those were good enough anyway.  So I'll go with just the one power-up, and leave it at that.

 

So, I got a couple questions...

As I said, I'm running out of room again.  Would someone mind looking at the code to see if I'm able to free up more space somewhere?  I just don't see how I can add audio, a title screen, game select logic, a 2-player option, and a few other graphics to the game without going to 8k.  I'm sure I could free up a few bytes here and there, but I just don't see where I can free up a big enough chunk to accomplish what I'd like to.  I think some space could be freed up with a new kernel.  If the flicker is removed, then I could re-write my collision detection to use the various registers, which I think would be much more efficient than the way I'm doing it now.

 

With the gameplay pretty much done, I'm finally getting around to sound.  My fiancée is going to compose a little bit of music for the game, as I'm completely inept when it comes to those things.  She's an orchestra teacher, and it was her idea to use little musical note guys as the items you're trying to rescue (I was originally going to use fruit).  Anyway, is there a good tool out there somewhere to help compose little musical pieces on the 2600?  Or, would it be easier to have her just draw up some normal sheet music then translate that to the various values I'd use in my code?

mr_yo_yo 0.15.1.a mr_yo_yo.0.15.1.bin

[DaveM]

Sounds added!  Well, some of them anyway.  Probably about 2/3 of the audio has been added, plus I added a surprise or two.  I also made a slight adjustment where the timer now pauses while you're dropping off the Notelies at the top of the screen.  This was causing a problem when the player would drop off the last Notely to complete the round, but the timer would expire while the Notely was dancing off the screen.  Technically, the player completed his task in time, but would get cheated out of a bonus round because the timer expired. 

 

The game is now 8k.  I optimized the code as best I could to try to stick to 4k, but just couldn't squeeze anything else in there.  So, 8k it is.  I really was hoping to stick to 4k, but it just wasn't going to happen.  This game has fermented in the back of my head for 20+ years, so I'd rather expand to 8k and get everything in there, than cut stuff out just to stick to a 4k limit.  But I've decided come hell or high water, my next game will be no more than 4k.

 

Gonna shut it down for the weekend.  I got an idea for a new feature to add to the game, so I'm going to try to add that next week.

 

Keep letting me know if there's any issues or errors, and I hope you enjoy this latest update!

mr_yo_yo 0.17.3.a mr_yo_yo.0.17.3.bin

[DaveM]

I've added a cutscene/intermission following successful completion of the bonus cave.  There will eventually be music to go with it, but that's at least a few weeks away.  In the meantime, when it pops up, just hum a catchy tune while the cutscene plays.  I've also added one more sound, a small little "boing" effect as the Notelies dance off screen.  I was hoping to add more this week, but that cutscene was a lot more work than I thought it would be.  

mr_yo_yo 0.18.a mr_yo_yo.0.18.bin

[DaveM]

Another week, another update.  What's new...

• Added pause functionality for the Color/B&W switch.  You can now flip the switch to B&W to pause your game.  There's an interesting bug if you start a new game or power up the system with the switch on B&W, but I'll leave that alone for now.  It doesn't affect the game play, and I'll be adding a game options menu later, so I'll take care of it then.  In the meantime, it's a strange little quirk.
• I've slowed down the enemies in levels 4 and up.  So what was the speed of the enemies in the original demo is now the highest possible speed (without the difficulty switch added), and is used for levels 7-9.  Levels 4-6 are halfway in between the starting speed and that faster speed.  As I was testing the game, I found I could get to level 4 with all my lives intact, then they'd all be wiped out in a matter of seconds.  So, I eased things up a bit.
• More sounds added.  I added a little "charge" tune when Mr. Yo-Yo rolls on, and added sound effects for the Power-Up.  I may have added a couple others in there, but I don't remember.

What's left...

• I think the only sounds left are some effects I want to add for the bonus round, plus the little bit of music my fiancée will eventually get around to doing for the cutscene and for when the yo-yo rolls off the screen at the end of a round.  
• Title screen
• Game menu and game variations.  I'm thinking 1 or 2 players, and choice of starting level.  Then there was this suggestion a while back...

  On 1/15/2020 at 4:54 PM, R. Jones said:

  One last thought regarding multiplayer. Space Invaders (and probably some other games) offered bizarre 2-player modes where both players controlled the same cannon. These were really weird to be honest, but just something to think about regarding multiplayer modes that don't require a whole new kernel.

  … which I'm thinking is a good idea, so I'll try to include it.  So, open question to anyone who's read this far: If I implement such a game mode where one player controls movement, and the other fires the lasers, how often should I switch those responsibilities?  Should I switch them up with every successful notely rescue, switch them at the end of the round, switch them when a life is lost, or just keep them the same throughout the game and let the players decide when to pass the joysticks back and forth?

• Once all of that is complete, then I think it'll be time to try to solve the flicker issue.  So I'll be reaching back out to Debro and maybe some others to see if they're willing to assist.

• If a flicker-less solution is found, I'll then go back and re-write the collision detection to use the collision registers, rather than what I have in place now.

• And I think that's it.  Anyone see anything else that needs to be done?

So another open question to anyone who's read this far.... How are the sounds?  I mentioned at the start of this thread that I had done games in VB, etc., but I never created any sound effects.  Most of those games were done to kill time at work.  I used to work a lot of temp jobs, and companies would bring me in for something they thought would take 90 days, then I'd go and write an Excel macro and have the whole job finished by lunch on day 1. Usually, they'd let me go and I'd end up cheating myself out of 89 days of work.  So I started writing these games using the user forms in VBA for Excel and Access, just to kill time, but of course, I'd never add sound, since they were designed to be played at work.  I'm hoping to port a couple of them to the 2600 some day.  But anyway, first time doing audio.  No musical ability whatsoever.  Hope everything sounds ok.

mr_yo_yo 0.19.1.a mr_yo_yo.0.19.1.bin

[DEBRO]

Hi David,

 

12 hours ago, DaveM said:

• Once all of that is complete, then I think it'll be time to try to solve the flicker issue.  So I'll be reaching back out to Debro and maybe some others to see if they're willing to assist.

• If a flicker-less solution is found, I'll then go back and re-write the collision detection to use the collision registers, rather than what I have in place now.

• And I think that's it.  Anyone see anything else that needs to be done?

You should be able to this without flicker. Hopefully @Atarius Maximus is okay with me linking directly to his site. Take a look at my (embarrassing to look at) source for Climber5 or Joe Grand's UltraSCSIcide. We both used Oystron by Piero Cavina as a model. They are good examples of vertically separated sprites.

 

Also look at my reverse-engineering of Atari's Air-Sea Battle or 20th Century Fox's Turmoil. These are good examples as well.

 

[DaveM]

2 hours ago, DEBRO said:

Hi David,

 

You should be able to this without flicker. Hopefully @Atarius Maximus is okay with me linking directly to his site. Take a look at my (embarrassing to look at) source for Climber5 or Joe Grand's UltraSCSIcide. We both used Oystron by Piero Cavina as a model. They are good examples of vertically separated sprites.

 

Also look at my reverse-engineering of Atari's Air-Sea Battle or 20th Century Fox's Turmoil. These are good examples as well.

 

Thanks!  I'll definitely be checking those out when I get ready to re-write that part.  I looked at the Turmoil code way back when I started, but I got lost in it and didn't comprehend what was going on.  But that was a while back, and hopefully I've learned something since then, so I'll have another look at it.

[DaveM]

Small update this week, but it'll probably be the last one for a little while.  I've added a little tune for the Game Over sequence, and once that's done playing, you can now start a new game by pressing the joystick button.  I've also added a small sound effect when you crash into one of the targets in the bonus cave.  I think that's it for the audio, except for the cutscene music.

 

For some reason, I seem to be having some scanline issues again.  Every now and then, it'll jump to 263 scanlines, and I have no idea why.  I've kinda hit a bit of a wall with this for now, and on top of that, I've caught one helluva nasty bug.  Lately, I'm either coughing my head off, or the meds have kicked in and my head's in a complete fog.  So I'm in no mood to start debugging that stuff right now.  If anyone wants to have a look at the code and figure it out, or point me in the right direction, I'd appreciate it.  If not, I'm sure I'll get to it eventually.

 

Once I'm back to normal, the next thing I'll tackle will be that kernel.  I'll start going over the code that Dennis suggested, and see if I can figure something out.  I'd like to get that set before starting on game menus or anything.

 

I finally started testing my game outside of Stella, mainly because the button on my game controller broke playing this damn thing so much.  The game seems to work great on the Flashback portable.  When I loaded it onto my Retron 77, I'm having issues with the system dropping some of the audio.  I've downloaded the latest version of Stella for the Retron, but I've noticed a lot of games have a bit of a lag when it comes to the audio.  Anyone know of a quick fix for that?  Anyway, I've found the game is damn near impossible to play using an Atari joystick.  Kinda made me question whether or not to continue with it.  While playing it on Stella and on the Flashback Portable, I can usually break 100k quite easily (if you're curious, and I can't imagine anyone is, the score to beat is 365,280), but using the Atari joystick, I couldn't get past the first couple caves.  The split second you lose trying to swing that big joystick back and forth makes shooting the enemies really quite difficult.  On the bright side, when I switched to their new Ranger controller, it worked much better.  The audio lag was still throwing me off, but at least it was playable.  The one bright spot about testing it on the Retron is that it prompted me to go add the code to reset the game with the joystick button. ?

 

Enjoy!

mr_yo_yo 0.19.3.a mr_yo_yo.0.19.3.bin

[Glenn Main]

There's a lot to like you know, not too much longer before all is tidy for release.