It is currently Wed Dec 19, 2018 3:27 am

 All times are UTC - 7 hours

 Page 67 of 97 [ 1452 posts ] Go to page Previous  1 ... 64, 65, 66, 67, 68, 69, 70 ... 97  Next
 Print view Previous topic | Next topic
Author Message
 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Tue Jun 04, 2013 12:06 pm

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1254
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
sta camerapositionlow

lda camerapositionhigh
sta camerapositionhigh
bcs abovezero
lda #\$00
sta camerapositionhigh
sta camperapositionlow

abovezero:

Edit: The above is totally wrong. See this post for a fix.

_________________
https://kasumi.itch.io/indivisible

Last edited by Kasumi on Tue Jun 04, 2013 11:24 pm, edited 1 time in total.

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Tue Jun 04, 2013 1:04 pm

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

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Tue Jun 04, 2013 1:48 pm

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20899
Location: NE Indiana, USA (NTSC)
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

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Tue Jun 04, 2013 2:07 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 940
Location: cypress, texas
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.
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:
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.
Thank you for the correction!

Kasumi wrote:
Edit:
Code:
lda camerapositionlow
sec
sta camerapositionlow

lda camerapositionhigh
sta camerapositionhigh
bcs abovezero
lda #\$00
sta camerapositionhigh
sta camperapositionlow

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

edit.

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Tue Jun 04, 2013 10:10 pm

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1254
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:
sec
sbc #128;#\$80
sta camerapositionlow

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."

_________________
https://kasumi.itch.io/indivisible

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Wed Jun 05, 2013 6:14 am

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3141
Location: Tampere, Finland
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

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Wed Jun 05, 2013 10:25 am

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

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.)
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.

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Wed Jun 05, 2013 2:11 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 940
Location: cypress, texas
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:
sec
sbc #128;#\$80
sta camerapositionlow

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! 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!

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Wed Jun 05, 2013 10:18 pm

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1254
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 ... 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:
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:
sec
lda #\$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 #\$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.

_________________
https://kasumi.itch.io/indivisible

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Thu Jun 06, 2013 5:58 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 940
Location: cypress, texas
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 ... 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:
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:
sec
lda #\$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 #\$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!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

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!

edit.
once more.

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Fri Jun 07, 2013 10:08 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 940
Location: cypress, texas
Kasumi wrote:
Quote:
No I do not understand.

Edit: Because I don't think things through sometimes. It should be this:

Code:
sec
sbc #128;#\$80
sta camerapositionlow

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:
sec
sbc #128;#\$80
sta camerapositionlow

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.

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Sat Jun 08, 2013 5:42 am

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1254
Quote:

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:
clc
sta camerapositionlow

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:
clc
sta camerapositionlow

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.

_________________
https://kasumi.itch.io/indivisible

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Sat Jun 08, 2013 11:45 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 940
Location: cypress, texas
Kasumi wrote:
Quote:

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:
clc
sta camerapositionlow

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:
clc
sta camerapositionlow

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.

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Fri Jun 14, 2013 3:08 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 940
Location: cypress, texas
Code:
;camera movement
;
;
;
;***********************

.enum  LocalVariables4mvement

t12 .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
lda oX+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

sec
sbc #128 ;cameraposition = ladyposition - 128.
sta CameraX+0

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.

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Fri Jun 14, 2013 3:17 pm

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20899
Location: NE Indiana, USA (NTSC)
If the camera position has fallen below 0, then the high byte will have become 0xFF.

Top

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 67 of 97 [ 1452 posts ] Go to page Previous  1 ... 64, 65, 66, 67, 68, 69, 70 ... 97  Next

 All times are UTC - 7 hours

#### Who is online

Users browsing this forum: No registered users and 2 guests

 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum

Search for:
 Jump to:  Select a forum ------------------ NES / Famicom    NESdev    NESemdev    NES Graphics    NES Music    Homebrew Projects       2018 NESdev Competition       2017 NESdev Competition       2016 NESdev Competition       2014 NESdev Competition       2011 NESdev Competition    Newbie Help Center    NES Hardware and Flash Equipment       Reproduction    NESdev International       FCdev       NESdev China       NESdev Middle East Other    General Stuff    Membler Industries    Other Retro Dev       SNESdev       GBDev    Test Forum Site Issues    phpBB Issues    Web Issues    nesdevWiki