[solved] two quick question about collision

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
ReverendSA
Posts: 36
Joined: Wed Mar 23, 2016 12:27 pm

[solved] two quick question about collision

Post by ReverendSA »

i have written collision in c# and c++ before, and it seemed to be an easy enough translation to asm 6502. here is my code below:

1. even though this works, is there a secret way that I am missing to do collision on nes? maybe shortcut? or do we always have to define bounding box? just curious

2. looking at code below, this would be a headache when accounting for multiple sprites. $0200 is the player sprite, and $0210 is the top left tile of a glass shard (see the image below). im not saying that i am discouraged but is this something you just have to deal with? a giant big mess of addresses? or is there a way to clean it up!? maybe give the $200 sprite an reference in english?!

Code: Select all

CheckCollide:
  LDA $0203 ; x1 
  CLC
  ADC #$10  ; x1 + w (16)
  CMP $0213 ; x2
  BMI Done
  LDA $0213 ; x2
  CLC
  ADC #$10  ; x2 + w (16)
  CMP $0203
  BMI Done
  LDA $0200 ; y1
  CLC
  ADC #$10  ; y1 + h (16)
  CMP $0210
  BMI Done
  LDA $0210 ; y2
  CLC
  ADC #$10  ; y2 + h (16)
  CMP $0200
  BMI Done
  INC $10
Done:
  RTS
Image
Last edited by ReverendSA on Sun Dec 08, 2019 11:05 pm, edited 1 time in total.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: two quick question about collision

Post by Pokun »

1.
You technically define the bounding box in your collision handling routine since that's what checks what pixels are colliding. So yeah you always define a bounding box in some way.

2.
The $0200 RAM page can be named oam_buffer or oam_shadow or something, and to access $0203 (sprite 0's x-position) for example you just use oam_buffer+3.

Also you might want to have some kind of metasprite system. Metasprites are also called objects (confusingly enough Nintendo uses the term "object" for the hardware sprites), and is what you refer to in your logic code. They don't have to be hardcoded into hardware sprite slots, you have a routine that runs every frame (as part of your logic, not in your rendering update) and translates your object data to OAM data and puts them in unused oam_buffer slots. You can also have it check how many sprites there is on a line and cycle them to make them blink to allow more than 8 sprites on a line (sometimes called sprite mutliplexing but that term also seems to have other meanings). Your object movement logic, collision logic etc never has to bother with oam_buffer slots, that's all taken care of in the object system. They only addresses these software objects. An object can also be made up of several hardware sprites. 1 parent sprite and 3 child sprites for 16x16 objects for example. The child sprites always have a position that is relative to the parent sprite (enforced by the object system routine), so only the parent needs to be moved by the movement logic code.

So your logic code may look something like this (for example):

Code: Select all

  jsr input_read             ;reads input devices (like the controllers) and saves their states in RAM
  jsr input_handler          ;checks player inputs and gives commands to player object to move
  jsr object_movement        ;moves objects according to physics, player input and enemy AI etc
  jsr object_collision       ;handles collisions and re-adjusts positions according to that
  jsr object_system_handler  ;looks for free sprite slots in $0200 and converts object data to OAM data
So your objects have their own format of data which the object_system_handler interprets and uses to build the OAM data in $0200.
ReverendSA
Posts: 36
Joined: Wed Mar 23, 2016 12:27 pm

Re: two quick question about collision

Post by ReverendSA »

Pokun wrote: Sun Dec 01, 2019 3:19 am 1.
You technically define the bounding box in your collision handling routine since that's what checks what pixels are colliding. So yeah you always define a bounding box in some way.

2.
The $0200 RAM page can be named oam_buffer or oam_shadow or something, and to access $0203 (sprite 0's x-position) for example you just use oam_buffer+3.

Also you might want to have some kind of metasprite system. Metasprites are also called objects (confusingly enough Nintendo uses the term "object" for the hardware sprites), and is what you refer to in your logic code. They don't have to be hardcoded into hardware sprite slots, you have a routine that runs every frame (as part of your logic, not in your rendering update) and translates your object data to OAM data and puts them in unused oam_buffer slots. You can also have it check how many sprites there is on a line and cycle them to make them blink to allow more than 8 sprites on a line (sometimes called sprite mutliplexing but that term also seems to have other meanings). Your object movement logic, collision logic etc never has to bother with oam_buffer slots, that's all taken care of in the object system. They only addresses these software objects. An object can also be made up of several hardware sprites. 1 parent sprite and 3 child sprites for 16x16 objects for example. The child sprites always have a position that is relative to the parent sprite (enforced by the object system routine), so only the parent needs to be moved by the movement logic code.

So your logic code may look something like this (for example):

Code: Select all

  jsr input_read             ;reads input devices (like the controllers) and saves their states in RAM
  jsr input_handler          ;checks player inputs and gives commands to player object to move
  jsr object_movement        ;moves objects according to physics, player input and enemy AI etc
  jsr object_collision       ;handles collisions and re-adjusts positions according to that
  jsr object_system_handler  ;looks for free sprite slots in $0200 and converts object data to OAM data
So your objects have their own format of data which the object_system_handler interprets and uses to build the OAM data in $0200.
ty for the info I will read into the bolded area.
ive started to label addresses in RAM and use loops and its making everything a lot cleaner (and easier). i can now add 6 glass shards from 2 and have collision with all of them effortlessly
Post Reply