Jump to content

Photo

[WIP] Bag Boy


57 replies to this topic

#51 Muddyfunster OFFLINE  

Muddyfunster

    Moonsweeper

  • 300 posts

Posted Sun Mar 3, 2019 3:55 PM

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.  

 

 

Also as RT suggests, you can set the debugger to hard stop if the scanline count is exceeded. I use both methods, sometimes I like to let it run and watch the cycle count go red to see if there are patterns to the overcycle. 

 

The debugger also lets you step through frame by frame, i've found that invaluable for tracking cause.



#52 KevKelley OFFLINE  

KevKelley

    Chopper Commander

  • Topic Starter
  • 196 posts
  • Lots of hobbies, little time, loads of fun.
  • Location:Orlando

Posted Fri Mar 8, 2019 3:49 PM

I've used the various methods discussed and seem to be at an impasse.  Not sure if it is something simple that I am just overlooking but it seems the over-cycling occurs when the score goes over a certain point and I change part of the playfield (I have the sky turn gray and flicker white to simulate lightning) but the cycles seem to change at random, which make me think it has something to do with the power-up generation.  I'll post the .bas of what I was playing around with here while I continue to try and locate this issue.  On the plus side I found some other issues that I was able to fix but sadly they were not the cause of my current headache.

  

Attached Files



#53 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,956 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Fri Mar 8, 2019 4:19 PM

I'm going out for a while. If nobody fixes it before I get back, I'll see if there is anything I can do.



#54 KevKelley OFFLINE  

KevKelley

    Chopper Commander

  • Topic Starter
  • 196 posts
  • Lots of hobbies, little time, loads of fun.
  • Location:Orlando

Posted Fri Mar 8, 2019 9:52 PM

So I still couldn't figure out why it was having the issue but I decided to try and clean up my code a bit and consolidate some redundant lines. For example, since the result of collision between Bag Boy and any car is the same I deleted each individual player/car collision result lines and combined them into one.  I had also started doing the same for the cart/car collision lines.  I freed up a couple hundred bytes in Bank 2. 
 
When I ran a test to check if everything worked, everything seemed fine.  The odd thing was that when I made the jump to the "raining" playfield I did not experience any increase in cycles.  I had the program running for a couple of minutes and using the breakif {_scan>#262} in Stella debugger the game never crashed.  I also noticed the counter in the top left never went red.  
 
I will test this on my hardware in the morning as I wonder if I had actually fixed the issue or am just missing something simple.
 
Here is the .bas of the little changes I had made from moving the code around. 

Attached Files


Edited by KevKelley, Sat Mar 9, 2019 9:33 AM.


#55 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,956 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Mar 9, 2019 4:23 PM

This probably doesn't have anything to do with your problem, but search your program for the word collision. Any time you see a collision check that includes player1 and player2 (or anything higher), smack yourself in the face with a rubber chicken. :D For example, you can't do this:
 

   if !collision(player1,player6) then goto _skipcheck2

 
You can't check for a collision between player1 and player6 that way because they are the same sprite. You'll have to check their positions instead. I better not mess with the code until you rework it.



#56 KevKelley OFFLINE  

KevKelley

    Chopper Commander

  • Topic Starter
  • 196 posts
  • Lots of hobbies, little time, loads of fun.
  • Location:Orlando

Posted Sat Mar 9, 2019 4:51 PM

Yeah... Those are remnants of when I first started using virtual sprites and copied the example code about collision with player1 thinking it applied for all. You had suggested I change it a month ago when I was having another unrelated issue but I never got around to changing it because I didn't see an immediate priority since it didn't seem to impact my game. And then I forgot about it.

Maybe I'll fix it once I get a rubber chicken, or need to free up some bytes.

#57 KevKelley OFFLINE  

KevKelley

    Chopper Commander

  • Topic Starter
  • 196 posts
  • Lots of hobbies, little time, loads of fun.
  • Location:Orlando

Posted Sat Mar 9, 2019 4:53 PM

I'm hoping to clean up some code tomorrow. I spent the day out so didn't get a chance today and with clocks going forward I doubt I can tonight. Better to spend my lunch playing Atari programmer than waste money on lunch.

#58 KevKelley OFFLINE  

KevKelley

    Chopper Commander

  • Topic Starter
  • 196 posts
  • Lots of hobbies, little time, loads of fun.
  • Location:Orlando

Posted Wed Mar 13, 2019 3:27 PM

This probably doesn't have anything to do with your problem, but search your program for the word collision. Any time you see a collision check that includes player1 and player2 (or anything higher), smack yourself in the face with a rubber chicken. :D For example, you can't do this:
 

   if !collision(player1,player6) then goto _skipcheck2

 
You can't check for a collision between player1 and player6 that way because they are the same sprite. You'll have to check their positions instead. I better not mess with the code until you rework it.

 

I was playing around with this for the last couple of days.   

 

I changed a few things to see what works and what doesn't to eliminate my collision statements with virtual sprites.

 

I changed 

 if player1x <= player8x + 8 && player1x + 8 >= player8x && player8y + player8height >= player1y && player8y <= player1y + player1height then goto _CART_HIT
 if !collision(player1,player8) then goto _SKIP_CART_HIT

to this

 if player1x <= player8x + 8 && player1x + 8 >= player8x && player8y + player8height >= player1y && player8y <= player1y + player1height then goto _CART_HIT else goto _SKIP_CART_HIT

and I seemed to get the same effect, where the collision box is created around the virtual sprite and if no collision then the code skips to the next section.  The only "else goto _SKIP_CART_HIT" line I have is at the last check so it runs through the code for all cart/car interactions.  I haven't really seen anything crazy come from this as a result of the change.   

 

Do you think this is a reasonable fix?

 

The only other thing I seem to be having an issue with collision with NUSIZ copies of virtual sprites and player0 or player1.  I was able to get it to work earlier when I was playing around with collision statements yesterday but I cannot remember what I was doing to get it to work (and of course I still had my screwy collision statements in place then).

 

If this works I will work to remove my other screwy collision statements tomorrow.

Attached Files


Edited by KevKelley, Wed Mar 13, 2019 3:29 PM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users