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

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 wrote: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.
  • 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.
tepples, thank you I appreciate all of this effort. : ) I shouldn't have asked that question. I'm sorry. I'm uncomfortable...
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re:

Post by unregistered »

tepples, thank you so much for your post :D ... I'm working with what you wrote... getting somewhere I think. :oops:
---
tokumaru[color=#BF00FF], on page 21,[/color] wrote:I believe that the main purpose of BIT is to test whether bits in memory are set or clear. You load your bit mask into the accumulator and BIT it with the value you want to test, if the Z flag is set, the bits you tested are clear.
Thanks! :D I'm wondering about this code

Code: Select all

+	lda currNameTable
    sta PPUCTRL0
	sta my_copy_of_last_write_to_PPUCTRL
	
	bit PPUSTATUS2
	
	lda CameraX+0  ; time to MOVE THE CAMERA OBJECT!
	sta PPUSCROLL5     ; write the horizontal scroll count register
	
	lda #$00        ; (no vertical srolling)
    sta PPUSCROLL5     ; set the vertical scroll

  rts ;end of scroll_screen
Why is bit PPUSTATUS2 or bit $2002 there? It doesn't have to do anything with the flags, I don't think, cause the loop ends with an rts.
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 »

$2005 (PPUSCROLL5), (and $2006) are double write registers. Reading from $2002 "resets" them so the next write will always go to the same place.

Code: Select all

lda $2002;Now next write to $2005 will set X scroll
lda #$80
sta $2005;X scroll is #$80
lda #$00
sta $2005;Y scroll is #$00

Code: Select all

lda $2002;Now next write to $2005 will set X scroll
lda #$80
sta $2005;X scroll is #$80
lda $2002;Now next write to $2005 will set X scroll
lda #$00
sta $2005;X scroll is #$00
It's just a way to make sure the values are being written to the right places.

If you just do this:

Code: Select all

lda #$FF
sta $2005;Is this going to X scroll or Y scroll?
lda #$00
sta $2005;Same here.
It's just safe code, since it's possible the FF might become the y scroll and the 0 might become the X scroll if you're not sure which write the register is currently on.

Edit: Ah. And I did lda $2002 in this examples, but using bit lets you read it without changing A, so that's usually what you'd want to do.
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, excellent response! Thank you so much! :D
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 »

Is my debugger lieing to me?
Ok, the accumulator has #$06 in it...
the carry is set
and it subtracts #$80
THEN it says the answer is #$86...
Is that because it subtracted the negative 80 and that changes it to an add? :?
edit: If that's so then is it possible to subtract 80? Maybe im missing something... :?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

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

Post by tokumaru »

unregistered wrote:Ok, the accumulator has #$06 in it...
the carry is set
and it subtracts #$80
THEN it says the answer is #$86...
That's correct: 6 - 128 = -122 ($86, 8-bit, signed)
Is that because it subtracted the negative 80 and that changes it to an add? :?
You can think of it this way, yes, but no matter how you look at it, the answer is correct:

6 - 128 = -122 ($86, 8 bit, signed)
6 - (-128) = 134 ($86, 8 bit, unsigned)
edit: If that's so then is it possible to subtract 80? Maybe im missing something... :?
I'm not sure what your goal is, but maybe 8 bits aren't enough in this case? If you used 16 bits, the result wouldn't be so ambiguous. You see, when you use only 8 bits, 128 and -128 are the same in hex ($80), bit when you use 16 bits, they're very different: 128 = $0080, -128 = $FF80. So if you did $0006 - $0080 you'd get $FF86, which can't be mistaken for $0086.
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 »

My sister said that I should try adding 80 to 6 and see what that does.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

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

Post by tokumaru »

unregistered wrote:My sister said that I should try adding 80 to 6 and see what that does.
Your sister probably doesn't know much 6502 and is just guessing. Do you really want to program a game based on guesses? You need to know what you're doing in order to make good software. Adding $80 or subtracting $80 will have the same result if you keep using 8 bits, because 128 and -128 are the same in hex in this case.

The result you're getting is not wrong, just ambiguous, and this might be causing you trouble. Like I said, if you want to get rid of this ambiguity, you'll need to use 16-bit math.
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 »

tokumaru wrote:
unregistered wrote:My sister said that I should try adding 80 to 6 and see what that does.
Your sister probably doesn't know much 6502 and is just guessing.
She reminded me that you can add a negative number to a positive one and it will be like subtracting it.
tokumaru wrote:Do you really want to program a game based on guesses? You need to know what you're doing in order to make good software. Adding $80 or subtracting $80 will have the same result if you keep using 8 bits, because 128 and -128 are the same in hex in this case.

The result you're getting is not wrong, just ambiguous, and this might be causing you trouble. Like I said, if you want to get rid of this ambiguity, you'll need to use 16-bit math.
OOOOOOOH ok... this is math on a cpu. Then I understand now that it works kind of differently... Ill reread your first reply again.

edit:Ahhhhh yes!!!
tokumaru wrote:
unregistered wrote:Ok, the accumulator has #$06 in it...
the carry is set
and it subtracts #$80
THEN it says the answer is #$86...
That's correct: 6 - 128 = -122 ($86, 8-bit, signed)
Is that because it subtracted the negative 80 and that changes it to an add? :?
You can think of it this way, yes, but no matter how you look at it, the answer is correct:

6 - 128 = -122 ($86, 8 bit, signed)
6 - (-128) = 134 ($86, 8 bit, unsigned)
edit: If that's so then is it possible to subtract 80? Maybe im missing something... :?
I'm not sure what your goal is, but maybe 8 bits aren't enough in this case? If you used 16 bits, the result wouldn't be so ambiguous. You see, when you use only 8 bits, 128 and -128 are the same in hex ($80), bit when you use 16 bits, they're very different: 128 = $0080, -128 = $FF80. So if you did $0006 - $0080 you'd get $FF86, which can't be mistaken for $0086.
That's what my 255 is for. Of course $ff86!!!! YES THANK YOU SO MUCH TOKUMARU!!!! :D :D
ChipHomsar10
Posts: 5
Joined: Sun Jul 21, 2013 8:32 am
Location: On Planet K, 20X6!

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

Post by ChipHomsar10 »

Jeez guys, I am new to coding, but NOT to graphics hacking. Everything is made of 8x8 tiles. For example, loading the SMB rom and locating the mushroom won't show it in one piece. You see each 8x8 tile of it for all of it. A 16x16 sprite has 4 8x8 tiles, 32x32 has 16, so on.

As for the oddity of the 8x16 graphic being 16x32, it's probably something related to your hex for graphics, or something else.
ChipHomsar10
Super Mario Bros, Game Genie, N, Y, A, G, E, O, Start, Glitching Commence!
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

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

Post by tokumaru »

ChipHomsar10 wrote:Jeez guys, I am new to coding, but NOT to graphics hacking. Everything is made of 8x8 tiles.
This thread hasn't been about tiles for what now? 69 pages?
As for the oddity of the 8x16 graphic being 16x32, it's probably something related to your hex for graphics, or something else.
Yup, that should narrow it down!

ChipHomsar10, sorry if I'm being rude. I know you're new and want to participate, but if you want to be a programmer, you have to pay attention to detail. If you gave this thread a second look you'd notice that the issue about sprite sizes has been solved ages ago, and now this is actually "unregistered's thread of general programming questions" (someone should change the subject to that!).
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 and whatever else unreg wants to know

Post by tepples »

Edited to make it less of an artifact title.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

8x16 and whatever else unreg wants to know
... well I surely want to know what is wrong with this code

Code: Select all

update_colors: ;under development *Something definitly wrong with this code... makes screen all uncalm and jumpy during musicA

sta $ff
;		ldx #$02              ;loads 3rd screen
;		jsr load_screen
		
    ;set color of column        
		;must set 2006 with 23C0
		lda #$23
		sta PPUADDR6
		lda #$C0
		sta PPUADDR6
		  ;write to 23C0 and 23E0
		  lda RAMbufferColors+7
		  sta PPUDATA7
		  lda RAMbufferColors+6;3
		  sta PPUDATA7
		  
		; must set 2006 with 23C8
		lda #$23
        sta PPUADDR6
        lda #$C8
		sta PPUADDR6
		  ;write  to 23C8 and 23E8
		  lda RAMbufferColors+5;6
		  sta PPUDATA7
		  lda RAMbufferColors+4;2
		  sta PPUDATA7
		  
		; must set 2006 with 23D0
		lda #$23
		sta PPUADDR6
		lda #$D0
		sta PPUADDR6
		  ;write to 23D0 and 23F0
		  lda RAMbufferColors+3;5
		  sta PPUDATA7
		  lda RAMbufferColors+2;1
		  sta PPUDATA7
		  	
    	;must set 2006 with 23D8
		lda $23
		sta PPUADDR6
		lda #$D8
		sta PPUADDR6
		  ;write to 23D8 and 23F8
		  lda RAMbufferColors+1;4
		  sta PPUDATA7
		  lda RAMbufferColors+0    ;<this is ordered differently from its attribute table array...
		  sta PPUDATA7              ; ...2xF8, 2xD8, 2xF0, 2xD0, 2xE8, 2xC8, 2xE0, 2xC0
		                           ;notice the numbers get smaller as we go
			
    rts	 ;end of update_colors  
Or would that be correct if RAMbufferColors is set up correctly? It is pretty simple code... isn't it? :?
I mean.. all it does is a double write to set $2006 and then 2 writes to $2007... and redo that like 4 times.
edit: PPU is already set up to increment by 32 after each write to $2007.
edit2

edit3: update_colors runs during vblank
ε-δ
Posts: 6
Joined: Mon Jul 22, 2013 5:04 am

Re: 8x16 and whatever else unreg wants to know

Post by ε-δ »

At least you are using wrong adressing mode in one lda. I suppose it's a typo. Try finding it yourself.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

ε-δ wrote:At least you are using wrong adressing mode in one lda. I suppose it's a typo. Try finding it yourself.
GRAND!!! THANK YOU SO INCREDIBLY MUCH ε-δ!!! :D The screen doesn't jump around anymore and the colors just change in places!! Even when the music is playing!!!!!!! :mrgreen:

edit: WOW!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! I MISSED A # SIGN AGAIN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! SO HAPPY THANK YOU SO MUCH ε-δ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! :D I'm insanely excited! And I should be working on music today... so tomorrow is fun with colors. :)
Post Reply