Collision detection problem with my project.
Moderator: Moderators
Re: Collision detection problem with my project.
Just remember NNyyyyyxxxxx, and you're good.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: Collision detection problem with my project.
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
Re: Collision detection problem with my project.
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.
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.
Re: Collision detection problem with my project.
Yes he should. He needs to change a tile. That requires an address.You shouldn't be converting sprite coordinates into NT addresses directly
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
Re: Collision detection problem with my project.
[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.
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.
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
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.
Re: Collision detection problem with my project.
Might you have put a checkmark in [ ] Disable BBCode next to Options: below that post?
Re: Collision detection problem with my project.
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.dougeff wrote:Yes he should. He needs to change a tile. That requires an address.
Re: Collision detection problem with my project.
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.
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.
Re: Collision detection problem with my project.
I'm reading! 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 .
Re: Collision detection problem with my project.
What's the best way to do the division in ASM 6052? I can't find any instructions, just ADC and SBC.
Re: Collision detection problem with my project.
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.
You want to keep divisions and multiplications to a minimum in 6502 programs, since they're pretty slow compared to addition and subtraction.
Re: Collision detection problem with my project.
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.
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.
Re: Collision detection problem with my project.
Yeah, I need to divide by 16 so I can do something like this: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.
Code: Select all
LSR A
LSR A
LSR A
LSR A ;Divide by 16
Re: Collision detection problem with my project.
Yes. You're getting the hang of it.