Collision detection problem with my project.

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

User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Collision detection problem with my project.

Post by Dwedit »

Just remember NNyyyyyxxxxx, and you're good.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Collision detection problem with my project.

Post by dougeff »

And you might have to add 1 or 2 to the sprite's y before converting to nametable address, to get it to visually line up. Otherwise the block might disappear when the Sprite is still 1 pixel away.
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Collision detection problem with my project.

Post by tokumaru »

You shouldn't be converting sprite coordinates into NT addresses directly, though... The "correct" thing to do would be to run the game logic in "game world space", a space that contains all your game objects and doesn't care about sprite evaluation delays or scrolling, and convert coordinatrs from that space into sprite space or NT addresses when needed.

Some simpler games (single screen without scrolling) do end up unifying all these spaces to simplify things, and will even set the scroll to -1 (i.e. 239 or 255) to push the background 1 pixel down so it'll align with sprite coordinates, eliminating the need to compensate for that 1 scanline delay that sprites have.
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Collision detection problem with my project.

Post by dougeff »

You shouldn't be converting sprite coordinates into NT addresses directly
Yes he should. He needs to change a tile. That requires an address.

EDIT, and I always forget about setting Y scroll to -1. I remember that Shiru's example game Chase sets the X scroll to 4 (on a transition screen) so that text is exactly lined up to the middle of the screen. Another thing I frequently forget is possible.
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
Sogona
Posts: 186
Joined: Thu Jul 23, 2015 7:54 pm
Location: USA
Contact:

Re: Collision detection problem with my project.

Post by Sogona »

[quote="dougeff”]Yes he should. He needs to change a tile. That requires an address.[/quote]
You wanna treat the ball as an object with a hitbox though; not as a sprite.

A full-fledged metasprite system probably isn’t necessary for this game. Kikutano, you could probably get by with just having variables for the ball’s X and Y, as well as the X and Y for the hitbox. In the ball’s code you’d just update both one after the other. This way you can check for collisions on all the corners. Then after the ball’s done running, you can have a simple routine that just stores the ball’s X and Y coordinates into the OAM shadow. You can even subtract 1 from the ball’s Y position to fix the scanline offset problem people were talking about.

Code: Select all

DrawBall:
  lda ball_x
  sta $0203
  lda ball_y
  sec
  sbc #1   ;account for the 1 scanline delay for sprite rendering
  sta $0200
  rts
Directly working with OAM like this is bad practice for an actual game, but at the same time it’s good practice to separate “object code” from “drawing code”.

Edit: BBcode isnt working for some reason. Maybe it’s something I did.
Last edited by Sogona on Thu Jun 07, 2018 2:32 pm, edited 2 times in total.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Collision detection problem with my project.

Post by tepples »

Might you have put a checkmark in [ ] Disable BBCode next to Options: below that post?
User avatar
Sogona
Posts: 186
Joined: Thu Jul 23, 2015 7:54 pm
Location: USA
Contact:

Re: Collision detection problem with my project.

Post by Sogona »

Maybe :wink:
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Collision detection problem with my project.

Post by tokumaru »

dougeff wrote:Yes he should. He needs to change a tile. That requires an address.
What I meant is that, ideally, he shouldn't be converting sprite coordinates in order to get that address. Positions, collisions, etc. should normally be processed in world space, and that's what you'd convert to other spaces (sprite, NT) as necessary.
User avatar
Punch
Posts: 365
Joined: Sat Feb 16, 2013 11:52 am

Re: Collision detection problem with my project.

Post by Punch »

Coordinate space translation reminds me a lot of working with OpenGL shaders.

Anyway, for a single screen game like his, the translation matrix from world to screen space is simply [{1,0,0},{0,1,-1},{0,0,1}], ie. simply decreasing the Y coordinates of all sprites by 1 when writing the OAM table should be fine. The only relevant coord translation he should be doing right now is playfield space to/from screen space, unless he plans to add multi-screen playfields to the game which would be something incredibly stupid for Arkanoid.

I know you guys like to go deep into discussing things and this is mostly a strength of this forum, but right now discussing metasprite systems, world coordinates, etc. will only confuse him in a simple game concept which only needs basic collision detection and video RAM writes.
This is a block of text that can be added to posts you make. There is a 255 character limit.
User avatar
kikutano
Posts: 115
Joined: Sat May 26, 2018 6:14 am
Location: Italy

Re: Collision detection problem with my project.

Post by kikutano »

I'm reading! :mrgreen: I hope to implement the collision detection with the background this weekend and I will update you. Thanks for all suggests! :) I will release the source code on Github when I finish the project. Now I'm reading the code from BrickBreaker to steal some idea :).
User avatar
kikutano
Posts: 115
Joined: Sat May 26, 2018 6:14 am
Location: Italy

Re: Collision detection problem with my project.

Post by kikutano »

What's the best way to do the division in ASM 6052? I can't find any instructions, just ADC and SBC.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Collision detection problem with my project.

Post by tokumaru »

You have to code division routines yourself, the 6502 doesn't know how to do divisions or multiplications. Here's a page with tons of math routines: http://codebase64.org/doku.php?id=base:6502_6510_maths

You want to keep divisions and multiplications to a minimum in 6502 programs, since they're pretty slow compared to addition and subtraction.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Collision detection problem with my project.

Post by tepples »

There are 8x8 bit multiplication and 0.8/0.8 bit division routines in math.s of Thwaite. This is targeted mostly at calculating slopes as part of an arctangent routine.

There are 16x16 bit multiplication and 32/16 bit division routines in muldiv.s of 240p Test Suite, used in the Overclock activity.

There are various multiplication and divisions in the hardware-independent portion of cc65's runtime library.

But for collision with elements of a matrix whose sizes are powers of 2, such as translating pixel positions into which brick was hit in a Breakout clone, you'll probably need only division by powers of 2. To divide A by 2, use the LSR A instruction, which is much faster than the above generic dividers. To divide by larger powers of 2, use more shifts. To divide by 4, shift twice; by 8, thrice; and so on.
User avatar
kikutano
Posts: 115
Joined: Sat May 26, 2018 6:14 am
Location: Italy

Re: Collision detection problem with my project.

Post by kikutano »

tepples wrote:There are 8x8 bit multiplication and 0.8/0.8 bit division routines in math.s of Thwaite. This is targeted mostly at calculating slopes as part of an arctangent routine.

There are 16x16 bit multiplication and 32/16 bit division routines in muldiv.s of 240p Test Suite, used in the Overclock activity.

There are various multiplication and divisions in the hardware-independent portion of cc65's runtime library.

But for collision with elements of a matrix whose sizes are powers of 2, such as translating pixel positions into which brick was hit in a Breakout clone, you'll probably need only division by powers of 2. To divide A by 2, use the LSR A instruction, which is much faster than the above generic dividers. To divide by larger powers of 2, use more shifts. To divide by 4, shift twice; by 8, thrice; and so on.
Yeah, I need to divide by 16 so I can do something like this:

Code: Select all


  LSR A
	LSR A
	LSR A
	LSR A ;Divide by 16

tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Collision detection problem with my project.

Post by tepples »

Yes. You're getting the hang of it.
Post Reply