This is more than i can reasonably type out and demonstrate on a phone. If someone hasn't helped by the time i get off work in about 7 hours i can help with the basics. In the mean time look up how bounding boxes work with collision. Basically you'll want to update the x0, x1, y0, and y1 coordinates for both the ball and each paddle separately. Then check for the actual collision. Sorry i can't help more at the moment.

no need to apologize at all, i tried updating what I thought was the sprite before but then it just held onto a chunk of another sprite, ill try again and post
 

heres what I have now, still getting no result  

CheckPaddleCollision:
  
  LDA ballx
  CMP PADDLE1X
  BCC .End
  LDA bally
  CMP paddle1ytop
  BCC .End
  LDA bally
  CMP paddle2ybot
  BCS .End
  LDA #$00
  STA ballright
  LDA #$01
  STA ballleft    ;bounce, ball moving left
  .End:
    RTS

UpdateSprites:
LDA bally ;;update all ball sprite info
STA $0320
LDA #$12
STA $0321
LDA #$00
STA $0322
LDA ballx
STA $0323 ;end of ball sprite info

STA paddle1ytop
LDA $0300
LDA #$00
STA $0301
LDA #$00
STA $0302
LDA #PADDLE1X
STA $0303

STA paddle2ybot
LDA $0324
LDA #$31
STA $0325
LDA #$00
STA $0326
LDA #PADDLE2X
STA $0327

RTS

Here's a quick bounding box collision tutorial I worked up for PK in case anyone else needs it.

https://www.dropbox.com/s/en88bzm...

If anyone sees any issues let me know and I'll make the appropriate changes.

Thanks! I'll be refering to this for some tips.

Has anyone here attempted sprite movement in isometric view? I'm having an issues with sprites jumping across the screen with the Y coordinate. Basically, the equation to convert from Cartesian coordinates (2d top-down map) to Isometric (on screen coordinates) is IsoY = (CartX + CartY)/2. Whenever (CartX + CartY) sets the carry flag going up (CartY rolls over from $00 to $FF), you must use LSR to divide by 2 to drop the carry flag so your sprite doesn't jump to the bottom of the screen. Whenever (CartX + CartY) sets the carry flag going down, I have to do ROR to divide by 2 so that the IsoY coord is $80 and not $00 and jumps the sprite back to the top of the screen.

Anyone have any experience in the best way to tackle this problem?

I figured out my Isometric issue. Ignore.

So I am trying to condense my enemy parameters. Right now I have set aside space to have 4 enemies on screen at a time so I have varaibles for each enemy set aside and I control them by using an enemy_number:

enemy_number .rs 1
enemy_frame .rs 4
enemy_animation .rs 4
enemy_hp .rs 4
enemy_speed .rs 4

I need to set some of would like to hold these according to enemy type and would like some structure to hold values that would initialize by type. In one of MRN tutorials I saw him use .word to make a sort of data table for the background meta sprites. Can this be used for enemy types like:

enemyTypes:
    .word demon,flying_eye

demon:
    .db $02,$05,$06...

flying_eye:
    .db $04,$02,$05...

Where each value for the type is something I need. I think this would work but then how do I get these values? I am thinking I would have to have another variable like:

enemyType .rs 4
enemyType_ptr .rs 2

but how would you set this? If each .word is an address (IE demon = $0010 or something) would I have to do:

;set enemy type to flying_eye
LDX enemy_number
LDA $01
STA enemyType,x
;get to the enemy type values
LDA enemyType,x
TAX
LDA enemyTypes,x
STA enemyType_ptr
LDA enemyTypes+1,x
STA enemyType_ptr+1

It would seems that this routine would get me the address of the correct starting values (maybe) but now I am lost on how to get what I need. I am not sure if I am even doing this correct. Any advise would be greatly appreciated.

EDIT - reworded 

Use EnemyNumber to find the EnemyType and then get the data you need from the table. Then store it to useful variables or temporary ones to execute what you need. In my loading routines I have tables for Types, and then load those up before hand. These Types are used for movement, tile data, and other things.

LoadingTypeData:
  .db $00,$00,$01,$03

LoadTypeData:
  LDX #$00 ; X is going to be EnemyNumber
.LoadingLoop
  LDA EnemyNumber, X
  ASL A
  TAY
  LDA LoadingTypeData, Y
  STA PTR1
  INY
  LDA LoadingTypeData, Y
  STA PTR1+1

  LDY #$00
  LDA [PTR1], Y
  STA EnemyType, X      ; Store at one of your EnemyType variables that will be used for other things

  INX
  CPX #$04 ; Load your four enemies
  BNE .LoadingLoop
  RTS

Then in your main program you'd run what you need based on the Type variable. Hopefully that helps? I have gotten tripped up on it all before, having to store things at different places and all. I think what confused me was the step of pre-loading the data. You have to have the Type, but you need to load it before you need it. And, you only need to load it once if you do it with your room loading routines. I suppose you could find it every frame, but...  .

Again, hopefully that helps. It has been a while since I have gotten to write any code so it might be a bit off.

Thank you. I understand everything except for (as always) ASL and what it does. I'm still a bit new to this so I believe it stands for arithmetic shift left, and I believe it shifts each bit in the byte to the left. I just don't understand why we would do this here in your code.

Someone smarter than me can give the real reason, but ASL is what allows you access .dw tables. It multiplies your starting entry by two, and aligns things. That is also why .dw tables are capped out at 128 entries instead of 256 (i.e. half). MRN mysteriously mentions that in one of the tutorials, but it is something to keep in mind since if you need more than that you'll need tables of tables.

Thanks be to Metal Slime for understanding pointers, 16-bit addressing, and word tables in general, but I'll be darned if I can explain the technical stuff at the moment.

Haha fair enough. Thank you!

ASL is essentially like multiplying by 2. .dw tables are 2 bytes per entry instead of 1 byte because they are addresses, $8540. So, if you are going after entry 3, its actually the 6th byte, so you must multiply by 2.

.dw entry1, entry2, entry3 ; in label format

.dw $853E, $853F, $8540 ; what it looks like to the cpu

Be careful when mixing .dw and .db tables in the same routine, like it looks like you'll be doing. Only ASL the .dw ones, otherwise you'll end up skipping over the data you want. Many mistakes over the years!

Things like finding: MovementType (.dw) --> MovementDirection (.dw) --> MovementValue (.db). Tables within tables within tables...

When you're going into a pointer table you always have to do an ASL A because ASL is the same as multiplying by 2. Pointer tables are all 16-bit, since it's in essence a full address that you're basically skipping to. So multiplying the variable you load by 2 is preparing it to go to the correct 16-bit address.

edit: This is redundant after reading the previous posts. Sorry about that. I started posting and got sidetracked for a long time!

Just as a quick tip/alternative, if you want 256 addresses store two tables, one for the lo byte of each address, and one for the hi byte of each address. Then you don't need to asl, just ldx the index of the address (or other 16 bit value) that you want.

address1:
;whatever data you need
address2:
;whatever data you need
address3:
;whatever data you need

;Apologies if I got the nesasm syntax wrong. its either LO and HI or LOW and HIGH, I forget which
addresses_lo:
.db LOW(address1), LOW(address2), LOW(address3)

addresses_hi:
.db HIGH(address1), HIGH(address2), HIGH(address3)

;Variable is a 16 bit value in zp or ram
ldx #the_address_number_you_want
lda addresses_lo,x
sta variable
lda addresses_hi,x
sta variable+1

ldy #whatever_offset_you_need_From_that_address
lda [variable],y   ;I seem to recall nesasm using []

Now that is something I wouldn't have thought of. Im sure when I learn more about what I am doing and need 256 addresses (or even more than 128) I will definitely use this. Thanks for all of the responses guys!

Hi there !

I'm new to NES programming (and asm language), I followed the nerdy nights tutorials. To all the people involved into this forum and the tutorials, thank you very much !
Apart from that, I'm a developer and I did several games in C and JavaScript/HTML5, so I know general principles.

So, I use NESASM, and I was wondering : what is the correct way to display text on screen ? Should I use letters as sprites with all the alphabet ?
Otherwise I saw this trick and it confused me since I'm not used to asm : https://github.com/PeterLemon/NES...

Thank you !

Ypu can do them as bg tiles or sprites. Usually, if they are sprites its because there is special animation or just numbers for a score, like in Jackal. I normally use background tiles. When you get further along and look up using ram buffers to save on nmi time, this way you can write a good number of tiles to the bg.

Thank you for your quick response, it helps me, I'm gonna dig into bg tiles !

It's amazing how active is the NES dev community in 2018 

No problem! It is a nice little helpful community.

You only get 8 sprites per scanline, so sprites are rarely used for text except things like status bars in scrolling games. Some games will put the text on a diagonal to avoid the 8/line limit  

You're gonna love making your own fonts  

People make their own fonts?  
 

I have run into an issue and have an idea of how to deal with it but want to find out how other devs have tackled it. I have the need to capture an input string to perform a special player move. Think of it like throwing a fireball in street fighter 2 with ryu or ken. It isn't that many commands, I just want to do a double direction button push left or right.
I had the idea to record the previous button presses and then have a timer that the double push needs to be pressed within that time. Is this on the correct track? How would you guys go about accomplishing this?