4 replies to this topic

[blueterrance]

Hello I'm trying to simply change the sign of an 8.8 fixed point number but I can't get it to work properly.

I declare it with:

dim xspeed0=a.m


And then whenever the player's joystick goes right or left I add or subtract 0.01 to xspeed0.

When the player collides with a vertical wall I want to simply change the sign of the xspeed so that it goes in the opposite direction.

I tried:
xspeed0 = -xspeed0

This changes the sign, but makes the player move inversely fast the other way, so if he hits the wall slowly he'll fly away really fast, and if he hits it fast he'll come away slowly.

I also tried:
a = -a

but that had the same effect.

I've tried it with and without the fixed_point_math.asm included.

I also tried making another 8.8 variable where I added or subtraced 0.01, opposite of whatever is added to xspeed0, and then I just change xspeed0 to that when there is a collision. That worked quite well and exhibited the desired behavior, but I don't have enough memory to do that for all the speed variables I have.

I'm using batari 1.0 for linux. It's using DASM V2.20.09 to compile

I also tried including div_mul.asm and then doing:
xspeed0 = xspeed0 * (-1)

And that compiled but then when I collided with the wall the Stella screen went dim and the game froze.

Oh, by the way, I really love batari so far; it's so easy to get a game going, compared to pure assembly.

[SeaGtGruff]

First of all, I see that this is your first post, so welcome to AtariAge!

I would think that using "a = -a" should work, so I'm inclined to suspect that this may be a DASM assembler issue, rather than a batari Basic issue per se. DASM lets you work with numbers bigger than 2 bytes, and I seem to recall a thread in the Stella mailing list about a problem with using a simple statement like "a = -a" to negate a number. You might be able to get it to work by switching to an older version of DASM, or you could try "fooling" it with something like the following:

   a = 0 - a : rem * instead of just a = -a
   a = 255 - a + 1 : rem * if a = 0 - a doesn't work

I'm not sure about the fractional part just off the top of my head; I'll have to go read up on using 8.8 signed variables in the bB help document.

Michael

[SeaGtGruff]

Okay, I just read some old posts in the Stella list, as well as in this batari Basic forum, and I've refreshed my memory.

First of all, DASM version 2.20.10 seems to be the one with negative number issues-- so if you're using that version, you might want to switch to either 2.20.11 or 2.20.07 and see if that helps.

Additionally, negative fixed-point numbers might work a little differently than you expect in batari Basic. The fractional portion is always *added* to the whole portion-- i.e., the fractional portion is always positive or unsigned. That means if the number were +32.25, it would be stored as 00100000.01000000 (32 = %00100000, whereas 0.25 = 1/4 = 64/256, and 64 = %01000000, so "32 and 64/256" would be 00100000.01000000). But if the number were -32.25, it would need to be stored as "-33 and [positive] 0.75," because -32.25 = -33 + 0.75," so it would be stored as 1101111.11000000. I think the smallest/fastest way to do this (13 bytes/18 cycles?) would be as follows:

   dim xspeed0 = a.m

   rem * to negate xspeed0
   a = a ^ %11111111 : rem * or a = a ^ $FF
   m = 0 - m

Michael

[blueterrance]

Oh thanks Michael, that makes sense why the collision speeds were inversely proportional.

I tried the code in your latest post and it works perfectly.

Thanks, I'll post my game up here in a few days when its done

Matt

[SeaGtGruff]

On a hunch, I tried "xspeed0 = 0.0 - xspeed0" and it worked perfectly. You need to use "0.0 - xspeed0" so batari Basic understands that you want to subtract two 16-bit numbers.

Here's a comparison of the code differences:

   dim xspeed0 = a.b

   1528  f49e			  .L04; xspeed0 = 0.0 - xspeed0
   1529  f49e
   1530  f49e   a9 00		 LDA #0	 ; 2 bytes, 2 cycles
   1531  f4a0   38			SEC		; 1 byte,  2 cycles
   1532  f4a1   e5 d7		 SBC b	  ; 2 bytes, 3 cycles
   1533  f4a3   85 d7		 STA b	  ; 2 bytes, 3 cycles
   1534  f4a5   a9 00		 LDA #0	 ; 2 bytes, 2 cycles
   1535  f4a7   e5 d6		 SBC xspeed0; 2 bytes, 3 cycles
   1536  f4a9   85 d6		 STA xspeed0; 2 bytes, 3 cycles; total: 13 bytes, 18 cycles

   1553  f4bb			   .L08; a = a ^ $FF
   1554  f4bb
   1555  f4bb   a5 d6		 LDA a	  ; 2 bytes, 3 cycles
   1556  f4bd   49 ff		 EOR #$FF   ; 2 bytes, 2 cycles
   1557  f4bf   85 d6		 STA a	  ; 2 bytes, 3 cycles
   1558  f4c1			   .L09; b = 0 - b
   1559  f4c1
   1560  f4c1   a9 00		 LDA #0	 ; 2 bytes, 2 cycles
   1561  f4c3   38			SEC		; 1 byte,  2 cycles
   1562  f4c4   e5 d7		 SBC b	  ; 2 bytes, 3 cycles
   1563  f4c6   85 d7		 STA b	  ; 2 bytes, 3 cycles; total: 13 bytes, 18 cycles

So the number of bytes and cycles are the same for both methods (and the results are identical as well).

Michael