Testing on AFP

[KevKelley]

I was curious. I was testing my game Crossdock and I had came across a couple of weird issues, but I had so far only had it happen on the Atari Flashback Portable. 

 

The main issue I had was that during gameplay, once you fill all the bays at the top of the screen, each bay is then reset using a bit. The issue was that after all the bays were closed, the doors never reset. 

 

I've only had this happen this one time and couldn't figure out why. I haven't had it happen in Stella or on hardware and I was going to double check my code later to see if I did something by accident like reuse a variable but the question I had was if there had ever been any known bug issues with the AFP? I know I had read some things about adjustments to make certain games compatible so I was wondering if there is something I need to pay much attention to when working out bugs, or as long as it works on hardware I should be fine?

 

 

[+KaeruYojimbo]

The emulator in the Flashback Portable is not nearly as accurate as Stella (and seems to have several issues with bB games). Unless there is some specific reason you need the game to work on the AFP, as long as it works on real hardware you should be fine.

[+Karl G]

It offhand doesn't sound like it would likely be related to one of the known limitations of the AFP. The fact that you can't reproduce it makes it tricky to figure out if it's AFP-related or just an obscure corner case in your code, though.

[KevKelley]

Thanks. 

 

I am going to keep testing things and see what happens. I gotta go over the code and see if I slipped up somewhere. I had instances in the past where a typo would cause weird graphical errors or some wacky actions and sounds. These sounded a little specific of an action, which is helpful in that it gives me a place to look.

 

I had another issue, but after thinking about it I think my fat finger may have pressed one of the other buttons on the AFP (it involved the color switch, which is by the fire button) but I did see that there is an issue with the AFP saving the state of the color switch.

 

I will also have to look more into some of the know issues with the AFP. 

 

Edited May 29, 2020 by KevKelley

[KevKelley]

So after testing on hardware again, I couldn't replicate the color issue but at 671 points the bay doors didn't open. It must have been from some new code I had implemented as that didn't happen the other day and I must not have fully tested it beyond an initial "does it work" test. 

 

That is also an odd number for the bay doors not to open, as each pallet is basically equal 10 points (10 boxes), each bay is a bonus 5 points, and completion of all bays gets 25 points so at no point should the number be 671...

 

I don't believe I hit any boxes when I checked the score so that is weird. Unless I'm missing something.

 

I had also noticed that at that point instead of flashing "+25" it flashed "+5." This leads me to believe it skipped the +25 code, which would also have the reset.

 

Hopefully that should be easy to find.

 

Now the weird color issue I am leaning on AFP issue.   

 

Thanks for the help! 

Edited May 29, 2020 by KevKelley

[KevKelley]

I think I may have found the issue...

 

Each bay door is assigned a bit ( e{0}, e{1}, e{2}, e{3}, e{4} )

 

There is a check to see if it drops the pallet and continues or drops the pallets and clears all the doors.

 

I had recently cleaned up the code.  It previously checked for the bay doors like this:

 

if e{0} && e{1} && ... then...

 

I had changed it to check for the bits like this:

 

if e=%00011111 then...

 

What I could tell is that in my latest build I had added a bit check for e{5}, which involves skipping the movement code.  Before there was never any interaction between the door check and the movement check but when I wrote the code to prevent grabbing the flashing numbers, I inserted the movement check inside the door check code.  That would then make e=%00111111 and then skip the re-open code.  Now I don't know why it happened both times at the same score but I had tried a third time and it did not have any interaction so there may be a third factor in play that I am not aware of yet. I realized I also use e{6}, which turns on or off based on 2 counters associated with the level change and obstacle selection - (W and V).  After each stage is completed, W goes up.  When W reaches a certain value V then increases.  This makes sense as to why it happened at the same weird interval.  So my solution would then be to swap out the bit with another unused bit and go from there.

I jumped to it being the AFP because in the same session I had the color switch issue so hopefully this fixes that and there are no issues between the AFP, Stella, or Hardware.  

Edited May 30, 2020 by KevKelley