8x16 and whatever else unreg wants to know

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by Kasumi »

This does make sense, however on my screen it is kind of different. The camera doesn't center on the character... it still scrolls when she is past $80 and she eventually reaches the edge of the screen and appears on the other side.
Is this what you're seeing with the current code? Or is this what you want to have happen? It's true I can't account for her appearing on the other side, but that seems a lot like the image to me. My animation still moves when she's past $80, but it stops at $0100-$017F which is the problem I'm describing. I'm assuming this where she appears on the other side of the screen for you. Maybe the behavior is different, but the source of the problem is almost definitely the same.

I guess the bottom line is: Anyway I look at it $80 can't always be the middle of the screen. This is because if the camera moves, the middle of the screen moves with it. So you can't do a check for the being left of the screen just by checking the low byte of the position. You need to use both.

That's what I did in the code here.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

Kasumi wrote:
This does make sense, however on my screen it is kind of different. The camera doesn't center on the character... it still scrolls when she is past $80 and she eventually reaches the edge of the screen and appears on the other side.
Is this what you're seeing with the current code?
Yes
Kasumi wrote:It's true I can't account for her appearing on the other side, but that seems a lot like the image to me. My animation still moves when she's past $80, but it stops at $0100-$017F which is the problem I'm describing. I'm assuming this where she appears on the other side of the screen for you. Maybe the behavior is different, but the source of the problem is almost definitely the same.

I guess the bottom line is: Anyway I look at it $80 can't always be the middle of the screen. This is because if the camera moves, the middle of the screen moves with it. So you can't do a check for the being left of the screen just by checking the low byte of the position. You need to use both.
I happily agree! :) Thank you this message got through to me! :D Have to think about this for a bit. Thanks Kasumi for your efforts to get me to understand this!
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

How can I check if our lady's position is greater than half the screen. It's confusing because her position can be positive or negative when it's greater thabn half the screen. :?

edit: I just tried bcc and bcs and neither one is satisfing. :?

edit2: BNE and BVC are both better... the screen is slower scrolling but all the columns are drawn... incorrectly but they are drawn.
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by 3gengames »

This is where you forget signed numbers exist. If you CMP #$(Number) with unsigned numbers, if it's above that number or equal, it'll be BCS. If it's lower, it'll be BCC.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

Thanks 3gengames! :) But, I'm still confused :? because why should I subtract #128 when the number will be higher and lower? There must be something I don't understand... :?
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by 3gengames »

I think the best way to think of it as two planes. Yes, you sorta have to use the sprite position to move in the map and make sure it doesn't go past the boundary, but once it hits that line, just move the map forward and keep here there. It's hard to explain because I've thought this out thoroughly and made the decision it'd have to be highly integrated with my camera system, but...I dunno, just look at it. Look at the variables you have that show the position of the person, the map, and the camera, and figure out which you can use to solve the problem. :)
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by Kasumi »

unregistered wrote:Thanks 3gengames! :) But, I'm still confused :? because why should I subtract #128 when the number will be higher and lower? There must be something I don't understand... :?
You just fix it when it's lower, and don't when it's not.

Think about it this way: To check if it's lower before you do the actual subtract, you STILL have to do a compare (subtract). So why do it before? Do the subtract regardless, and fix the result only if it needs it. (The carry will tell you if it needs fixing!)


Read this:
Three things to take away:
1. The carry is ALWAYS taken into account when you use adc or sbc, so make sure it's right for the operation you intend to do before that operation runs. (Clear before addition, set before subtraction)
2. The carry will become the opposite of what you would normally initialize it to if the operation goes outside the boundaries of a byte. (So if an addition would have yielded more than 255, or a subtraction would have yielded less than 0.) Otherwise, the carry becomes what you would normally initialize it to.
3. If the carry is the opposite of what you would normally initialize it to, one extra will be used in the operation. (One extra will be subtracted for sbc, or one extra will be added for adc.)
If that's not enough explanation, try the whole post it's from again: viewtopic.php?p=112830#p112830

Then see how this works:

Code: Select all

lda ladypositionlow
sec
sbc #128;#$80
sta camerapositionlow

lda ladypositionhigh
sbc #$00;High byte of $0080
sta camerapositionhigh
bcs abovezero
lda #$00
sta camerapositionhigh
sta camperapositionlow

abovezero:
;Can be optimized in cute ways... ^_^
I mean... I probably shouldn't encourage you to lift it without understanding, but this working code has been available to study.

What is the state of the carry when ladyposition is < 128 and you subtract 128 from it? What is the state of the carry when ladyposition is > 128 and you subtract 128 from it? In which case do you want to discard the result and use zero? Then branch passed the fix on the opposite state of the carry.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

Code: Select all

camera_aim:

  
  
  ;determines how much to move based on the players position
  sta $ff
  
  ;set players position and cameraposition
  lda oX+0
  sta ladyposition+0
  lda oX+1
  sta ladyposition+1
;  lda CameraX+0
;  sta cameraposition+0
;  lda CameraX+1
;  sta cameraposition+1 
  
  
  ;First set cameraposition = ladyposition - 128
  
  lda ladyposition+0
  sec
  sbc #128 ;cameraposition = ladyposition - 128.
  sta CameraX+0 
  
  lda ladyposition+1
  sbc #$00
  sta CameraX+1
  

+question1 ;branch is now CORRECT!

  ;Is cameraposition > levellength-256
  lda CameraX+1 ;was lda cameraposition+1
  cmp levellength_high
  bmi +question2
  
    ;make cameraposition = levellength-256
	lda #$00
	sta CameraX+0
	lda levellength_high ;...is already set at levellength-256
	sta CameraX+1
	
	jmp +end
    
+question2  
  
  ;Is cameraposition < 0,
  lda CameraX+1
  bpl +abovezero
      
	;cameraposition = 0
	lda #$00
    sta CameraX+1 ;cameraposition+1
    sta CameraX+0 ;cameraposition+0
    jmp +end
  
+abovezero: 

    ;move camera
    ;lda t12+0
    ;sta CameraX+0
    ;lda t12+1
    ;sta CameraX+1
  
+end  rts ;end of camera_aim
Is that perfect? Wait!! No! There isn't any thing to do with the carry. =( I just figured out that there are only 2 questions asked after you set cameraposition = playerposition - 128. So yall have been so helpful thank you 3gengames and Kasumi!! :D

edit.

edit2: Well sorry guys... I just spent a long time changing the code to how it is now above. My brain is gone... I have to wait till tomorrow... or Monday. I'm hoping that my code up there works really well aside from the fact that it doesn't do anything with the carry. I would really like to know if my code is good. Good night yall. :)

edit3.
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by Kasumi »

Is that perfect? Wait!! No! There isn't any thing to do with the carry. =(
You don't NEED to use the carry here (the one issue would be levels $80 screens long or longer), but you should definitely take steps to understand it fully because it will probably come up again.

What you have looks like it will work.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

Kasumi wrote:you should definitely take steps to understand the carry fully because it will probably come up again.
Ok I will.
Kasumi wrote:What you have looks like it will work.
THANK YOU KASUMI!!! :D

edit.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

Kasumi wrote:What is the state of the carry when ladyposition is < 128 and you subtract 128 from it?
The carry is set for subtraction but it changes to clear because the answer is negative.
Kasumi wrote:What is the state of the carry when ladyposition is > 128 and you subtract 128 from it?
The carry is set for subtraction and it stays set because the answer is positive.
Kasumi wrote:In which case do you want to discard the result and use zero?
The first one. :)
Kasumi wrote:Then branch passed the fix on the opposite state of the carry.
So... bcc? :? (I dont understand.) edit: Well maybe I do understand! :)

Code: Select all

bcs notfixed
;the fix part: change answer to 0

notfixed:
 
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by Kasumi »

I think you got it.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

Kasumi wrote:I think you got it.
YEAY!! :D Thank you.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

tepples[color=#40BFFF], on page 59,[/color] wrote:Sort of. The "p1 is pressing right on dpad" controls the location of a character in the game world, and a camera data structure follows the location of this character. When the camera moves, you draw the metatiles onto which the camera is moving.
So, I'm confused, do I have to keep track of which metatiles have been drawn already? :?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 sprite is really a 16x32 pixel image?

Post by tepples »

Let's assume that your map is structured as columns of metatiles, and each column is 16 pixels (2 tiles, 1 color area) wide, and your PCB arranges nametables horizontally, resulting in vertical mirroring. There is enough video memory to keep 32 columns of metatiles valid. The NES picture is 256 pixels wide, meaning that 17 columns will be fully or partly visible.

You manage updates using two variables:
  • visible_left, the left side (in columns) of the area. Normally, this will be about 8 columns to the left of the player. A camera system giving more room in front of the player than behind might cause it to be 5 to 11 columns in front.
  • valid_left, which your scrolling code updates as it draws columns to the nametables.
What you want to do is make sure that the interval visible_left through visible_left + 16 is contained within valid_left through valid_left + 31. Here's the logic:
  • At the start of the level, before turning on rendering, draw all columns from valid_left through valid_left + 31.
  • If visible_left becomes less than valid_left, column valid_left - 1 is coming into view. Decrease valid_left by 1 and draw column valid_left.
  • If visible_left becomes greater than valid_left + 15, column valid_left + 32 is coming into view. Increase valid_left by 1 and draw column valid_left + 31.
  • Clamp the camera X position to valid_left * 16 through valid_left * 16 + 256 so that the camera falls behind instead of glitching if the worst happens.
But each byte in the attribute table spans two columns. Depending on how you organize the map data, you may have to either draw two columns at once like Super Mario Bros. and Contra or store enough information to regenerate the attributes for the column that you're updating.
Post Reply