It is currently Mon Oct 22, 2018 8:10 pm

 All times are UTC - 7 hours

 Page 70 of 97 [ 1452 posts ] Go to page Previous  1 ... 67, 68, 69, 70, 71, 72, 73 ... 97  Next
 Print view Previous topic | Next topic
Author Message
 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Wed Jul 10, 2013 4:04 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 937
Location: cypress, texas
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...

Top

 Post subject: Re:Posted: Thu Jul 18, 2013 9:20 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 937
Location: cypress, texas
tepples, thank you so much for your post ... I'm working with what you wrote... getting somewhere I think.
---

tokumaru, on page 21, 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! I'm wondering about this code
Code:
+   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.

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Thu Jul 18, 2013 10:23 am

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1251
\$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:
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:
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:
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.

_________________
https://kasumi.itch.io/indivisible

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Thu Jul 18, 2013 10:35 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 937
Location: cypress, texas
Kasumi, excellent response! Thank you so much!

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Sat Jul 20, 2013 1:34 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 937
Location: cypress, texas
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...

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Sat Jul 20, 2013 2:49 pm

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10910
Location: Rio de Janeiro - Brazil
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)

Quote:
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)

Quote:
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.

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Sat Jul 20, 2013 3:02 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 937
Location: cypress, texas
My sister said that I should try adding 80 to 6 and see what that does.

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Sat Jul 20, 2013 3:25 pm

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10910
Location: Rio de Janeiro - Brazil
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.

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Sat Jul 20, 2013 3:43 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 937
Location: cypress, texas
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)

Quote:
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)

Quote:
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!!!!

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Sun Jul 21, 2013 7:18 pm

Joined: Sun Jul 21, 2013 8:32 am
Posts: 5
Location: On Planet K, 20X6!
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!

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Sun Jul 21, 2013 7:38 pm

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10910
Location: Rio de Janeiro - Brazil
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?

Quote:
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!).

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Sun Jul 21, 2013 10:55 pm

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20687
Location: NE Indiana, USA (NTSC)
Edited to make it less of an artifact title.

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Mon Aug 05, 2013 12:56 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 937
Location: cypress, texas
Quote:
8x16 and whatever else unreg wants to know

... well I surely want to know what is wrong with this code
Code:
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

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Tue Aug 06, 2013 3:02 am

Joined: Mon Jul 22, 2013 5:04 am
Posts: 6
At least you are using wrong adressing mode in one lda. I suppose it's a typo. Try finding it yourself.

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Tue Aug 06, 2013 8:36 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 937
Location: cypress, texas
ε-δ 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 ε-δ!!! The screen doesn't jump around anymore and the colors just change in places!! Even when the music is playing!!!!!!!

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

Top

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 70 of 97 [ 1452 posts ] Go to page Previous  1 ... 67, 68, 69, 70, 71, 72, 73 ... 97  Next

 All times are UTC - 7 hours

#### Who is online

Users browsing this forum: battagline and 2 guests

 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum

Search for:
 Jump to:  Select a forum ------------------ NES / Famicom    NESdev    NESemdev    NES Graphics    NES Music    Homebrew Projects       2018 NESdev Competition       2017 NESdev Competition       2016 NESdev Competition       2014 NESdev Competition       2011 NESdev Competition    Newbie Help Center    NES Hardware and Flash Equipment       Reproduction    NESdev International       FCdev       NESdev China       NESdev Middle East Other    General Stuff    Membler Industries    Other Retro Dev       SNESdev       GBDev    Test Forum Site Issues    phpBB Issues    Web Issues    nesdevWiki
Powered by phpBB® Forum Software © phpBB Group