Get ready for a long post
log in wrote:
My progress
I could not get the x check right.i had them both bcc and no mather what i tried i could not get them to work.
I said before they can't both be bcc. One has to be bcs, and the other must be bcc.
Here is a line with two points:
Code:
|
1 | 2
|
lda point1x
cmp linex
Would clear the carry.
lda point2x
cmp linex
would set the carry.
If you want to check if a point is to the left of another point, you have to do something different than checking if its to the right.
Quote:
I have not tested this code yet but on paper and in my head it works.
BUT ...here comes my QUESTION: if this is correct?
It is correct so far, but it will depend on if you fill in the "+ the other way around " parts with.
Quote:
And how do you handle left right top bottum of 1 sprite?
I wrote it up in my last post.
Code:
//If all the following conditions are true
ballx+ballwidth >= paddlex
ballx<= paddlex+paddlewidth
bally+ballheight >= paddley
bally<= paddley+paddleheight
There was a collision.
If any of them were false, the collision failed.
Figure out how to implement a check for each of those individually and you are done.
In any case if you do want to try it, here's a new starter document:
http://pastebin.com/50Q1K5U6I cut out basically everything from it, and also did things slightly different than bunnyboy. Here is a list of differences:
1. I didn't use the .rs command. I don't personally like it, but if you do you can use it.
2. Took out the background loading and replaced it with code that just writes tile 0 to every tile in the background.
3. Removed all the constants and code that was not filled in.
And the most important change: I made it so that the main game loop is not in the NMI.
Apologies if I explain anything you already know, but I am assuming nothing.
Code:
.org $FFFA ;first of the three vectors starts here
.dw NMI ;when an NMI happens (once per frame if enabled) the
;processor will jump to the label NMI:
.dw RESET ;when the processor first turns on or is reset, it will jump
;to the label RESET:
That code above sets your vectors. Each .dw here refers to an address that the CPU will go to when a specific thing happens.
The first is your NMI. If enabled, the label specified here (NMI in this case) will be jumped to every 60th of a second. Bunnyboy had it so that all of your game logic was here, but I believe this is bad form. What if the game takes longer than a 60th of a second to run?
In any case, the new code you write in my starter doc should be after the controller is read from, and before "JMP main".
Again, apologies if I am covering easy stuff.
Your first task is getting a sprite on screen. This code is underneath your NMI label:
Code:
LDA #$00
STA $2003 ; set the low byte (00) of the RAM address
LDA #$02
STA $4014 ; set the high byte (02) of the RAM address, start the transfer
You may recall that everything in your NMI routine is run every 60th of a second. What the code above does is copy all of the RAM in page 2 ($0200-$02FF) to the PPU's internal object memory.
What does this mean for you? That writing values to RAM anywhere from $0200-$02FF will update the sprites in the next 60th of second.
There are 64 sprites which each use four bytes to fill page 02 evenly.
Byte 0 is the sprite's y position. So writing #$10 to $0200 would set one of the 64 sprite's y position to #$10. Writing #$20 to $0204 would set the next sprite's y position to #$20. Etc.
Byte 1 is the sprite's tile. Whatever byte you write here is the tile graphic the sprite will use. $0201 refers to one sprite. $0205 refers to the next. etc.
Byte 2 ($0202, $0206 etc) is broken down like this:
Code:
Byte 2
Attributes
76543210
||||||||
||||||++- Palette (4 to 7) of sprite
|||+++--- Unimplemented
||+------ Priority (0: in front of background; 1: behind background)
|+------- Flip sprite horizontally
+-------- Flip sprite vertically
But you can just write #$00 there for now.
Byte 3 ($0203, $0207) is the sprite's X position.
So to display one sprite, all you have to do is write the tile you want to $0201, #$00 to $0202, and the X and Y position you to want to $0203, and $0200.
To add another sprite, you'd set the values you want to $0204-$0207. Just keep moving up four bytes to add more sprites.
If that's easy for you, the next step is to make your sprite move with d-pad presses. Start with just one direction.
Use one of the buttons variables (buttons1 or buttons2) to check if a button is pressed.
Each one contains the state of all 8 buttons, so you have to isolate the bit that you want.
Here is how they are laid out:
Code:
bit: 7 6 5 4 3 2 1 0
button: A B slct strt up down left right
So to do something if A was pressed...
Code:
lda buttons1
and #%10000000;This makes bits 6-0 equal to 0.
;So there are only two possibilities left. Either #%10000000 (if A was pressed) or
;#%00000000(if A was not pressed)
beq skip;If the button was not pressed, we do not want to do the action.
;Code dependent on A being pressed would go here
skip:
So to make the sprite move, you would make a check for all the dpad buttons. Then you would update the sprite's position ($0200 and $0203) when a button is pressed.
The next step is to add another sprite.
Then make that one controlled with the other controller.
The next step is collision detection.
Start with something simple. For instance, make it so that a new sprite appears near the top of the screen when just one of the collision checks is true. For instance, if this is true (sprite1x<= sprite2x+sprite2width ) the sprite will appear. If the sprite appears as you expect, add the next check. It should then appear only when both checks are true.
If you work by adding new code slowly like this, you will know what part of your code is wrong immediately.
Keep going until you have added all four checks.
If you have any questions on any part of this, let me know.