Jump to content

Photo

7800basic strange variable behaviour

7800basic

3 replies to this topic

#1 Dalta OFFLINE  

Dalta

    Space Invader

  • 14 posts

Posted Sun Mar 10, 2019 6:48 PM

Sorry couldn't think of a better title.

 

So, I'm trying to implement moving and placing blocks in order to place them as defenses in front of the player's base. I wrote a simple code, just two lines, so that when the player's x and y are within a range of the block's x and y (15 pixels on the x, 10 on the y), and then the player presses a button, the block will jump to be 4 pixels away from the player's x and y ("carrying" the block). Everything works fine until the block gets to blockx=14 (and blocky=9) when the the block will detach from the player (the variable 'nearbase' is no longer true) and will not allow itself to be picked up again (nearbase is never re-set as 1), even if the player's x and y go away from the edge of the screen. I used plotvalue to display that the variables for player and base x and y are correct, stay what they should be and stay within range. There is no problem on the other end of the screen, only in the lower numbers. When the strange behaviour is happening, I ask (via plotting a debug image) if the playerx is within range, it says it isn't, despite the plotvalue clearly showing that, in fact, it is.

playerx and playery are dimensioned as a and b while blockx and blocky are $2557 and $2561 so it doesn't seem to be an overwriting issue.

 

The block is called 'base' in the code, so blockx=basex.

 if playerx<basex+15 && playerx>basex-15 && playery<basey+10 && playery>basey-10 then nearbase=1 else nearbase=0
 if joy0fire1 && nearbase=1 then basex=playerx+4:basey=playery+4:basepickedup=1 else basepickedup=0

Anyone know what's going on?



#2 RevEng OFFLINE  

RevEng

    Bit Player

  • 5,176 posts
  • Location:bottom of the stack

Posted Sun Mar 10, 2019 8:12 PM

Yeah, it's clear what's going on, but let me give you some background...

On the 6502, numbers are only "negative" in a limited way. If you take 0 and subtract 1, the result is 255. This is called an underflow. There's a similar overflow situation when you add 1 to 255, and the result becomes 0.

The 6502 instructions that check for one value being larger than another aren't hip to whether a particular value is "meant" to be negative or positive. They always assume positive values.

In your code, when basex=14 and you test "playerx>basex-15", the test evaluates to "playerx>255", due to underflow. This test is never true, while your desired "playerx > -1" test would always be true.

One way to work around this is to rewrite your tests to avoid the underflow. e.g. "playerx>basex-15" is the same as "playerx+15>basex". (Just be careful you don't overflow "playerx+15", which won't happen with regular screen coordinates)

#3 Dalta OFFLINE  

Dalta

    Space Invader

  • Topic Starter
  • 14 posts

Posted Wed Mar 20, 2019 2:42 AM

So sorry not to reply sooner, was travelling. Thank you for that explanation, I had read that before but hadn't thought of it as a possible reason for this bug. I implemented your suggested workaround and everything works as intended now. Thanks so much!



#4 RevEng OFFLINE  

RevEng

    Bit Player

  • 5,176 posts
  • Location:bottom of the stack

Posted Wed Mar 20, 2019 6:54 AM

You're welcome!





Also tagged with one or more of these keywords: 7800basic

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users