How do you flip between 1 and -1? (a=0-a, a=a^254)

[+Random Terrain]

Without using a bunch of if-then statements, how do you flip a number between 1 and -1 or -1 and 1 in either direction? It's not hard to do with other BASIC languages, but can we do that with batari Basic?

 

 

Thanks.

 

Edit:

Answered in posts below. You can use:

 

a=0-a

 

or

 

a = a^254

 

See this post for details on which one you should use:

 

http://www.atariage.com/forums/index.php?s...ndpost&p=927991

Edited September 9, 2005 by Random Terrain

[+batari]

Without using a bunch of if-then statements, how do you flip a number between 1 and -1 or -1 and 1 in either direction? It's not hard to do with other BASIC languages, but can we do that with batari Basic?

 

 

Thanks.

927378[/snapback]

Yes, something like a=-a should work.

[+Random Terrain]

Without using a bunch of if-then statements, how do you flip a number between 1 and -1 or -1 and 1 in either direction? It's not hard to do with other BASIC languages, but can we do that with batari Basic?

 

 

Thanks.

Yes, something like a=-a should work.

927380[/snapback]

I tried that with and without spaces and it won't compile, so I thought that wasn't allowed. Well, it won't compile in an if-then, but it will outside of it but it complains about an error and then the buggy program runs.

Edited September 8, 2005 by Random Terrain

[+Random Terrain]

In case anyone wants to know, I figured out a way to toggle without creating extra if-then statements:

 

 rem * Here's a crappy little program I (Random Terrain) made as an example of
 rem * sprite movement with the joystick. You control a sprite and there is also 
 rem * a bouncing ball that you can bang into.
 rem * Don't worry, you are blocked from going past the edge of the screen.

gamestart
 rem * Create alias for each variable.
 dim spritex = a
 dim spritey = b
 dim directionx = c
 dim directiony = d
 dim directionx2 = e
 dim directiony2 = f

 rem * Setup.
 COLUPF = 204 : score = 0
 player0x = 93 : player0y = 54
 bally = 30 : ballheight = 1
 r = rand : if r > 30 && r < 155 then ballx = r else ballx = 30
 directionx = 1 : directiony = 1
 directionx2 = 255 : directiony2 = 255

 rem * Define player0 shape.
 player0:
 %11111111
 %10100101
 %10100101
 %10111101
 %10111101
 %10100101
 %10100101
 %11111111
end


 rem * Main game loop starts here.
gameloop

 scorecolor = 158
 COLUP0 = 28
 drawscreen

 rem * Move player0 if joystick is used and don't allow border crossing.
 if joy0up && player0y > 10 then player0y = player0y - 1
 if joy0down && player0y < 89 then player0y = player0y + 1
 if joy0left && player0x > 15 then player0x = player0x - 1
 if joy0right && player0x < 167 then player0x = player0x + 1

 rem * Move ball and don't allow border crossing and detect collision with player0.
 if bally < 3 then directiony =  1 : directiony2 = 255
 if bally > 87 then directiony = 255 : directiony2 = 1
 if ballx < 16 then directionx = 1 : directionx2 = 255
 if ballx > 174 then directionx = 255 : directionx2 = 1 
 if collision(ball,player0) then directionx = directionx2 : directiony = directiony2 : score = score + 10

 ballx = ballx + directionx : bally = bally + directiony

 if switchreset then goto gamestart

 goto gameloop

As you can see, I just made an opposite within the if-then statements that already existed. Might be a better way than that, but I can't think of it.

 

 

EDIT:

 

Here is the same thing, but using Zach's tip (from a post below).

 rem * Here's a crappy little program I (Random Terrain) made as an example of
 rem * sprite movement with the joystick. You control a sprite and there is also 
 rem * a bouncing ball that you can bang into.
 rem * Don't worry, you are blocked from going past the edge of the screen.

gamestart
 rem * Create alias for each variable.
 dim spritex = a
 dim spritey = b
 dim directionx = c
 dim directiony = d

 rem * Setup.
 COLUPF = 204 : score = 0
 player0x = 93 : player0y = 54
 bally = 30 : ballheight = 1
 r = rand : if r > 30 && r < 155 then ballx = r else ballx = 30
 directionx = 1 : directiony = 1

 rem * Define player0 shape.
 player0:
 %11111111
 %10100101
 %10100101
 %10111101
 %10111101
 %10100101
 %10100101
 %11111111
end

 rem * Main game loop starts here.
gameloop

 scorecolor = 158
 COLUP0 = 28
 drawscreen

 rem * Move player0 if joystick is used and don't allow border crossing.
 if joy0up && player0y > 10 then player0y = player0y - 1
 if joy0down && player0y < 89 then player0y = player0y + 1
 if joy0left && player0x > 15 then player0x = player0x - 1
 if joy0right && player0x < 167 then player0x = player0x + 1

 rem * Move ball and don't allow border crossing and detect colision with player0.
 if bally < 3 then directiony =  1
 if bally > 87 then directiony = 255
 if ballx < 16 then directionx = 1
 if ballx > 174 then directionx = 255
 if collision(player0,ball) then directionx = directionx^254 : directiony = directiony^254 : score = score + 10

 ballx = ballx + directionx : bally = bally + directiony

 if switchreset then goto gamestart

 goto gameloop

Edited September 9, 2005 by Random Terrain

[danwinslow]

a=a*(-1)

 

? maybe.

[+batari]

a=a*(-1)

 

? maybe.

927699[/snapback]

Not yet - it will get confused by the parens.

 

I am a little surprised that a=-a does not work - I thought I programmed this in. I guess I did it wrong Either way, a=0-a will work.

[Zach]

For 1 and -1, a = a ^ 254 would work too. Plus, it should produce more efficient code. A lot of people here would be happy to explain why it works if you're interested.

Edited September 8, 2005 by Zach

[+Random Terrain]

I am a little surprised that a=-a does not work - I thought I programmed this in.  I guess I did it wrong Either way, a=0-a will work.

927707[/snapback]

Thanks. That works. I'm really bad at math, so there is no way I would have come up with that.

 

 

For 1 and -1, a = a ^ 254 would work too. Plus, it should produce more efficient code. A lot of people here would be happy to explain why it works if you're interested.

927766[/snapback]

That also works. Is one better than the other without a doubt?

 

Which one should I go with?

 

a = a^254

 

or

 

a=0-a

 

 

Thanks.

[SeaGtGruff]

I am a little surprised that a=-a does not work - I thought I programmed this in.  I guess I did it wrong Either way, a=0-a will work.

927707[/snapback]

Thanks. That works. I'm really bad at math, so there is no way I would have come up with that.

 

 

For 1 and -1, a = a ^ 254 would work too. Plus, it should produce more efficient code. A lot of people here would be happy to explain why it works if you're interested.

927766[/snapback]

That also works. Is one better than the other without a doubt?

 

Which one should I go with?

 

a = a^254

 

or

 

a=0-a

 

 

Thanks.

927870[/snapback]

 

That depends on what you need to do.

 

"a = 0 - a" compiles as "LDA #0:SEC:SBC a:STA a," which takes 7 bytes, and uses 10 machine cycles.

 

"a = a ^ 254" compiles as "LDA a:EOR #254:STA a," which takes 6 bytes, and uses 8 machine cycles.

 

Thus, "a = a ^ 254" is more space-efficient and time-efficient than "a = 0 - a."

 

*However*, "a = 0 - a" flips between a and -a for any value of a (e.g., 2 and -2, or 3 and -3, or 4 and -4, etc.), whereas "a = a ^ 254" flips between a and -a if and only if a happens to be equal to 1.

 

That's because if a is equal to 1, then it's flipping between %00000001 (1, which is +1 if the byte is considered to be a signed number) and %11111111 (255, which is -1 if the byte is considered to be a signed number).

 

If a is anything other than 1, then "a = a ^ 254" will produce some value other than -a. For example, if a is equal to 2 (%00000010), then "a = a ^ 254" will result in %11111100 (253, which is -3 if the byte is considered to be a signed number).

 

So it all depends on whether you're specifically wanting to flip between 1 and -1, or whether you're actually wanting to flip between a and -a for any a.

 

Michael Rideout

[+Random Terrain]

That depends on what you need to do.

 

"a = 0 - a" compiles as "LDA #0:SEC:SBC a:STA a," which takes 7 bytes, and uses 10 machine cycles.

 

"a = a ^ 254" compiles as "LDA a:EOR #254:STA a," which takes 6 bytes, and uses 8 machine cycles.

 

Thus, "a = a ^ 254" is more space-efficient and time-efficient than "a = 0 - a."

 

*However*, "a = 0 - a" flips between a and -a for any value of a (e.g., 2 and -2, or 3 and -3, or 4 and -4, etc.), whereas "a = a ^ 254" flips between a and -a if and only if a happens to be equal to 1.

 

That's because if a is equal to 1, then it's flipping between %00000001 (1, which is +1 if the byte is considered to be a signed number) and %11111111 (255, which is -1 if the byte is considered to be a signed number).

 

If a is anything other than 1, then "a = a ^ 254" will produce some value other than -a. For example, if a is equal to 2 (%00000010), then "a = a ^ 254" will result in %11111100 (253, which is -3 if the byte is considered to be a signed number).

 

So it all depends on whether you're specifically wanting to flip between 1 and -1, or whether you're actually wanting to flip between a and -a for any a.

927991[/snapback]

Thanks. I was only using 1 in my last test program, so a = a^254 is the best choice for now. I'm sure I'll need a = 0-a one of these times though.

[chad5200]

Weird...

 

The "sample.bas" included with bB 0.35 includes the command:

 

"shipvelocity=-shipvelocity"

 

and that compiles just fine.

 

Why?

[+Random Terrain]

Weird...

 

The "sample.bas" included with bB 0.35 includes the command:

 

"shipvelocity=-shipvelocity"

 

and that compiles just fine.

 

Why?

928120[/snapback]

I wonder if it has to do with this:

 

dim shipvelocity=b.b

 

I still don't understand that yet. Or maybe it has to do with this:

 

include fixed_point_math.asm

[SeaGtGruff]

Weird...

 

The "sample.bas" included with bB 0.35 includes the command:

 

"shipvelocity=-shipvelocity"

 

and that compiles just fine.

 

Why?

928120[/snapback]

 

Hmm, you're right! Three things come to mind, but I don't have time to check them out right now:

 

(1) Because shipvelocity is a "dim" instead of a "straight variable"?

(2) Because shipvelocity is a "floating-point" variable instead of an "integer byte"?

(3) Because batari said that "a = - a" should have worked, so it's apparently a bug related to at least that specific scenario (if not others as well), similar to the way that "||" followed by ">" produces a bug, yet "||" followed by "<" doesn't.

 

Michael Rideout

[+Random Terrain]

Weird...

 

The "sample.bas" included with bB 0.35 includes the command:

 

"shipvelocity=-shipvelocity"

 

and that compiles just fine.

 

Why?

928120[/snapback]

Hmm, you're right! Three things come to mind, but I don't have time to check them out right now:

 

(1) Because shipvelocity is a "dim" instead of a "straight variable"?

(2) Because shipvelocity is a "floating-point" variable instead of an "integer byte"?

(3) Because batari said that "a = - a" should have worked, so it's apparently a bug related to at least that specific scenario (if not others as well), similar to the way that "||" followed by ">" produces a bug, yet "||" followed by "<" doesn't.

928131[/snapback]

I know for sure it's not because of a regular dim, since I was using directionx=-directionx and it didn't work.

[+batari]

Weird...

 

The "sample.bas" included with bB 0.35 includes the command:

 

"shipvelocity=-shipvelocity"

 

and that compiles just fine.

 

Why?

928120[/snapback]

 

Hmm, you're right! Three things come to mind, but I don't have time to check them out right now:

 

(1) Because shipvelocity is a "dim" instead of a "straight variable"?

(2) Because shipvelocity is a "floating-point" variable instead of an "integer byte"?

(3) Because batari said that "a = - a" should have worked, so it's apparently a bug related to at least that specific scenario (if not others as well), similar to the way that "||" followed by ">" produces a bug, yet "||" followed by "<" doesn't.

 

Michael Rideout

928131[/snapback]

It's #3. There is a specific section of the compiler where it handles "assignment to a negative" and I thought I specifically coded this case in. It looks like 4.4 fixed point types were coded properly, but apparently integers were not.