nesdev.com https://forums.nesdev.com/ 

8x16 and whatever else unreg wants to know https://forums.nesdev.com/viewtopic.php?f=10&t=7451 
Page 67 of 97 
Author:  Kasumi [ Tue Jun 04, 2013 12:06 pm ] 
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image? 
Quote: levellength+1 is 4... so cameraposition would have to be big enough to reach 768... my logic doesn't work well right now. Where is levellength+1 even coming from? You've used it in both your posts, and I'm not seeing it. Also 4 (in the examples I gave) would mean your level is only 4 pixels wide. If you're saying that's the number of screens across your level is, your levellength (following my example) is really 4*256 (1024) pixels, and your cameraposition/ladyposition have to be two bytes to hold that large a number. Quote: ...I remember that cmp would work because it acts just like subtraction only it discards the answer... and that would be fine... the carry would still be cleared. No, you cannot use cmp for 16bit numbers (which you'll need for scrolling past more than one screen) because cmp also ignores the state of the carry before the operation. Edit: (Disclaimer: You can totally use cmp for 16 bit numbers with branches and such, but it's more work for probably no gain in this case.) Code: lda #$00 clc sbc #$00 ;Carry is clear Code: lda #$00 clc cmp #$00 ;Carry is set. This will affect the higher bytes of all subtractions greater than 8 bits, so you must use sbc. Edit: Code: lda camerapositionlow sec sbc ladypositionlow sta camerapositionlow lda camerapositionhigh sbc ladypositionhigh sta camerapositionhigh bcs abovezero lda #$00 sta camerapositionhigh sta camperapositionlow abovezero: Edit: The above is totally wrong. See this post for a fix. 
Author:  unregistered [ Tue Jun 04, 2013 1:04 pm ] 
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image? 
Kasumi wrote: Quote: levellength+1 is 4... so cameraposition would have to be big enough to reach 768... my logic doesn't work well right now. Where is levellength+1 even coming from? You've used it in both your posts, and I'm not seeing it. Also 4 (in the examples I gave) would mean your level is only 4 pixels wide. If you're saying that's the number of screens across your level is, your levellength (following my example) is really 4*256 (1024) pixels, and your cameraposition/ladyposition have to be two bytes to hold that large a number. I appreciate your helpfullness ...and I'm sorry for using +1 to mean my variable is the high byte. 
Author:  tepples [ Tue Jun 04, 2013 1:48 pm ] 
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image? 
To compare large numbers, try using cmp for the first and sbc for the rest. Code: lda this_lo
cmp that_lo ; set up carry for next sbc lda this_hi sbc that_hi ; right now, carry is set if and only if this >= that 
Author:  unregistered [ Tue Jun 04, 2013 2:07 pm ] 
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image? 
Kasumi wrote: Quote: ...I remember that cmp would work because it acts just like subtraction only it discards the answer... and that would be fine... the carry would still be cleared. No, you cannot use cmp for 16bit numbers (which you'll need for scrolling past more than one screen) because cmp also ignores the state of the carry before the operation. Kasumi wrote: Edit: (Disclaimer: You can totally use cmp for 16 bit numbers with branches and such, but it's more work for probably no gain in this case.) Thank you for the correction! Code: lda #$00 clc sbc #$00 ;Carry is clear Code: lda #$00 clc cmp #$00 ;Carry is set. This will affect the higher bytes of all subtractions greater than 8 bits, so you must use sbc. Kasumi wrote: Edit: Code: lda camerapositionlow sec sbc ladypositionlow sta camerapositionlow lda camerapositionhigh sbc ladypositionhigh sta camerapositionhigh bcs abovezero lda #$00 sta camerapositionhigh sta camperapositionlow abovezero: edit. 
Author:  Kasumi [ Tue Jun 04, 2013 10:10 pm ] 
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image? 
Quote: and I'm sorry for using +1 to mean my variable is the high byte. I was just interpreting it as an addition to a value rather than address. No need to be sorry. I just always only see things one way. tepples wrote: To compare large numbers, try using cmp for the first and sbc for the rest. YO!!!! That made my evening, I can use that in quite a few places! I concede, it's not more work to do that at all. Edit2: I really can't thank you enough. Off topic, but you caught me in the middle of rewriting some object collision/interaction stuff and I can now save a small amount of time in subroutines that will be run many times per frame. Quote: Why does the state of the carry before the operation matter? Because the sbc/adc (but not cmp) take the carry before the operation into account. Code: lda #$00 sec sbc #$00 ;Result is #$00 with set carry. Code: lda #$00 clc sbc #$00 ;Result is #$FF, with clear carry. And then the second subtraction of the 16 bit number needs to take the result of the carry from the first into account. (which cmp doesn't do.) Quote: No I do not understand. Edit: Because I don't think things through sometimes. It should be this: Code: lda ladypositionlow sec sbc #128;#$80 sta camerapositionlow lda ladypositionhigh sbc #$00;High byte of $0080 sta camerapositionhigh bcs abovezero lda #$00 sta camerapositionhigh sta camperapositionlow abovezero: ;Can be optimized in cute ways... ^_^ Which will make infinitely more sense, because what I posted before will not work at all. My logic here was sound, but what I wrote in 6502 wasn't that logic... Not thinking, not debugging, etc... I'm sorry. I kind of look forward to these posts, but then, sometimes... I hurt more than help. Also, this does not include the "If cameraposition > levellength 256, cameraposition = levellength256." 
Author:  thefox [ Wed Jun 05, 2013 6:14 am ] 
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image? 
For more explanations about 16bit comparisons, see http://www.6502.org/tutorials/compare_beyond.html 
Author:  unregistered [ Wed Jun 05, 2013 10:25 am ] 
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image? 
Kasumi wrote: tepples wrote: To compare large numbers, try using cmp for the first and sbc for the rest. YO!!!! That made my evening, I can use that in quite a few places! I concede, it's not more work to do that at all. Edit2: I really can't thank you enough. Off topic, but you caught me in the middle of rewriting some object collision/interaction stuff and I can now save a small amount of time in subroutines that will be run many times per frame. I'm still confuzzled about: Kasumi wrote: Quote: Why does the state of the carry before the operation matter? Because the sbc/adc (but not cmp) take the carry before the operation into account. Code: lda #$00 sec sbc #$00 ;Result is #$00 with set carry. Code: lda #$00 clc sbc #$00 ;Result is #$FF, with clear carry. And then the second subtraction of the 16 bit number needs to take the result of the carry from the first into account. (which cmp doesn't do.) edit. 
Author:  unregistered [ Wed Jun 05, 2013 2:11 pm ] 
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image? 
Kasumi wrote: Quote: and I'm sorry for using +1 to mean my variable is the high byte. I was just interpreting it as an addition to a value rather than address. No need to be sorry. I just always only see things one way. Kasumi wrote: Quote: No I do not understand. Edit: Because I don't think things through sometimes. It should be this: Code: lda ladypositionlow sec sbc #128;#$80 sta camerapositionlow lda ladypositionhigh sbc #$00;High byte of $0080 sta camerapositionhigh bcs abovezero lda #$00 sta camerapositionhigh sta camperapositionlow abovezero: ;Can be optimized in cute ways... ^_^ Which will make infinitely more sense, because what I posted before will not work at all. My logic here was sound, but what I wrote in 6502 wasn't that logic... Not thinking, not debugging, etc... I'm sorry. I kind of look forward to these posts, but then, sometimes... I hurt more than help. Kasumi wrote: Also, this does not include the "If cameraposition > levellength 256, cameraposition = levellength256." Thank you Kasumi!

Author:  Kasumi [ Wed Jun 05, 2013 10:18 pm ] 
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image? 
Quote: sbc is the same as cmp in cycles use... so after looking at tepples post again I'm guessing you save (don't require) an sec. Is that correct? This is correct. Although, sometimes you can avoid the sec anyway, even when using sbc. What matters is not that sec is used, just that the carry is set. Code: bcc somewhere ;If we're here, we didn't branch, so the carry is set. lda variable ;sec;Not needed right here, because we can guarantee the carry is already set sbc variable2; somewhere: Stuff like this is why it takes forever for me to write code. I think I like optimizing more than getting things working. *shrug* Quote: I can see what happens but my brain is missing the why I'm not sure I can explain that stuff better than the guides, but apparently I'm giving it a shot. Check the 6+5 = 11 on this poster: http://www.abcteach.com/documents/poste ... elem24639 (It's kiddy, but it actually shows what I want to show) The orange 1 is basically like the carry bit. For the tens place, it's adding 0+0. PLUS CARRY (1 in this case)! If you were adding 4+5, the tens place would add 0+0. PLUS CARRY (0, in that case! Because 4+5 doesn't carry to the tens place.) So when you add on the 6502 with adc, you are always adding the two numbers. PLUS CARRY! It just carries over to the next byte when it overflows, instead of the next place when you run out of digits. This is why you clear the carry before most additions. If you don't, you will add an extra one if the carry was set! Code: 00FF (the  separates the two bytes into "places" like the one and tens place in the decimal addition example) +0001  0100 You'll notice for the high bytes, you're doing 00+00, just like for the tens place in that example poster. But, like in the example poster, the addition of the lower place causes an overflow. FF+01 is greater than 255, so the carry ends up set. 5+6 is greater than 9, so you end up carrying one. Anytime you add a number and result would have been greater than the byte can hold, the carry is set. Otherwise it is cleared. For clarity: ADC will always set/clear the carry based on the result of the addition. See this code: Code: sec lda #$00 adc #$00 ;Carry is cleared. The carry is not "left alone" (In this case, it does not stay set) if there was no carryover. If there was no carryover, it is clear. If there was, it is set. Nothing else. This ensures that when you add the higher bytes (places) of the number, they get the correct result. This is why you DO NOT change the carry between operations that are part of the same multi byte add or subtract. The previous operations will make the carry right (whether there was a carry or not) and you don't have to worry about it to get the right result. Now... subtraction is a bit different. It subtracts the two numbers and the OPPOSITE of the carry. So when the carry is set (1), it will just subtract one number from the other. When the carry is clear (0), it will subtract one number from the other, AND an additional one. The way I used to remember it... If the carry is opposite what you would normally set it to before that operation, that's when you get the extra one. (You clear the carry before addition, so when it's set it adds one more. You set the carry before subtraction, so when it's clear, it subtracts one more.) Three things to take away: 1. The carry is ALWAYS taken into account when you use adc or sbc, so make sure it's right for the operation you intend to do before that operation runs. (Clear before addition, set before subtraction) 2. The carry will become the opposite of what you would normally initialize it to if the operation goes outside the boundaries of a byte. (So if an addition would have yielded more than 255, or a subtraction would have yielded less than 0.) Otherwise, the carry becomes what you would normally initialize it to. 3. If the carry is the opposite of what you would normally initialize it to, one extra will be used in the operation. (One extra will be subtracted for sbc, or one extra will be added for adc.) That's really all there is to it. The rest is the "why" behind it. With the knowledge, you can do fun stuff like this: Code: bcc somewhere ;The carry is set because we didn't branch ;We want to add eight to the accumulator ;clc;We could clear the carry ;adc #$08;And add 8. adc #$07;Or... we could add 7. Because we know the carry is set, and 7+1 is eight. But... don't do stuff like that in your game until you're really sure about it. If you understand it why it works, though, you've got a handle on the carry. I really do look forward to these posts. This is my favorite section of the forum, and I always feel bad when I mislead people. 
Author:  unregistered [ Thu Jun 06, 2013 5:58 pm ] 
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image? 
Kasumi wrote: Quote: sbc is the same as cmp in cycles use... so after looking at tepples post again I'm guessing you save (don't require) an sec. Is that correct? This is correct. Although, sometimes you can avoid the sec anyway, even when using sbc. What matters is not that sec is used, just that the carry is set. Code: bcc somewhere ;If we're here, we didn't branch, so the carry is set. lda variable ;sec;Not needed right here, because we can guarantee the carry is already set sbc variable2; somewhere: Stuff like this is why it takes forever for me to write code. I think I like optimizing more than getting things working. *shrug* Quote: I can see what happens but my brain is missing the why I'm not sure I can explain that stuff better than the guides, but apparently I'm giving it a shot. Check the 6+5 = 11 on this poster: http://www.abcteach.com/documents/poste ... elem24639 (It's kiddy, but it actually shows what I want to show) The orange 1 is basically like the carry bit. For the tens place, it's adding 0+0. PLUS CARRY (1 in this case)! If you were adding 4+5, the tens place would add 0+0. PLUS CARRY (0, in that case! Because 4+5 doesn't carry to the tens place.) So when you add on the 6502 with adc, you are always adding the two numbers. PLUS CARRY! It just carries over to the next byte when it overflows, instead of the next place when you run out of digits. This is why you clear the carry before most additions. If you don't, you will add an extra one if the carry was set! Code: 00FF (the  separates the two bytes into "places" like the one and tens place in the decimal addition example) +0001  0100 You'll notice for the high bytes, you're doing 00+00, just like for the tens place in that example poster. But, like in the example poster, the addition of the lower place causes an overflow. FF+01 is greater than 255, so the carry ends up set. 5+6 is greater than 9, so you end up carrying one. Anytime you add a number and result would have been greater than the byte can hold, the carry is set. Otherwise it is cleared. For clarity: ADC will always set/clear the carry based on the result of the addition. See this code: Code: sec lda #$00 adc #$00 ;Carry is cleared. The carry is not "left alone" (In this case, it does not stay set) if there was no carryover. If there was no carryover, it is clear. If there was, it is set. Nothing else. This ensures that when you add the higher bytes (places) of the number, they get the correct result. This is why you DO NOT change the carry between operations that are part of the same multi byte add or subtract. The previous operations will make the carry right (whether there was a carry or not) and you don't have to worry about it to get the right result. Now... subtraction is a bit different. It subtracts the two numbers and the OPPOSITE of the carry. So when the carry is set (1), it will just subtract one number from the other. When the carry is clear (0), it will subtract one number from the other, AND an additional one. The way I used to remember it... If the carry is opposite what you would normally set it to before that operation, that's when you get the extra one. (You clear the carry before addition, so when it's set it adds one more. You set the carry before subtraction, so when it's clear, it subtracts one more.) Three things to take away: 1. The carry is ALWAYS taken into account when you use adc or sbc, so make sure it's right for the operation you intend to do before that operation runs. (Clear before addition, set before subtraction) 2. The carry will become the opposite of what you would normally initialize it to if the operation goes outside the boundaries of a byte. (So if an addition would have yielded more than 255, or a subtraction would have yielded less than 0.) Otherwise, the carry becomes what you would normally initialize it to. 3. If the carry is the opposite of what you would normally initialize it to, one extra will be used in the operation. (One extra will be subtracted for sbc, or one extra will be added for adc.) That's really all there is to it. The rest is the "why" behind it. With the knowledge, you can do fun stuff like this: Code: bcc somewhere ;The carry is set because we didn't branch ;We want to add eight to the accumulator ;clc;We could clear the carry ;adc #$08;And add 8. adc #$07;Or... we could add 7. Because we know the carry is set, and 7+1 is eight. But... don't do stuff like that in your game until you're really sure about it. If you understand it why it works, though, you've got a handle on the carry. THANK YOU KASUMI!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Kasumi wrote: I really do look forward to these posts. This is my favorite section of the forum, and I always feel bad when I mislead people. edit. once more. 
Author:  unregistered [ Fri Jun 07, 2013 10:08 pm ] 
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image? 
Kasumi wrote: Quote: No I do not understand. Edit: Because I don't think things through sometimes. It should be this: Code: lda ladypositionlow sec sbc #128;#$80 sta camerapositionlow lda ladypositionhigh sbc #$00;High byte of $0080 sta camerapositionhigh bcs abovezero lda #$00 sta camerapositionhigh sta camperapositionlow abovezero: ;Can be optimized in cute ways... ^_^ So... this code is susposed to take care of cameraposition = ladyposition  128. and If cameraposition < 0, cameraposition = 0. because you ended with: Kasumi wrote: Also, this does not include the "If cameraposition > levellength 256, cameraposition = levellength256." Ok well I copied your code and wrote my questions: Code: lda ladypositionlow sec sbc #128;#$80 sta camerapositionlow lda ladypositionhigh ;why do you load ladypositionhigh here? sbc #$00;High byte of $0080 ;< what does this comment mean? sta camerapositionhigh bcs abovezero ;I understand this... it is going to a place where cameraposition > 0 lda #$00 ;I also understand these... cameraposition = 0 sta camerapositionhigh sta camperapositionlow abovezero: ;Can be optimized in cute ways... ^_^ edit: Well... I looked at this some more and want to say that I notice you aren't using sec before my first question line... so that 128 would be the low... and 00 would be the high... I still don't understand, I'm thinking... but Yes I dont understand. 
Author:  Kasumi [ Sat Jun 08, 2013 5:42 am ] 
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image? 
Quote: lda ladypositionhigh ;why do you load ladypositionhigh here? Because ladyposition is one number stored in two bytes. If you want to subtract a number from it, you have to subtract both bytes of that number from both bytes of ladyposition. If you don't also subtract from the high byte, it's going to end up wrong when the low byte wraps. This is 16 bit subtraction. Quote: sbc #$00;High byte of $0080 ;< what does this comment mean? We're subtracting 128. 128 is $80 if you use one byte. 128 is $0080 if you use two bytes. So the high byte for 128 is $00. To add 256, you'd do this: Code: lda ladypositionlow clc adc #$00 sta camerapositionlow lda ladypositionhigh adc #$01;High byte of $0100 (256) sta camerapositionhigh ;Well... for code clarity you'd do that, anyway. to add one, you'd do this: Code: lda ladypositionlow clc adc #$01 sta camerapositionlow lda ladypositionhigh adc #$00;High byte of $0001 sta camerapositionhigh Let's pretend ladyposition is $00FF or 255 (so ladypositionlow is #$FF and ladypositionhigh is #$00) in the above add one example. Use what you've learned about the carry to see how ladyposition gets to $0100 or 256. (so ladypositionlow is #$00 and ladypositionhigh is #$01). Does it make sense? Then see how it goes to $0101. The carry is what allows one byte to overflow into the next without branching. That's how you do 16bit math. I'm not prepared to write a huge post on it at the moment, though. 
Author:  unregistered [ Sat Jun 08, 2013 11:45 am ] 
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image? 
Kasumi wrote: Quote: lda ladypositionhigh ;why do you load ladypositionhigh here? Because ladyposition is one number stored in two bytes. If you want to subtract a number from it, you have to subtract both bytes of that number from both bytes of ladyposition. If you don't also subtract from the high byte, it's going to end up wrong when the low byte wraps. This is 16 bit subtraction. Quote: sbc #$00;High byte of $0080 ;< what does this comment mean? We're subtracting 128. 128 is $80 if you use one byte. 128 is $0080 if you use two bytes. So the high byte for 128 is $00. To add 256, you'd do this: Code: lda ladypositionlow clc adc #$00 sta camerapositionlow lda ladypositionhigh adc #$01;High byte of $0100 (256) sta camerapositionhigh ;Well... for code clarity you'd do that, anyway. to add one, you'd do this: Code: lda ladypositionlow clc adc #$01 sta camerapositionlow lda ladypositionhigh adc #$00;High byte of $0001 sta camerapositionhigh Let's pretend ladyposition is $00FF or 255 (so ladypositionlow is #$FF and ladypositionhigh is #$00) in the above add one example. Use what you've learned about the carry to see how ladyposition gets to $0100 or 256. (so ladypositionlow is #$00 and ladypositionhigh is #$01). Does it make sense? Then see how it goes to $0101. The carry is what allows one byte to overflow into the next without branching. That's how you do 16bit math. I'm not prepared to write a huge post on it at the moment, though. I am going to understand 16bit math; thank you for answering me. edit: Yes that makes sense. Now I must apply what I've learned. Give me a while to do this. It is 1:56pm n0ow. 
Author:  unregistered [ Fri Jun 14, 2013 3:08 pm ] 
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image? 
Code: ;camera movement ; ; ; ;*********************** .enum LocalVariables4mvement t12 .dsb 2 ladyposition .dsb 2 ;ladypositionlow .dsb 1 ;players position ;ladypositionhigh .dsb 1 ;players position cameraposition .dsb 2 ;camerapositionlow .dsb 1 ;camerapositionhigh .dsb 1 .ende camera_aim: ;determines how much to move based on the players position sta $ff ;set players position and cameraposition lda oX+0 sta ladyposition+0 lda oX+1 sta ladyposition+1 lda CameraX+0 sta cameraposition+0 lda CameraX+1 sta cameraposition+1 ;Is our players position is greater than half the screen lda ladyposition+0 ;players position bpl +question2 lda ladyposition+0 sec sbc #128 ;cameraposition = ladyposition  128. sta CameraX+0 lda ladyposition+1 sbc #$00 sta CameraX+1 +question2 ;Is cameraposition > levellength256 lda cameraposition+1 cmp levellength_high bcs +question3 ;make cameraposition = levellength256 clc lda #$00 sta CameraX+0 lda levellength_high ;...is already set at levellength256 sta CameraX+1 +question3 ;Is cameraposition < 0, lda CameraX+1 bpl +abovezero ;cameraposition = 0 lda #$00 sta CameraX+1 ;cameraposition+1 sta CameraX+0 ;cameraposition+0 jmp +end +abovezero: ;move camera +end rts ;end of camera_aim My code is above... how do I determine if cameraposition < 0? I noticed you branched if the carry was set right in the middle of the first question. I'm trying to deal with each question individually. 
Author:  tepples [ Fri Jun 14, 2013 3:17 pm ] 
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image? 
If the camera position has fallen below 0, then the high byte will have become 0xFF. 
Page 67 of 97  All times are UTC  7 hours 
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ 