[WIP] Bag Boy

[+ZeroPage Homebrew]

I was looking to stream Bag Boy on ZeroPage Homebrew today but unfortunately it only displays a black screen when I start the game on my hardware. I suspect this is due to a initial unstable line count on the first frame when the game begins. Sadly I only have a suspicion of what's causing the issue but not how to fix it. :-(

 

I still have things I wanna do with the graphics to give a more varied experience. And then depending on how much space I may try to improve upon the simple walking movements and may tweak the playfield a bit. Overall I am pleased. Once I finish with the virtual Sprite behavior I am going to add power ups and bonus items.

[KevKelley]

That is unfortunate. I have yet to test this out on hardware and was unaware of any issues. I am still fuzzy on the whole scanlines and cycle count thing. I think I understand it but identifying or diagnosing a problem is a whole other story. I have a more recent version of the game but I would imagine it would experience the same problem.

 

What are your suspicions as to why it may be acting up on hardware? I will try my best to fix it up.

[+TwentySixHundred]

 rem playfield configuration
 DF6FRACINC = 128; Background colors.
 DF4FRACINC = 128; Playfield colors.

 DF0FRACINC = 128; Column 0.
 DF1FRACINC = 128; Column 1.
 DF2FRACINC = 128; Column 2.
 DF3FRACINC = 128; Column 3.

The remarks were throwing alot of warnings probably because the semicolon was directly after the value. It seams it was thinking Background ect was a key word.

 rem playfield configuration
 DF6FRACINC = 128
 DF4FRACINC = 128

 DF0FRACINC = 128
 DF1FRACINC = 128
 DF2FRACINC = 128
 DF3FRACINC = 128

I have had issues in the past placing remarks on the same line as code. Im not sure but could also have to do with the "." period at the end.

 

There is still a bunch of warnings to do with collision detection with player0 & player6. However seems to compile and run fine.

 

By memory the warnings show, but the detection for virtual sprites is still valid in bB.

 

Removed the rem's causing warning's and i haven't real hardware so only tested in Stella.

BBPv020819.bas BBPv020819.bas.bin

Edited February 16, 2019 by Tony The 2600

[KevKelley]

Ah. I will have to make those adjustments in my newest iteration and upload them. That is interesting nonetheless. I have been finding myself look at the debugger screen in Stella to get an idea of what's going on under the hood. I had an issue earlier when I was working on capturing the shopping cart and when I approached the edge of the screen the cart went to the other side and the screen flickered. I think I had fixed that.

 

The only unintended issue I have now is if you get to the side of the screen and continue pushing left or right the other sprites freeze. I have been comparing code from older versions the didn't have the issue.

 

On a plus, some of these unintended actions have given me ideas I may want to implement in the future.

[KevKelley]

And I am still kind of working out the collision detection. For now everything kind of works the way I want but I have been testing new code to try and make things progressively more difficult.

[KevKelley]

I made those changes in my newer code and uploaded it to the first post on this thread. I didn't get a chance to implement many other changes that I had wanted to (since I passed out last night when I was waiting for my computer to update) but I put those in there this morning to see if those would help. I also removed some of the other comments that I had after code that involved the initial coordinates of every sprite.

 rem playfield configuration
 DF6FRACINC = 128; Background colors.
 DF4FRACINC = 128; Playfield colors.

 DF0FRACINC = 128; Column 0.
 DF1FRACINC = 128; Column 1.
 DF2FRACINC = 128; Column 2.
 DF3FRACINC = 128; Column 3.

The remarks were throwing alot of warnings probably because the semicolon was directly after the value. It seams it was thinking Background ect was a key word.

 rem playfield configuration
 DF6FRACINC = 128
 DF4FRACINC = 128

 DF0FRACINC = 128
 DF1FRACINC = 128
 DF2FRACINC = 128
 DF3FRACINC = 128

I have had issues in the past placing remarks on the same line as code. Im not sure but could also have to do with the "." period at the end.

 

There is still a bunch of warnings to do with collision detection with player0 & player6. However seems to compile and run fine.

 

By memory the warnings show, but the detection for virtual sprites is still valid in bB.

 

Removed the rem's causing warning's and i haven't real hardware so only tested in Stella.

BBPv020819.bas BBPv020819.bas.bin

 

[+TwentySixHundred]

Just curious what is the "jump" label doing at this location?

 drawscreen

jump
 rem draw

 rem INSERT GAMEPLAY LOGIC
 goto MAIN_LOOP

it seems to be skipping drawscreen causing the screen to stutter due to these lines.

if joy0up then player0y = player0y-1:if player0y<30 then player0y=31:goto jump
if joy0down then player0y = player0y+1: if player0y>163 then player0y=162 :goto jump
if joy0left then player0x = player0x-bagxy: if player0x<4 then player0x=5:goto jump
if joy0right then player0x = player0x+bagxy: if player0x>149 then player0x=148:goto jump

by removing the goto jump and slightly changing the code like this eliminates the stutter issue.

 if joy0up then player0y = player0y-1:if player0y<30 then player0y=player0y+1
 if joy0down then player0y = player0y+1: if player0y>163 then player0y=player0y-1
 if joy0left then player0x = player0x-bagxy: if player0x<4 then player0x=5
 if joy0right then player0x = player0x+bagxy: if player0x>149 then player0x=148

BBPv021419.bas BBPv021419.bas.bin

[KevKelley]

To be honest I am not sure. When I rewrote everything, I copied a lot of code from my old program I was learning under. A lot of what I had entered was from piecing code together from online examples and suggestions and then trial and error until I got results resembling what I wanted.

 

Things seemed to work so I never really messed with it. Now as I have been adding things I am sure more issues arise. This game is my first so it is still a learning experience.

[KevKelley]

Seeing your code example and explanation makes sense now that I think about. I was just playing around with the player0 movement code this morning but I never really looked at the jump. I guess I have to do a better job following the code or looking at everything when I make changes. I try to label everything with comments so I can find things easier.

Edited February 16, 2019 by KevKelley

[KevKelley]

So I fixed the whole "goto jump" code and updated the .bin and .bas on the page.

 

Thank you so much for pointing that out. I guarantee it would have taken me days to figure out what I did!

 

Next up on my to do/idea list in no particular order:

 

• Change in movement for Customer 1 at higher difficulty.
• Change in movement for Customer 2 when they capture the cart at higher difficulty.
• Change in movement for Truck at higher difficulty.
• Implement power ups (more time, increased speed, extra life, score).
• Bonus Round with multiple cart collection and no cars.
• Random weather.
• Title Screen w/music
• Game Over Screen w/music

[+TwentySixHundred]

Seeing your code example and explanation makes sense now that I think about. I was just playing around with the player0 movement code this morning but I never really looked at the jump. I guess I have to do a better job following the code or looking at everything when I make changes. I try to label everything with comments so I can find things easier.

You're on the right track, trial and error is the best way to learn. Yeah the more complex the game becomes the more bugs arise (it's just part of the parcel). You will run into circumstances where a tiny change will break large chucks of code. The game is coming along well, good job and well done

[+TwentySixHundred]

The player0y boundary is broken, these changes at "player0y-bagxy"

 if joy0up then player0y = player0y-bagxy:if player0y<30 then player0y=player0y+1
 if joy0down then player0y = player0y+bagxy: if player0y>163 then player0y=player0y-1
 if joy0left then player0x = player0x-bagxy: if player0x<4 then player0x=5
 if joy0right then player0x = player0x+bagxy: if player0x>149 then player0x=148

from "player0y-1"

 if joy0up then player0y = player0y-1:if player0y<30 then player0y=player0y+1
 if joy0down then player0y = player0y+1: if player0y>163 then player0y=player0y-1
 if joy0left then player0x = player0x-bagxy: if player0x<4 then player0x=5
 if joy0right then player0x = player0x+bagxy: if player0x>149 then player0x=148

"player0y-bagxy" you might need to make another code block for "bagxy" of it's own for further checks.

Edited February 16, 2019 by Tony The 2600

[KevKelley]

By broken, do you mean that having "player0y-1" or "player0y+1" caused player0 to continue up or below the screen? I had taken your code and tested it but changed the "player0y=player0y+1" and put it back to "if player0y<30 then player0y=31" and everything seemed to be okay.

 

That was one area of code where I was making changes and forgot to make adjustments. I originally had separate variables for the x and y (bagx, bagy) but I realized that I didn't really need to waste 2 variables on something that was probably going to remain the same so I combined them into bagxy. I had kept the y the same when I was comparing speeds to see what I had liked and had never changed it back.

[+TwentySixHundred]

Both "player0y-1" and "player0y+1" are broken as the player exits the screen both top and bottom. Im fairly sure you wanted the player to be held within a boarder. I have noticed you changed

 if joy0up then player0y = player0y-1:if player0y<30 then player0y=player0y+1
 if joy0down then player0y = player0y+1: if player0y>163 then player0y=player0y-1
 if joy0left then player0x = player0x-bagxy: if player0x<4 then player0x=5
 if joy0right then player0x = player0x+bagxy: if player0x>149 then player0x=148

to

 if joy0up then player0y = player0y-bagxy:if player0y<30 then player0y=player0y+1
 if joy0down then player0y = player0y+bagxy: if player0y>163 then player0y=player0y-1
 if joy0left then player0x = player0x-bagxy: if player0x<4 then player0x=5
 if joy0right then player0x = player0x+bagxy: if player0x>149 then player0x=148

Basically you will want to create a separate code block to check further conditions for "bagxy" and "player0y". Have a look at the latest source i posted and compile to see the differences to your latest.

Edited February 16, 2019 by Tony The 2600

[KevKelley]

I see. This is what I had done:

 if joy0up then player0y = player0y-bagxy:if player0y<30 then player0y=31
 if joy0down then player0y = player0y+bagxy: if player0y>163 then player0y=162
 if joy0left then player0x = player0x-bagxy: if player0x<4 then player0x=5
 if joy0right then player0x = player0x+bagxy: if player0x>149 then player0x=148

[KevKelley]

I finally got the power-up generation to work out the way I want. I still have to tweak things like duration, collision, preferred spawning area, sound, color, etc. but I got the basics.

 

Right now they all just give +500 points since that was an easily identifiable result to test.

 

So far there are the following power-ups:

 

Energy Drink - This little can will eventually give a boost of speed.

Over Time - Represented by a little clock, this puts a little bit back on the timer.

Money - A little dollar sign, this will add to the score.

1up - This will add one life.

 

 

Edited February 22, 2019 by KevKelley

[KevKelley]

Still tweaking the power ups but I think I am satisfied with the duration. I started adding different attributes to see if it altered gameplay much. I would love to make them flash but was having problems getting the code to work so for now they are yellow so they stand out a bit for testing. I was satisfied with their appearance, especially when my 5 year old correctly identified them.

 

I had also played around with the cars, moving some code around to different locations and testing how everything worked, as well as when they first appear and how difficulty would increase. For the sake of testing, collision isn't entered for some of them and everything is activated at 100 points. I had added another car on the top of the screen so that I can make more stages of difficulty. I had noticed that it does behave funky at times and not sure if it is how i coded it and added difficulty. Some funky stuff also happened with the third car I had noticed, such as it not going completely to the left and spawning farther to the left then supposed to. I also played around with the change in movement for the customer for added difficulty.

 

I had also noticed a couple yellow specks flicker on the screen. They didn't seem to impact gameplay in emulation but not sure if I screwed up something. Overall the gameplay has become a bit more enjoyable, in my opinion. I updated the original post with the newest edits and left the previous version up for comparison purposes.

 

Back to work!

[KevKelley]

I finally got a Harmony cart and played the game on a 7800. I noticed that when a playfield changed the screen then started to roll, like if the v-hold on the TV was bad. For an issue like this, what would one look for? Is this to vague of a question? Should I test on a 2600?

Edited March 2, 2019 by KevKelley

[+Karl G]

That generally means that you are using too many cycles, which is more evident on real hardware (although you can use the Stella debugger to bring up the debugger every time you go over 262 scanlines to check for this).

[+Muddyfunster]

as Karl mentioned, that's on overcycle problem, basically you are doing too much each frame and there are not enough processor cylces to do all the stuff you want to do.

 

Fixes for that :

 

Optimised code, shift things to alternate frames, do less (!). I had exactly this same problem when I was developing Tyre Trax and it really helped me to code more efficiently

 

I run every major build on the harmony on my real hardware, just to be sure.

 

In Stella press ALT- L, this will show your cycle count, when it goes red, you are overcycling. Also, ask Karl said use the debugger mode is your friend !

[KevKelley]

This time I didn't notice anything weird in emulation but now that I have the Harmony I will be doing more tests. I checked older versions and I didn't have an issue so I suspect it is how I had it redraw the playfield when it rains (I change the color of the parking lot and sky) because it doesn't seem to act up until a certain point.

 

Also, I have seen mention of drawing things on a particular frame. I don't recall reading about how to do that. Is there a trick or how to that I had seemed to miss?

[KevKelley]

I've been getting more familiar with the debugger. I had been cycling through steps to see if anything goes red but I may have tp change the way I use it to fix mistakes.

[+Random Terrain]

I've been getting more familiar with the debugger. I had been cycling through steps to see if anything goes red but I may have tp change the way I use it to fix mistakes.

 

You can have Stella automatically stop with The Faster, Easier Way if the program goes over 262:

 

atariage.com/forums/topic/181081-keeping-track-of-the-scanline-count-with-stella/

 

You just play the game normally and Stella will stop if the program goes over 262.

[KevKelley]

Thanks! I know I had read that thread before when I had previously asked about cycles but I guess I forgot and my brain decided to out for the slow and clunky way.

 

I'm hoping to have time on my lunch break to play around with some stuff.

[KevKelley]

So I got a chance to run it in emulation and used ALT-L. I see where the the cycles flash red on my second playfield so I have an idea how to narrow down the error. This will be great for me to work things out. I can see where I would never catch it without the debugger - it happens so fast I had to run it for a while to catch it without thinking I was blinking.

 

If my idea of how to program this part of the game doesn't pan out at least I will have learned something.

 

as Karl mentioned, that's on overcycle problem, basically you are doing too much each frame and there are not enough processor cylces to do all the stuff you want to do.

 

Fixes for that :

 

Optimised code, shift things to alternate frames, do less (!). I had exactly this same problem when I was developing Tyre Trax and it really helped me to code more efficiently

 

I run every major build on the harmony on my real hardware, just to be sure.

 

In Stella press ALT- L, this will show your cycle count, when it goes red, you are overcycling. Also, ask Karl said use the debugger mode is your friend !