8x16 and whatever else unreg wants to know

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by Kasumi »

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 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: Select all

lda #$00
clc
sbc #$00
;Carry is clear

Code: Select all

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: Select all

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.
Last edited by Kasumi on Tue Jun 04, 2013 11:24 pm, edited 1 time in total.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

Kasumi wrote:
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.
When I added the +1 at the end... that +1 means levellength is a two byte variable. I don't know if I also knew that cameraposition/ladyposition would have to be two bytes to hold that large a number. You should know that levellength+1 could be used for your subtract 256... decrement levellength+1 by 1.

I appreciate your helpfullness :) ...and I'm sorry for using +1 to mean my variable is the high byte. :(
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 sprite is really a 16x32 pixel image?

Post by tepples »

To compare large numbers, try using cmp for the first and sbc for the rest.

Code: Select all

  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
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

Kasumi wrote:
...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.
Why does the state of the carry before the operation matter?
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.)

Code: Select all

lda #$00
clc
sbc #$00
;Carry is clear

Code: Select all

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.
Thank you for the correction! :D
Kasumi wrote:Edit:

Code: Select all

lda camerapositionlow
sec
sbc ladypositionlow
sta camerapositionlow

lda camerapositionhigh
sbc ladypositionhigh
sta camerapositionhigh
bcs abovezero
lda #$00
sta camerapositionhigh
sta camperapositionlow

abovezero:
Thought I understood this code. No I do not understand. :oops:

edit.
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by Kasumi »

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! :D 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.
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: Select all

lda #$00
sec
sbc #$00
;Result is #$00 with set carry.

Code: Select all

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.)
No I do not understand. :oops:
Edit: Because I don't think things through sometimes. It should be this: :oops:

Code: Select all

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 = levellength-256."
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: 8x16 sprite is really a 16x32 pixel image?

Post by thefox »

For more explanations about 16-bit comparisons, see http://www.6502.org/tutorials/compare_beyond.html
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

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! :D 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.
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? :)

I'm still confuzzled :? about:
Kasumi wrote:
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: Select all

lda #$00
sec
sbc #$00
;Result is #$00 with set carry.

Code: Select all

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.)
I can see what happens but my brain is missing the why. Lunch... (I'm going to come back to this... and honestly I am excited about learning about the carry and math. :) )

edit.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

Kasumi wrote:
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:
No I do not understand. :oops:
Edit: Because I don't think things through sometimes. It should be this: :oops:

Code: Select all

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.
Aw... you are very kind! :D :) Look forward to these posts. I appreciate your honesty and apology and I don't think you hurt more than help. :) : )
Kasumi wrote:Also, this does not include the "If cameraposition > levellength -256, cameraposition = levellength-256."
Thank you Kasumi! :D
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by Kasumi »

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: Select all

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*
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 ... elem-24639 (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: Select all

 00|FF (the | separates the two bytes into "places" like the one and tens place in the decimal addition example)
+00|01
------
 01|00
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: Select all

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: Select all

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.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

Kasumi wrote:
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: Select all

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*
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 ... elem-24639 (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: Select all

 00|FF (the | separates the two bytes into "places" like the one and tens place in the decimal addition example)
+00|01
------
 01|00
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: Select all

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: Select all

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.
Yes, I understand everything well; it is written very well. Great job Kasumi! Even your last code example... I was suprized you quoted your code... but suddenly I was happy to see those comments... it was a really cool experience! (: :)
THANK YOU KASUMI!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! :D
:D
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.
This is my favorite section of the forum too! :D

edit.
once more.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

Kasumi wrote:
No I do not understand. :oops:
Edit: Because I don't think things through sometimes. It should be this: :oops:

Code: Select all

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 = levellength-256."
Ok well I copied your code and wrote my questions:

Code: Select all

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. :oops:
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by Kasumi »

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.
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: Select all

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: Select all

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.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

Kasumi wrote:
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.
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: Select all

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: Select all

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. :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

Code: Select all

;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 > levellength-256
  lda cameraposition+1
  cmp levellength_high
  bcs +question3
  
    ;make cameraposition = levellength-256
	clc
	lda #$00
	sta CameraX+0
	lda levellength_high ;...is already set at levellength-256
	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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 sprite is really a 16x32 pixel image?

Post by tepples »

If the camera position has fallen below 0, then the high byte will have become 0xFF.
Post Reply