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

[DaveM]

Holy crud, I got it to work.

First, there was a typo here:

Quote

        lda #<(EnemyGfx - ArenaHt)
        clc
        adc LaneVPos        ; Enemy Vertical Position
        adc LaneEnemy        ; Enemy Type
        adc LaneAni        ; Animation Counter
        sta EnemyPointer
        lda >#(EnemyGfx - ArenaHt)
        adc #0
        sta EnemyPointer+1

 

I had a ># instead of a #>

 

Second, I tried to be clever, and it backfired.  I tried to use some #0 bytes from the end of my playfield array as the starting bytes of my enemy array.  Guess I can't do that, at least not how I tried to do it.  When I gave the enemy array it's own line of #0 bytes, the enemy magically appeared.  I then slowed down the animation counter so it changes bitmaps every 4th frame, and now the animation can be seen.

 

Now, I have to adjust things.  I don't like the way he looks.  I'm finding that how something looks on graph paper doesn't necessarily translate to how it looks on screen.  So I'm going to redraw my enemies.  He also looks quite small, so I'll probably give each of my enemies a few more scanlines.

 

Then, I have to work in the logic to change their color line-by-line, and somehow figure out how to get one of those little buggers going on each of the horizontal lanes.

 

Even after I figure that out, I still need room to draw some missiles.  But I'm liking the challenge so far, at least up until I start banging my head repeatedly against the wall.

 

mr_yo_yo 0.5.1.a

[DaveM]

Minor update.  I've redrawn the enemies, and added their proper colors.  Unfortunately, I can still only get one of them to appear at a time, which will make for a boring game.  But, at least they're in there now, and I can control which one I want and where.  The attached source code has the red "Snipper" enemy moving about.  He'll cut your string if he comes in contact with it.  To change which enemy is displayed, look for this bit of code at address F0AC:

 

Quote

        ldy #1
        sty LaneNum
        lda EnemyType,y
        sta LaneEnemy
        lda EnemyVPos,y
        sta LaneVPos
        lda EnemyHPos,y
        sta LaneHPos
        lda EnemyReflect,y
        sta LaneReflect 

That's just some test code to load the enemies in there.  If you change the first line of that, you can load any number from 1-5 to see a different enemy. #1 is the Snipper, here's the rest, with their various abilities that I hope to work into the game:

#2 - "Bouncer" - This guy will bounce off your string, as well as the sides of the screen.  With each bounce, he'll reverse direction and speed up.

#3 - "Flapper" - This purple bat-like creature will just flitter around his lane, hovering up and down.  He won't interact with your string, he'll just go right through.

#4 - "Stunner" - If he comes in contact with your string, he'll zap it, causing you to be stunned for a short period of time.

#5 - This is the bonus coin which will occasionally fly across the screen.  You'll be able to shoot it for a few points, or collect it for bigger points.

 

Here's the issues I'm currently having: As the enemies fly horizontally across the screen, they seem to jump up one pixel just before the reach the center of the screen.  I'm assuming that's some sort of timing issue, so I'm not too concerned about it right now, but I'd like to fix it before the game is complete.

 

My big issue is my (so far) inability to place more than one enemy on the screen.  I've tried a few different approaches, with mostly disastrous results.  However, I haven't yet gotten to the chapter in Steven Hugg's book where he explains displaying multiple sprites.  I've had a brief look at the corresponding example on the 8-bit workshop IDE though, and it flickers way too much for my taste.  So I thought I'd take a crack at it myself and see what I could do.  Some of the results were quite amusing, but nothing came even close to getting anything displayed.

 

Anyone have any suggestions?

mr_yo_yo 0.5.2.a

[+Andrew Davie]

 

        lda #<(EnemyGfx - ArenaHt)
        clc
        adc LaneVPos        ; Enemy Vertical Position
        adc LaneEnemy        ; Enemy Type
        adc LaneAni        ; Animation Counter
        sta EnemyPointer
        lda #>(EnemyGfx - ArenaHt)
        adc #0
        sta EnemyPointer+1
          

Code like the above can be dangerous and contains potentially difficult to find bugs.

Each of those adds has the potential to set the carry bit (indicating your high byte EnemyPointer+1 should increment too).
But you are ignoring the carry bit after each of those first two adds, and only pay attention to it on the last.

 

Sometimes you can get away with this because you know/guarantee there won't be any carry. But I don't think you're doing that here.
So, just a heads-up for you

 

[DaveM]

Thank you, sir!  Rookie mistake.  I'm sure I'll make many of those, but that's how you learn.

[+Andrew Davie]

4 hours ago, DaveM said:

Thank you, sir!  Rookie mistake.  I'm sure I'll make many of those, but that's how you learn.

 

Oh, the irony. Here is some code I found a bug in earlier tonight. Can you see the problem?
 

    ; generate a checksum

                clc
                lda encoding
                adc encoding+1
                adc encoding+2
                adc encoding+3
                adc encoding+4              ;checksum = sum(encoding) & 0xF
                asl
                asl
                asl
                asl
                ora encoding+3
                sta encoding+3                ;encoding[3] |= (checksum << 4)

 

[DaveM]

Looks like they're making much the same mistake I did, failing to clear the carry bit prior to each of those adc instructions.  Then when they're followed by all those asl's and the ora, I'm guessing the failure to clear the carry bit messes with those calcs.  You'll end up with the wrong value in the Accumulator at the end of the adc's, which will result in the wrong value being stored at encoding+3 at the end.  Something tells me there's something else wrong there, but without fully understanding what they're trying to accomplish, I can't quite figure it out.

[+Andrew Davie]

2 hours ago, DaveM said:

Looks like they're making much the same mistake I did, failing to clear the carry bit prior to each of those adc instructions.  Then when they're followed by all those asl's and the ora, I'm guessing the failure to clear the carry bit messes with those calcs.  You'll end up with the wrong value in the Accumulator at the end of the adc's, which will result in the wrong value being stored at encoding+3 at the end.  Something tells me there's something else wrong there, but without fully understanding what they're trying to accomplish, I can't quite figure it out.

Checksums are usually calculated by adding all the bytes together and then "mangling" the result so that it fits in a different number of bytes. It's a "signature" of sorts, to uniquely (hopefully) identify the identity of something without having to check all the bytes in the original. I'm using a checksum to ensure that all 40 bits of my "secret code" are valid. The checksum is calculated by adding the 5 bytes together and then masking out the low 4-bits. Then I shift those low 4 bits to the upper bits and incorporate them into the original "code".  So, the code itself carries a verification checksum to ensure the code is correct.

Since I only need the low 4 bits of the sum, I didn't really care about overflows. But what I missed/forgot is that if there IS an overflow, the next byte added will also be +1 (due to the carry) and that's definitely NOT what I want. I wanted just pure adds, ignoring overflow. So, very simliar to your problem really - not paying due care to the carry bit.

 

 

 

[DaveM]

I've taken a few cracks at re-writing the kernel so that I can display an enemy in each of the horizontal lanes, but I just can't figure out how to do it.  On my last attempt, I so badly screwed up my existing code, absolutely nothing would display properly.

 

My thought was that I'd divide the play area into horizontal sections.  The P0 graphics pointer would remain the same, but the P1 (enemy) graphics pointer I'd re-initialize at the end of each segment and set it up for the next segment.  I'd then perform an HMOVE prior to each segment.  But good ol' Mr Yo-Yo first turned into a garbled mess, then disappeared completely.  The playfield was no longer stable, I got errors saying I had a branch out of range, and the enemies didn't show up at all.  In the end, after a week or so of working on it, I got so lost in my own code that I couldn't tell what the heck I was doing anymore, so I scrapped it.

 

So what's the best way to get numerous P1 objects moving horizontally across the screen, at different vertical positions, but with different bitmaps for each and in varying directions and velocities (in other words, I don't want clones), without massive flicker?

 

I've attached my last stable code and rom image for reference.

mr_yo_yo 0.5.2.a mr_yo_yo.0.5.2.bin

[DaveM]

It's been a while, but I have a small update and a new issue that I need some help troubleshooting.

 

I've decided to put re-writing the display kernel aside for now, and I tried adding missiles.  So here's what's new in this update:

•  The enemies now appear in sequence.  When one reaches the right side of the screen, the next enemy starts on the left in the row below it.  This won't be how it works during the game, but it's nice for testing things out for now.  It also allows those of you who download the rom, but not the code, to see the other enemies.
•  You can now fire missiles by pushing the joystick right and left.  However - they don't work properly.

So here's the issue I'm having with the missiles, and I'm hoping someone could figure out where I messed up this time.  Regardless of where the Yo Yo is when you push the joystick right or left, the missile always appears at the same spot vertically on the screen.  I can't figure out why.  I created a couple arrays, one for each missile object, and I have a loop that sets enable missile bit for the instance of the array which corresponds to its Y position (for example, if missile 0 is fired from scanline 40, then M0Data,40 is set to #2).  The remaining instances in that array are cleared out when the missile reaches the end of the screen, so the array should always start with a #0 at each instance.  At the moment, I have the logic in for both missiles, however, only Missile 0 can be drawn with my current kernel.  I've run out of cycles.  I'll need to re-write the kernel to get Missile 1 in there, or, just limit it to Missile 0.  As an aside, the missile is traveling rather slowly at the moment, but that's intentional.  It just makes it easier to see.  I'll speed things up once I get it working.

 

But... that's where another problem comes in.  Anytime a missile reaches the edge of the screen, the game resets!  No idea how the heck that's happening.

 

So my two big problems now... missile 0 appears at the wrong vertical position, and the game resets when it reaches the edge of the screen.

 

After a few days of debugging and being unable to figure it out, I'm back here to ask for help!

 

I have a quite a number of smaller issues, but they can wait.  I'd like to get this missile problem resolved first, then I'll add some basic collision detection stuff before tackling the other issues I'm having.

mr_yo_yo 0.6.a mr_yo_yo.0.6.bin

[DaveM]

Progress!  And for the first time in a long time, it all pretty much works!

 

Here's what's new:

• I completely re-wrote the missile firing routine, and it works now.  Still not sure why the game reset itself before, but I suspect it had something to do with those enormous arrays I created.  So I did away with those, and found a better way to do things.  I wanted the player to have multiple missiles on the screen, but since I couldn't find the available cycles to display both missile objects, I instead store the coordinates for two missiles to a couple variables, and swap those out every other frame.  The flicker does not seem to be a problem with the missiles flying so fast.  So you can now push the joystick right and left to fire and take some target practice.
• I added functionality to the timer bar.  I originally wanted to have a timer bar and a progress bar, but after playing around with a few configurations, I decided to combine the two into one big status bar.  The red marker is the timer.  It starts at the right, and slowly moves left.  Right now, when it reaches the end, it just resets itself.  The green marker is the progress marker.  Right now, I just have it set to one constant value, so it won't move.  In the completed game, each time you pick up an object in the bucket at the bottom of the screen and bring it to the top of the screen, the green marker will move a bit to the right.  To complete the level, you'll have to get the green marker all the way to the right before the red timer marker goes all the way to the left.
• I was unable to center the scoreboard, so I decided to leave it there and make use of the blank space to the right of it by adding the lives remaining counter there.  The lives counter can display any number from 0-9, so I'll cap the lives at 9.  Right now, I have the score and lives alternating frames.  I'm thinking of changing that in the final product, so that your score will display while you're playing, and it will switch to show lives remaining when you lose a life, between levels, and various other stoppages.  Or I may leave it as is.  The flicker might not seem too bad once I stop the score from incrementing each frame.
• I added some basic collision detection.  When you shoot something, the screen will flash.  If something collides with the Yo-Yo, the playfield will turn red.  If something collides with the string, the playfield will turn yellow.
• Speaking of the playfield, you may notice that it looks completely different.  I changed it for a few reasons.  First, the game was looking too much like Turmoil.  Turmoil is one of my favorites, but I didn't want it to look like I was creating a Turmoil clone, so I removed the walls separating the enemy lanes.  Aside from changing the look of things, this also opened up the playfield more, so the player won't constantly be firing right into the walls, and the enemies now have more room to move vertically within their lanes.  The playfield's new design also serves a rather important function.  After adding the missiles to the display kernel, I was just over the cycle limit.  I needed a way to cut just a couple cycles to get things to work.  To solve this problem, I added a few breaks in the playfield walls.  Those spaces are in just the right spot so that I can use those bits to disable the Missile0 and Ball objects.  That saved me 4 cycles, no longer needing a pair of lda #0 instructions, and got me under the limit.  The playfield design already sets the Player0 reflect bit allowing the yo-yo to spin, and now it disables the Ball and Missile0 objects as well.
• I also redesigned the numbers, adding an extra column of padding.  The numbers looked great on the 8-bit workshop IDE tool, but when I tested the ROM in Stella, I noticed the spacing on the scoreboard just wasn't quite right.  I don't understand why it does that, but it does.  So until I figure that out (yeah, right, like I'll ever figure that out), I added the extra spacing so the digits don't run into each other.  They're still not evenly spaced on Stella, but at least they're not smushed together.

Still have a few issues...

• Still don't know how to display more than one enemy at a time.  I went through the Multisprite demo from Steven Hugg's book, but the whole thing just flew right over my head.  More importantly, I couldn't figure out how to adapt it to what I'm doing with my game.  So I need to figure out a way to solve this problem, because only having 1 enemy on the screen at a time I think would be quite boring.  I had a few ideas:

1. I could alternate frames between enemies.  This would cause flicker.  If I had a full onslaught of 5 enemies going at once, that flicker could be quite bad.  Pac-Man bad.  But since the object of the game is actually to pick up stuff from the bottom and move it to the top, rather than just being a straight shoot 'em up, I think 5 enemies at once would make the game impossibly difficult.  So this approach might be worth trying if I limit it to having only 2 or 3 enemies on the screen at once.
2. I could change things up to use 2xlines.  From what I understand, that'll cut the resolution in half, but increase (double?) the number of cycles I can use per line.  I have a couple concerns about going this route.  First, it seems like it'll be A TON of work to change all my graphics and whatnot to use the reduced resolution (basically, I'm a bit lazy); and second, what if I went though all that, and it still didn't work?  
3. That's about it for the ideas I had, unless someone else has any suggestions.  I don't suppose there's some sort of central repository of display kernel templates out there somewhere?

• The enemies still do a little jump of one scanline, but it's now to the right of the central column.  I think I understand why this is happening, but unless I end up completely re-writing the kernel for some reason, I think it's just going to stay in there.  Once I get the enemies moving up and down a bit, it may become less noticeable. 
• And finally, once again, outside factors have reared their ugly head.  Sometimes life gives you lemons and you make lemonade, but then sometimes life whacks you in the balls with a monkey wrench. I won't bother you with details, this isn't the time or place for that. But as this game progresses, there may be long gaps between updates from time to time.  But I'm determined to finish this thing, so it'll get done eventually.

mr_yo_yo 0.7.a mr_yo_yo.0.7.bin

Edited November 6, 2019 by DaveM
got my left and right mixed up

[Glenn Main]

Well on your way to Funville here. I'm having fun with it already.

[DaveM]

9 hours ago, Glenn Main said:

Well on your way to Funville here. I'm having fun with it already.

Thanks!  I'm glad you're enjoying it.  I really appreciate that.

 

I was testing it out a little more last night and noticed that the missiles will sometimes pass through the thinner parts of some of the enemies without the collision detection registering.  I know why this is happening, and I'll get it fixed before the game's complete.

[Glenn Main]

It's a tough life being a yo-yo here but I'm happy to report I shot the scissoring red beast. They sure had it coming.

[DaveM]

13 hours ago, Glenn Main said:

It's a tough life being a yo-yo here but I'm happy to report I shot the scissoring red beast. They sure had it coming.

Just wait until he starts cutting your string! You'll be minding your own business at the bottom of the screen, and he'll come flying along up top and... *SNIP* and it's all over.  I have a feeling he'll be a real pain to deal with.  So good preemptive strike on your part!  Show him who's boss! ?

[DaveM]

BIG Update! Here is the first fully-playable demo!  There's no audio yet, but the rest of the game is complete, and seems to be working ok.  Feel free to download it, play it, and let me know what you think.  And by all means, if you find an error or something seems wrong, please let me know!

 

I've attached my code as well, and would appreciate any feedback anyone would be willing to give.  I've used up just about every byte of the initial 4k, so I'll most likely have to expand to 8k to get the audio in. 

 

I'm having to alternate frames to get all the enemies on the screen at once.  I tried other methods, but this is the only one I could get to work.  If anyone has any other suggestions, or could show me how to improve on what I have, I'd greatly appreciate it.  To try to minimize flicker, I reduced the number of enemy lanes from 5 to 4, then I split the Player0 duties between the Yo-Yo, the enemy in the top lane, and the little musical note guys you're trying to save.  The Player1 object is used for the enemies in the bottom 3 lanes.

 

So, how to play....

 

The backstory as far as I've gotten so far: One evening, all the toys in toyland were throwing a party, but they were playing their music a bit too loud.  This annoyed the monsters in the nearby Caves of Blah, who prefer silence and boredom.  So they crashed the party, and kidnapped all the musical notes, hiding them in the deepest portion of their caves.  Since Mr. Yo-Yo is the only toy with a string long enough to descend to the bottom of the caves, it's up to him to rescue the Notelies, so the party can start back up again.

 

Game Controls:  Using the left joystick, push the button to descend, release the button to ascend.  Push the joystick right and left to fire your lasers.  You can hold the joystick right or left for continuous fire.

 

Console Controls: A new game starts immediately upon start up.  Use the reset switch to start a new game.  The left difficulty switch controls the Yo-Yo's speed.  Set it to the B position for normal speed, or the A position for slow speed.  The right difficulty switch controls your laser's speed.  Set to B for normal speed, A for slow speed.  The game select and color/B&W switches are not used... yet.

 

The object of the game is to rescue the Notelies from the bottom of the screen, and return them to the top of the screen.  When a Notely is ready to be rescued, he'll appear in the bucket at the bottom of the screen.  To pick him up, descend all the way to the bottom of your screen.  Mr. Yo-Yo will start flashing colors once you have picked up a Notely.  To release the Notely to freedom, return to the top of your string.  Mr. Yo-Yo will return to his normal color, and the Notely will dance off screen.

 

Each time you rescue a Notely, you'll receive between 200-3200 points, and the green marker on the progress bar will move to the right.  When it gets all the way to the right of the progress bar, the round is complete, and you'll receive bonus points for time remaining.  The time remaining is marked by the red marker on the timer bar.  It starts at the right, and slowly ticks down to the left.  If it reaches the left end of the timer bar, you'll continue with the round, however, you can no longer score any points.  You also become ineligible to compete in the bonus round that usually follows the orange cave.

 

Each level has four caves - blue, purple, green, and orange.  Completing all four before their respective timers expire earns you a shot at the bonus cave.

 

In blue caves, the Notelies appear immediately.  You must rescue 5 before time runs out.

In purple caves, the Notelies appear after you shoot 1 enemy, or collect 1 coin. You must rescue 6 before time runs out.

In green caves, the Notelies appear after you shoot 2 enemies, or collect 1 coin. You must rescue 7 before time runs out.

In orange caves, the Notelies appear after you shoot 3 enemies, or collect 1 coin. You must rescue 8 before time runs out.

 

The bonus caves have flashing walls, and nothing but square targets flying around.  The object is to shoot 10 targets before time expires.  If you're successful, a bonus gem will appear in the bucket at the bottom of the screen.  Collect it, and return it to the top before time runs out and you'll earn 9,900 points and an extra life!

 

Enemies:

Grey blob - This guy is new since the last update.  I needed a slow, generic, blob of an enemy, and he's it.  Nothing special about him.  Shoot him for 100 points.

Purple Flapper - Moves up and down a bit, and moves faster than the blob.  150 points.

Blue Bouncer - He bounces of the edges of the screen and off your string, reversing directions and speeding up each time.  Get rid of him as quick as you can.  200 points.

Green Stunner - If he touches your string, he'll stun you for up to 2 seconds.  250 points.

Red Snipper - You'll encounter him later in the game.  If he comes in contact with your string, he'll snip it, costing you a life.  Shoot him or get above him quickly.  300 points.

 

If any enemy comes in contact with the Yo-Yo, you lose a life.  I tried to be forgiving with the collision detection here, so they really have to hit you before it registers.  So if it looks like you passed through an enemy, that's why.  The game is supposed to ignore those little brushes, and only count when the enemies hit a large bulk of your Yo-Yo.  You start the game with 4 lives - one in play, and another three in reserve.  There is no limit to the number of lives you can have in reserve (well, I guess technically, 255 would be the limit), even though the lives indicator only shows up to 9.  Anything more than that, and the lives indicator will show who knows what.

 

Coins are worth 100 points if you shoot them, or 1,000 points if you collect them.  Collecting a coin also doubles the points rescuing Noteies are worth.

 

The value for rescuing a Notely starts at 200 points.  It doubles with each coin you collect up to 3,200 points.  It resets to 200 each time you lose a life, and at the start of each blue cave.

 

The square targets in the bonus round are worth 500 points each.  Running into them simply removes them from play.  Shoot down 10 in a round, and then rescue the bonus gem for 9,900 points and a free life.  This is currently the only way to get a free life.

 

What's left to be done:

Well, audio.  I'd also like to add a title screen, and a game select screen.  I'd like the player to select the starting difficulty level.  There's 9 difficulty levels, with 4 caves each (plus bonus caves).  I wanted to have the action speed up in the later levels, but I ran out of room to add that in, so that may go in later.  I may also add a 2-player option, but I'm not set on that.  There's also a few other animations I'd like to add, including displaying the number of points you earn with each rescue.  

 

So that's about it so far.  Hope you enjoy it!  Let me know what you think!

 

mr_yo_yo 0.12.a mr_yo_yo.0.12.bin

[DaveM]

Whoops... Found a bug.  In the previous rom, you only needed to shoot 1 target in the bonus cave to trigger the appearance of the gem.  The attached rom here fixes that, so you need to shoot 10 targets.  I had set the number to 1 so I could test things out easier, and forgot to switch it back.

mr_yo_yo.0.12.1.bin

[+ZeroPage Homebrew]

I noticed that there's an issue with your line count where it strays from the standard of 262 lines every second frame down to 261 lines (see screencap below, the line in red at the top). You won't see any negative effect in Stella but it can cause screen jitter or screen blanking with real hardware. To observe the effect, press ALT-L in Stella to bring up the line count information overlay on the screen.

 

It's great that you've posted your code so that someone should be able to figure out how to stabilize your line count.

 

BTW: Fun and challenging game, looking forward to playing it on ZeroPage Homebrew! Hopefully someone will also help you find a fix or appropriate kernel to alleviate the flicker issue. I would think that there should be a way to not have the flicker, you've definitely planned all of your enemies on separate vertical areas of the screen so to avoid the flicker issue.

 

- James

 

[DaveM]

Hi James,

 

Thanks for the interest and support!  Glad you're enjoying it so far!  I was aware of the frame count issue, but since it was running ok on Stella, I thought I was good.  I didn't know it would cause an issue on real hardware, so thanks for the heads up on that.  I'll work on getting that fixed in the next update.

 

I would like to get rid of that flicker, so I'm hoping there's a good solution to that.  I've tried a number of things, but just can't get anything to work for me.  I'd also like to get those scoreboard digits more evenly spaced, but I'm at a loss there as well.  Aside from that, I'm also posting my code for others like me who are trying to learn how to make 2600 games.  The more code samples you can look at, the better.  

 

After playing the game a bunch today, I think it's just a bit too difficult.  I've only managed to reach the bonus round twice, and I haven't been able to get to the point where the red snipper makes his debut.  My best game so far is getting to the 2nd green cave with a score of 65,980.  But most games ended in failure much, much earlier.  So I'm going to play around with tweaking things a bit, hopefully allowing players to get deeper into the game.  I'm thinking of having only 3 caves between bonus rounds, starting with 5 lives instead of 4, and re-working when you're introduced to certain enemies a bit.  No good having an enemy in there if you never reach him. 

 

Next update will probably come after the holidays.

[DaveM]

As promised, a post-holiday update!  I made a number of changes that I think improved the game, and fixed a few issues as well:

• The scanline stability issue has been resolved.  It was caused by the score and lives display at the bottom of the screen alternating frames.  When the score was displayed, the game was at 262 scanlines.  When the lives remaining were displayed, it was 261.  A simple sta WSYNC at the end of the lives display routine did the trick.
• I increased the number of lives per game from 4 to 5.
• I reduced the number of caves before a bonus round from 4 to 3.  The first level now has a blue, purple, and green cave, followed by a bonus round.  Every level after that has a purple, green, and orange cave.  The colors and the requirements in each remain the same.
• The enemy distribution has changed, so that the player encounters the harder enemies quicker, while still keeping the weaker enemies more prominent in the later levels.  The blob and flapper are still present at the start of the game, the coin makes its first appearance in the first purple cave, and the bouncer makes its first appearance in the first green cave.  The green stunner first appears in the 2nd green cave, and the dreaded red snipper first appears in the 2nd level orange cave.
• While I felt most of the game was too difficult, I thought there were a couple aspects that were too easy, so I tweaked those as well.  The timer was a complete non-factor before, so I've sped it up a bit.  The bonus round was also too easy, so you now have to shoot 12 targets instead of 10 in order to get the gem to appear. 
• A background flash was added each time you pick up a coin.  There was no previous visual cue, so it was sometimes hard to tell if a coin had been picked up.
• In rounds where you have to shoot a certain number of enemies to get the notelies to appear, shooting a coin now counts as shooting an enemy.  It didn't before, and that caused me some confusion while playing the game.  I'd shoot something, see a flash, and then wonder why the little note guys weren't appearing.  It was because I had shot a coin, and that didn't count.  It counts now.
• I found an issue with missile collision detection, and I think I corrected it.  I noticed that sometimes, a missile would seem to go right through the gut of an enemy, and a hit wouldn't register.  Because both the missiles and the enemies alternate frames, using the CXM0P register didn't work too well, so I wrote my own collision detection routine.  Well, I use the X and Y registers to loop through the missiles and enemies, and in the middle of the nested loop, I call a subroutine which alters those registers.  The Y register is stored to a temp variable before the jsr, and is restored following the rts, but not the X register.  I think this is what was causing the issue.  So I've updated the code to store the X register as well to a temp variable, and this seems to have fixed the issue.  
• Previously, when you completed a level, the point value for rescuing a notely was reset to 200.  It now stays where it is, carrying over from one level to another, only resetting when you lose a life.
• I've also made various other small changes which you may or may not notice, as well as having gone through the code and removed useless bits here and there and re-wrote a few things to optimize them a bit more.  I was hoping to save enough bytes this way to work in some more stuff, but just couldn't quite save enough.

I think these changes improved the game.  I've been able to get much farther in it myself.  Of course, like any game, the more you play, the better you get at it, so I've been figuring out little strategies that hadn't occurred to me while I was coding it.  My current best game is getting to the 4th level purple cave with a score of 114,540.  I'd love to hear how others have done!

 

So the flicker remains an issue.  It doesn't bother me all that much, I mean, it is my first game, and I'm just happy I've gotten this far and it's actually playable.  It's also nowhere near as bad as some of the games from back in the day.  That being said, if anyone is able to help out and fix the issue, it would be greatly appreciated.  If anyone is able to provide a stable, flicker-less solution, I'll of course give due credit, and I'll be happy send you a free boxed copy of the game when and if it gets published.  I'll even sign it if you want, or if you prefer, not sign it as that might bring the value down. 

 

Next steps... Well, as I've used up just about every bit of the initial 4k, my next step is to learn bankswitching, then along with that, learn how to do audio.  As of right this second, I have no idea how to do either.  So I'll probably take some time over the next few weeks to go about figuring that stuff out, then I can start putting the finishing touches on the game.

 

So, let me know what you think. Any feedback is appreciated!

mr_yo_yo 0.12.3.a mr_yo_yo.0.12.3.bin

[TrekMD]

Awesome, thank you!  This game is fun, addictive and TOUGH!  LOL

[DaveM]

I need some help with bankswitching.  I'm using the F8 method from Steven Hugg's book, and I thought I understood how it works, so I'm trying to implement it into my game and now I'm not getting anything.

 

I thought I'd move the overscan code, along with the various subroutines and data arrays that it uses over into the new bank, leaving the start of the frame, the kernel, and graphics arrays in the first bank.

 

As I was moving code over into the new bank, I actually had an image for a while.  It wasn't correct, but it was definitely an image of the game.  At some point while moving the rest of the code to the new bank, that image stopped, and now I just get a series of horizontal white lines.  

 

Not sure where I went wrong on this one.  Could someone please take a look at the attached code and let me know where I messed up this time?  Thanks!

mr_yo_yo_bankswitch_fail.a

[+ZeroPage Homebrew]

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!

 

Twitch Stream: https://www.twitch.tv/zeropagehomebrew/

 

Games:
- Mr. Yo-Yo (2020 WIP) by DaveM
- Beer Pong (2019) by Edward Smith aka easmith
- George 2007 (2007 WIP) by Chris Read aka atari2600land
- George 2019 (2019 WIP) by Chris Read aka atari2600land
- 1 vs 1 Baseball (2020) by Edward Smith aka easmith

 

EDIT: YouTube Archive of Stream

(SET VIDEO TO 1080P60 FOR FULL QUALITY)

 

 

Edited January 12, 2020 by ZeroPage Homebrew

[DaveM]

32 minutes ago, 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!

 

Twitch Stream: https://www.twitch.tv/zeropagehomebrew/

 

Games:
- Mr. Yo-Yo (2020 WIP) by DaveM
- Beer Pong (2019) by Edward Smith aka easmith
- George 2007 (2007 WIP) by Chris Read aka atari2600land
- George 2019 (2019 WIP) by Chris Read aka atari2600land
- 1 vs 1 Baseball (2020) by Edward Smith aka easmith

Sweet! Looking forward to it! Unfortunately, I'll be in the office and won't be able to watch it live, but I'll be sure to watch later tomorrow evening!

[Nukey Shay]

On 1/9/2020 at 7:43 PM, DaveM said:

I need some help with bankswitching.  I'm using the F8 method from Steven Hugg's book, and I thought I understood how it works, so I'm trying to implement it into my game and now I'm not getting anything.

 

I thought I'd move the overscan code, along with the various subroutines and data arrays that it uses over into the new bank, leaving the start of the frame, the kernel, and graphics arrays in the first bank.

 

As I was moving code over into the new bank, I actually had an image for a while.  It wasn't correct, but it was definitely an image of the game.  At some point while moving the rest of the code to the new bank, that image stopped, and now I just get a series of horizontal white lines.  

 

Not sure where I went wrong on this one.  Could someone please take a look at the attached code and let me know where I messed up this time?  Thanks!

mr_yo_yo_bankswitch_fail.a 81.23 kB · 3 downloads

Take care that you move all associated subroutines & data when exporting code to different banks.  For example, SetHorizPos subroutine is called in bank 1 but it exists in bank 2...so the program jumps into data tables which exists at the same address within bank 1.

[DaveM]

3 hours ago, Nukey Shay said:

Take care that you move all associated subroutines & data when exporting code to different banks.  For example, SetHorizPos subroutine is called in bank 1 but it exists in bank 2...so the program jumps into data tables which exists at the same address within bank 1.

Got it.  Thanks!  I thought I had moved over all the necessary subroutines and whatnot to bank 2, but I must've missed that one.  Then when I went through the code to see if I missed anything, I missed it again.  I'll get that moved over later this weekend.

 

This brings up a question - If I have a subroutine that's called from both banks, what is the best way of dealing with that?  Should I create a duplicate of the subroutine in both banks, or is there a more efficient method?  As I'm trying to think it through, I guess I could just switch back to the first bank each time that routine needs to be called from the second bank, but I'm wondering if there's an easier way?