Page 1 of 1
setting boundaries
Posted: Sun Nov 12, 2006 9:52 pm
by VanOccupanther
(Thank You tepples, the classic multiplying 16 bits by 16 bits algorithm really helped me!)
How do you set boundaries? After increasing the speed of my bullet, i noticed that sometimes it will cross the screen two or three times.
My code for checking the y boundary of the screen is like this:
Code: Select all
lda bullet_y
eor #%11100000 ;check check for row 240 or row 0. If there, delete the bullet from the index and screen...
bne +
lda bulletindex
and #%11111110
sta bulletindex
lda #0
sta sprite+4
sta sprite+7
The problem is that when the bullet is flying faster, i think, is that it skips over more numbers and may skip row 240 and row 0 causing it to flying again across the screen.
What can be done to make sure that the bullet never crosses the boundary of the screen, no matter how fast it is flying? Maybe it might work to subtract the previous row from the current row and if it's higher or lower than some number, don't let it pass?
Posted: Sun Nov 12, 2006 10:08 pm
by Memblers
I'm not sure how the EOR there is helping any.
So basically if I understand the problem, you're just comparing to line 240 and 0, so if it goes from 239 to 241 your check won't find it. The solution is to do greater/less than checking with CMP and BCC/BCS. And delete the object if it's on a line greater than 240. That'll take care of the line 0 check too, since it'll wrap into the erasing zone.
There's a tutorial here:
http://www.6502.org/tutorials/compare_instructions.html
Check the carry flag on that table.
BCS/BCC are pretty much
the way to do hit detection. Very helpful.
Posted: Sun Nov 19, 2006 8:46 pm
by VanOccupanther
Thank You for telling me about cmp!
My game has a very odd problem now. If i fly toward the bottom of the screen and fire directly up, the bullet disappears mid screen. While at the bottom and firing up, first the y value is $A0. And as it continues flying up the yvalue decreases to $94, then $8B, and finally it suddenly reaches $FD and is removed from the screen.
What could be done to debug this? This only happens when firing up. Please help me. Here is the code that uses cmp to test the screen boundaries (look and look2 etc are for debugging; that's the only way i know to debug, are there others? --- bullet_y is the current place the bullet is on the screen, y_portion is added each time to bullet_y):
Code: Select all
bullet0: lda bullettable+5 ;bullet_y_decimal
clc
adc bullettable+1 ;y_portion_decimal
sta bullettable+5 ;bullet_y_decimal
lda bullettable+4 ;bullet_y
adc bullettable+0 ;y_portion
sta bullettable+4 ;bullet_y
sta sprite+4
sta look3
cmp #240
bcc +
;eor #%11100000
;bne +
sta look2
lda #$55
sta look
lda bulletindex
and #%11111110
sta bulletindex
lda #0
sta sprite+4
sta sprite+7
jmp bullet1
* lda bullettable+7 ;bullet_x_decimal
clc
adc bullettable+3 ;x_portion_decimal
sta bullettable+7 ;bullet_x_decimal
lda bullettable+6 ;bullet_x
adc bullettable+2 ;x_portion
sta bullettable+6 ;bullet_x
sta sprite+7
sta look4
cmp #252
bcc bullet1
;eor #%11111100
;bne bullet1
lda bulletindex
and #%11111110
sta bulletindex
lda #0
sta sprite+4
sta sprite+7
bullet1: ...
Posted: Thu Nov 30, 2006 8:39 pm
by VanOccupanther
ok, i hope this is the question i should ask.
When shooting directly down, for the y-values, it reads:
48, 49, 4B, 4C, 4E (constant addition of $0180 (not including decimal part for these examples))
When shooting directly up, for the y-values, it reads:
92, 10, 8F, 0D, 8C (constant addition of $7E80)
The problem is here:
Code: Select all
sta bullettable+4 ;bullet_y
sta sprite+4
cmp #240
bcc +
Well, when firing up, part of the y values decreases to $0 (see the 10, 0D part up there? it fires the cmp then) causing the bullet to stop mid screen.
This only happens for all decreasing shooting (all up and all left)
How could i fix this ?
Posted: Thu Nov 30, 2006 9:57 pm
by tepples
VanOccupanther wrote:When shooting directly up, for the y-values, it reads:
92, 10, 8F, 0D, 8C (constant addition of $7E80)
Is there a reason that you're not constantly adding $FE80?
Posted: Mon Dec 04, 2006 6:07 pm
by VanOccupanther
Yes, Thank You, it should be FE80. But, the numbers, after multiplying, add up to 7E80. The multiply procedure works. So the code that figures out aa.bb * cc.dd could not be working. But, it only messes up when firing in a decreasing direction.
This one is really hard.
Posted: Tue Dec 05, 2006 8:10 am
by tepples
Perhaps the problem here is the difference between signed and unsigned multiplication. Is one of the factors an 8-bit number that you aren't properly sign-extending to 16-bit?
Posted: Thu Dec 07, 2006 7:40 pm
by VanOccupanther
When multiplying aa.bb by cc.dd, aa.bb is the spead variable and cc.dd is the value added to the y value each time. aa is 1, for now, so i dont have to worry about sign extending bb. But, cc might need to be signextended if cc is 0. So i added this code after (giving speed variable a value) and before (the rest of the calculate speed code):
Code: Select all
lda y_portion
bne skip_sign_extension
;sign extention
lda y_portion_decimal
and #%10000000
beq skip_sign_extension
lda #%11111111
sta y_portion
skip_sign_extension:
but it makes the ship fire weirdly sometimes and weirdly move other times. And it doesnt fix the pending problem. Is my thinking up there right?
Posted: Thu Dec 28, 2006 1:45 pm
by VanOccupanther
Just did a test while shooting up.
Code: Select all
FF.04 (a value for decrementing each time)
* 1.80 (movement speed)
-----------
17E.8600 (a new value for decrementing each time)
That's the answer that Windows Calculator gives. Well, it matches my programs answer.. 7E.86
So the multiplication is correct. And decrementing by 7E each time is normal (not FE, but decrementing by FE each time works, the bullet flys all the way up the screen. im not sure what to do about that
).
My sign extension code did not work/help, and after taking it out, one of the two problems went away. The other one is that the bullet stops mid screen when firing up. And the reason it does this is because decrementing by 7E each time (shooting up) gives values like:
Eventually the low part of the pattern reaches 00 quickly and causes the bullet to stop midscreen. When shooting down you get values like:
So everything seems to be correct. Do you have an idea of what to do to fix the bullet stopping midscreen?
Posted: Thu Dec 28, 2006 1:58 pm
by Quietust
If multiplying $FF.04 by $01.80 is giving you the answer $7E.86, then your code is not performing signed multiplication correctly - if you really want to handle signed multiplication properly, then what you should do is convert both input numbers to positive ($00.FC and $01.80), multiply them together (to get $01.7A), and then take the two's complement of the product* (to get $FE.86, the correct result).
* only if just one of the inputs was negative
The alternative is to sign extend the whole parts of each input to 16 bits - since the whole part of the output is 16 bits wide (and being truncated down to 8 bits), you must have at least that many valid bits in the whole part for each input. Considering how much more complicated this would make your multiplication routine, however, I'd advise just going with the "multiply as positive, then negate" route.
Posted: Sun Dec 31, 2006 6:10 pm
by VanOccupanther
THANK YOU SO MUCH!
