make sense like a cut scene where the sprite is present but you don't want them moving around and such. but in the tutorials so far there hasn't been a comment that says "; variable"
so I assume that " controller1: " would be a variable? and the information contained under it would be it's parameters?

No, it's just the memory where it's stored at when it reads the controller. A lot of programs that people do just read the controller and then move, but if it's not one right ofter the other, it's probably better, haha.

so then how would you put the controller functions into a variable?

Overly complicated tutorials is a common mistake. By trying to teach everything exactly right the first time the reader will be overloaded and far more likely to fail. Keeping it simple on purpose, then adding more detail in future lessons keeps the progress moving forward. Ignore variables until they are brought up in week 7.

Oh ok, I'll do just that then. Currently I've got the back of Mario's head working on the x and y axis and can move it in 8 directions. No I've just got to get all 4 sprites moving in tangent.

The variable is already there, it's whatever it rotates the values into. If you aren't using variables, how else do you remember the sprites X and Y coordinates?

By going back and looking at the code to see in which memory address they were put into???...

but right now I'm having the hardest time getting all four sprites to move together. I saw resynthesize's code and it somewhat makes sense to me but not entirely. I can get it to work left and right but up and down does some freaky stuff. I figured that my replacing the x's with y's and where the sprite address started it would just kick over and work

ReadUp: ;Player 1 D-Pad UP
LDA $4016 ; controller port 1 IRQ
AND #%00000001 ; AND IRQ byte
BEQ ReadUpDone ; Branch EQuals to ReadUpDone if Up was NOT pressed
;button is pressed

ldY #$00 ; y position of sprite starts at $0203

moveloopUp:
lda $0203, y ; load sprite y position ($2000 + y)
clc ; make sure the carry flag is clear
SBC #$02 ; A = A + 1
sta $0203, y ; save sprite y position
iny ; increment y 4 times to get to next sprite
iny ; y position
iny
iny
cpY #$13 ; if x = $13 (HEX), all 4 sprites have been moved
bne moveloopUp ; otherwise keep going.

ReadUpDone:

vs his

ldx #$03 ; x position of sprite starts at $0203

moveloop:
lda $2000, x ; load sprite X position ($2000 + x)
clc ; make sure the carry flag is clear
adc #$02 ; A = A + 1
sta $2000, x ; save sprite X position
inx ; increment X 4 times to get to next sprite
inx ; x position
inx
inx
cpx #$0F ; if x = $0f, all 4 sprites have been moved
bne moveloop ; otherwise keep going.

Mailed, I'll help you there.

Alright, So I came back to this and finally managed to get all the sprites moving together But now I've come to another problem. they seem to move at different speeds in different direction. Up goes nice and slow, left goes the same speed. however Down and right go faster. I assume it has to deal with the Y and X coordinate getting   loaded first for Up and Left, then for Down and right it doubles it in some respect.

I have the flag CLC'ed for each sprite on each direction then SEC'ed for each one in each direction. (At first I thought it was because the flag was carrying the math and at first it helped with one of the direction when 3 of them were moving fast and Up was the only one that was slow) and it may be a Flag issue but I'm just not sure

any suggestions?

P.S. I'm also working on the Background as part of this piece and I'm not quite finished with it so a lot of 2's will show up when complied.

You only need SEC with SBC and CLC with ADC. Not both SEC and CLC.

You're clearing the carry flag and setting the carry flag. Try that and see if it works.

Yup, that Did it. thanks MRM!

but why do you only use one for one not the other?

[EDIT]

let me rephrase, why do you only use SEC with SBC and CLC with ADC? what makes the difference?

Sorry to bump a rather old thread but...

How do I get the sprite to:

A. Move faster. (Doesn't necessarily need to be variable, but I may be doing it wrong or there may be a better way. Code only changed for Dpad_Right)
B. Move more smoothly.
C. Move more accurately to the button press.

Thanks.

A. Change $01 to however fast you want it to move. As you get more advanced, you'll figure out the whole "meta sprite" deal.  It works easier.

B. I assume that this is in reference to the "$08" you put in there.  That means that you move 8 pixels per frame.  You need to slow down if you don't want it to jump around.

C.  I don't know, but I suspect that if you used a more advanced controller reading method, it would work better.  Like MetalSlime uses. 

A/B:  You'll use what is known as fixed-point addition (also using it like this it's often called "sub-pixel precision".  That just means there is a decimal point, and it's fixed to a certain position.    The easy way is to make your speed use 2 bytes, instead of adding #1 per pixel to your sprite position, you do a 16-bit add and use the upper 8 bits as the actual sprite position (so your sprite position must be 16-bit as well, with the lower 8-bits as it's own variable, completely separate from NES sprite-memory).  So the "decimal point" is between those 2 bytes, giving you 256 fractional speeds (and by preserving the lower 8 bits of the sprite position, you'll have 256 fractional positions within each pixel on the screen).  That allows for really smooth movement, and all kinds of different speed possibilities.  Also makes it easy to adjust for NTSC/PAL differences.

^^ think the "ticker" in metalslimes sound tutorials.

Is this an acceptable way to make sprites move slower than 1 pixel per Vblank:

; Just before JMP Forever I cleared the X register.
ReadA:
LDA $4016 ; player 1 - A
AND #%00000001 ; only look at bit 0
BEQ ReadADone ; branch to ReadADone if button is NOT pressed (0)
; add instructions here to do something when button IS pressed (1)
INX ; if a press is registered for 3 Vblanks then translate the sprite.
CPX #$03
BNE ReadADone
LDX #$00 ; Once it has been moved reset the Vblank counter.
LDA $0203 ; load sprite X position
CLC ; make sure the carry flag is clear
ADC #$01 ; A = A + 3 (changed to 3)
STA $0203 ; save sprite X position (sprite moves 1 unit right).
ReadADone: ; handling this button is done

I've tried it and it works, just wondering if it's the right way to go about it.

It looks like a workaround. I don't see anything wrong with it up front though I can see that if you really wanted something to drag, like moving through mud, it could use up precious processor time. I think what Memblers is suggesting three posts above is worth looking into.

Basically what Memblers is saying is this:

LDA PartialVariable
CLC
ADC #$80 ;any speed here.
STA PartialVariable
LDA $0200
ADC #$00 ;any speed here. (usually #00 or #01 unless your stuff is moving super fast)
STA $0200

You have control over two addresses now, with this way giving you a ton more speed options. The downside to this is you have to have a partialvariable for every sprite you want more control over.

Thanks for the replies guys. But I don't exactly follow where the sprites postion ($0200) is being updated though, following memory:

A = PartialVariable
A = PartialVariable+$80
PartialVariable = A (so partialVariable is being updated each time).
A = $0200 (same x-position each time? PartialVariable isn't being to offset number stored in $0200?)
A = $0200
$0200 = A

I think it has to do with the carry flag. Someone with better knowledge should reply. I just know it works.

alright, so I'm back at the NN tutorials after a year of hiatus. Sadly most of my saved stuff from back then is gone so I've started over. a lot of things make WAY more sense this time around but I have a question. why does this
ReadUp:
LDA $4016 ; player 1 - Up
AND #%00000001
BEQ ReadUpDone
LDA $0203 ; load sprite 1 position
SEC ; make sure carry flag is set
SBC #$01 ; A = A - 1
STA $0203 ; save sprite 1 position
LDA $0207 ; load sprite 2 position
SEC ; make sure carry flag is set
SBC #$01 ; A = A - 1
STA $0207 ; save sprite 2 position
LDA $020B ; load sprite 3 position
SEC ; make sure carry flag is set
SBC #$01 ; A = A - 1
STA $020B ; save sprite 3 position
LDA $020F ; load sprite 4 position
SEC ; make sure carry flag is set
SBC #$01 ; A = A - 1
STA $020F ; save sprite 4 position
ReadUpDone:


move it horizontally while this

ReadUp:
LDA $4016 ; player 1 - Up
AND #%00000001
BEQ ReadUpDone
LDA $0200 ; load sprite 1 position
SEC ; make sure carry flag is set
SBC #$01 ; A = A - 1
STA $0200 ; save sprite 1 position
LDA $0204 ; load sprite 2 position
SEC ; make sure carry flag is set
SBC #$01 ; A = A - 1
STA $0204 ; save sprite 2 position
LDA $0208 ; load sprite 3 position
SEC ; make sure carry flag is set
SBC #$01 ; A = A - 1
STA $0208 ; save sprite 3 position
LDA $020C ; load sprite 4 position
SEC ; make sure carry flag is set
SBC #$01 ; A = A - 1
STA $020C ; save sprite 4 position
ReadUpDone:

moves it vertically?

I'm not sure what you're doing, but that's a terrible way of reading the controller. Just realize the right way to do it is to get all the data in one byte then do your bit masks with it, not straight off of $4016 like it is doing.

But the reason it moves it different ways is because each of the 64 OAM data values goes $200=Y location,$201=Tile,$202=Sprite Attribute,$204=X location.

yes yes I know, we talked about that last year. lol but I'm just going through the tutorials as they are. You sent me a ton of PMs helping me but going back over them my mind decided to freeze. For right now I just want to know why there's a difference in the movement.

---EDIT--

i didn't realize that you had answered my question in that response. thank you.

You can only have one value in a register at a time.
So your way, you add 1 to the value in $020F.