It is currently Sun Oct 21, 2018 8:18 am

 All times are UTC - 7 hours

 Page 84 of 97 [ 1452 posts ] Go to page Previous  1 ... 81, 82, 83, 84, 85, 86, 87 ... 97  Next
 Print view Previous topic | Next topic
Author Message
 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Mon Oct 06, 2014 8:40 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 937
Location: cypress, texas
Kasumi wrote:
Edit: Only reason I'm mentioning the above again is because I'm not sure where else #\$D0 could come from without rounding.

unregistered wrote:
I'm trying to figure out what row my character is standing on... starting with the oY value. She falls at the beginning and lands on the ground; her oY value is 168. Using my calculator 168 / 16 = 10.5. Now I add 2 to that because she is 32 pixels tall... so 12.5. Rounding up makes that row 13 which is good, I think. Now I clear the calculator memory; it's at 0. 13 * 16 = 208 and then clicking hex button makes that \$D0.

Ok, I'm not rounding up... so I have 12.5... which is 12. 12 * 16 = 192... or \$C0. But that \$C0 doesn't make since because my character is standing on row \$A0. I added 2 (32) to 10.5 to get the value at her feet. ... ... (mad at myself cause I'm still confused)

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Mon Oct 06, 2014 9:40 am

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1251
unregistered wrote:
Ok, I'm not rounding up... so I have 12.5... which is 12. 12 * 16 = 192... or \$C0. But that \$C0 doesn't make since because my character is standing on row \$A0. I added 2 (32) to 10.5 to get the value at her feet. ... ... (mad at myself cause I'm still confused)

She is 32 pixels tall, right? Her position (oY) is where the top of her head is right?

So if her head is at \$A0, Her feet are at \$C0. If her head is at \$C0, her feet are at \$E0. There's nothing more to it.

If you want what row her head is on, don't add the 32 to oY. If you want what row her feet are on, add the 32 to oY. I get the impression you're overthinking this.

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

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Mon Oct 06, 2014 10:04 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 937
Location: cypress, texas
unregistered wrote:
Kasumi wrote:
Edit: Only reason I'm mentioning the above again is because I'm not sure where else #\$D0 could come from without rounding.

unregistered wrote:
I'm trying to figure out what row my character is standing on... starting with the oY value. She falls at the beginning and lands on the ground; her oY value is 168. Using my calculator 168 / 16 = 10.5. Now I add 2 to that because she is 32 pixels tall... so 12.5. Rounding up makes that row 13 which is good, I think. Now I clear the calculator memory; it's at 0. 13 * 16 = 208 and then clicking hex button makes that \$D0.

Ok, I'm not rounding up... so I have 12.5... which is 12. 12 * 16 = 192... or \$C0. But that \$C0 doesn't make since because my character is standing on row \$A0. I added 2 (32) to 10.5 to get the value at her feet. ... ... (mad at myself cause I'm still confused)

Oh yes, ok... now the \$d0 makes sense. I'm looking at FCEUX's hex editor... the screen has 15 rows and 16 columns right? My character is standing on row 13... 13x16=\$D0... in the hex editor...each row is labeled:
Code:
\$0600: Row 0
\$0620: Row 1
\$0640: Row 2
\$0660: Row 3
\$0680: Row 4
\$06A0: Row 5
\$06C0: Row 6
\$06E0: Row 7
\$0700: Row 8
\$0720: Row 9
\$0740: Row A
\$0760: Row B
\$0780: Row C
\$07A0: Row D
\$07C0: Row E

So... my girl is standing on row \$7A0... row 13 (D)... hmm... \$D0 is not good... it's Row D... Ok, yes I'm overthinking this.

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Mon Oct 06, 2014 10:50 am

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1251
00 gives you 00
01 gives you 02
02 gives you 04
03 gives you 06. Etc. This is what you want.

So it's doubled because rows are 32 bytes long. You have what row she's standing on.

Multiply it by two. The carry is clear if you're reading from \$0600 and set if you're reading from \$0700.

Say \$00 is the row. ASL. Result is \$00, Carry clear. You want \$0600.
Say \$20 is the row. ASL. Result is \$40, Carry clear. You want \$0640.

Say \$80 is the row. ASL. Result is \$00, Carry set. You want \$0700.
Say \$A0 is the row. ASL. Result is \$40, Carry set. You want \$0740.

Once you've got the row, multiply it by two, transfer that result to y and branch to either a read from \$0600,y or \$0700,y depending on the carry.

It's all input output. Write out what you want like you did. Find the pattern that can make it happen.

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

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Mon Oct 06, 2014 12:30 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 937
Location: cypress, texas
Kasumi wrote:
00 gives you 00
01 gives you 02
02 gives you 04
03 gives you 06. Etc. This is what you want.

So it's doubled because rows are 32 bytes long. You have what row she's standing on.

Multiply it by two. The carry is clear if you're reading from \$0600 and set if you're reading from \$0700.

Say \$00 is the row. ASL. Result is \$00, Carry clear. You want \$0600.
Say \$20 is the row. ASL. Result is \$40, Carry clear. You want \$0640.

Say \$80 is the row. ASL. Result is \$00, Carry set. You want \$0700.
Say \$A0 is the row. ASL. Result is \$40, Carry set. You want \$0740.

Once you've got the row, multiply it by two, transfer that result to y and branch to either a read from \$0600,y or \$0700,y depending on the carry.

It's all input output. Write out what you want like you did. Find the pattern that can make it happen.

Kasumi, thanks so very much!!

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Wed Oct 08, 2014 3:08 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 937
Location: cypress, texas
Does asm6, my assembler, automatically cut off the top and bottom 8 pixels of the screen?

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Wed Oct 08, 2014 3:12 pm
 Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2263
Assemblers only assemble code, it doesn't know what a screen is or anything, so no it doesn't handle anything with the system. But also isn't something to worry about so much, just don't put anything important in the left+right 8 pixels, and top and bottom 16 pixels on the maps or UI or whatnot.

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Wed Oct 08, 2014 7:15 pm

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10904
Location: Rio de Janeiro - Brazil
unregistered wrote:
Does asm6, my assembler, automatically cut off the top and bottom 8 pixels of the screen?

Like 3gengames said, the assembler has absolutely nothing to do with this. The assembler only translates written code into instructions for the CPU, and it never tells the system to do anything other than what you have specified in the source code. The assembler doesn't even know what system will run the binary it outputs (only that the CPu is a 6502!), so it can't possibly do anything that's specific to the NES.

That being said, a lot of emulators are configured to hide those scanlines, because a lot of TVs cut a part of the picture. All emulators should allow you to change this configuration in the video settings.

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Fri Oct 10, 2014 4:30 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 937
Location: cypress, texas
Thank you 3gengames!! Thank you tokumaru!!
tokumaru wrote:
That being said, a lot of emulators are configured to hide those scanlines, because a lot of TVs cut a part of the picture. All emulators should allow you to change this configuration in the video settings.
Woah, wow!!! In my emulator, FCEUX 2.1.5, clicking "Config">"Video..." let me change it to show the whole screen!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! And doing that didn't affect any of my variables!! I recommend every programmer do that!

Now, here's my next question... In Super Mario Brothers where (how far down the screen) does the brick ground start?

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Fri Oct 10, 2014 5:02 pm

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1251
It begins at pixel 208 (#\$D0), and is 32 pixels tall.

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

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Fri Oct 10, 2014 5:05 pm

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20679
Location: NE Indiana, USA (NTSC)
SMB1 has 32 lines of status bar and 208 lines of playfield, organized as 13 rows each 16 pixels tall. In land and underground levels, the bottom two rows of metatiles, or 32 pixels, are normally filled with the cracked blocks.

So the screen is divided as follows:
0-31: Status
32-207: Playfield above ground level
208-239: Ground level and below

SMB1 (for Super Mario All-Stars) uses a 224-line screen mode, where only 208-223 are ground.

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Sat Oct 11, 2014 11:03 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 937
Location: cypress, texas
Kasumi wrote:
It begins at pixel 208 (#\$D0), and is 32 pixels tall.
tepples wrote:
SMB1 has 32 lines of status bar and 208 lines of playfield, organized as 13 rows each 16 pixels tall. In land and underground levels, the bottom two rows of metatiles, or 32 pixels, are normally filled with the cracked blocks.

So the screen is divided as follows:
0-31: Status
32-207: Playfield above ground level
208-239: Ground level and below

SMB1 (for Super Mario All-Stars) uses a 224-line screen mode, where only 208-223 are ground.
THANK YOU KASUMI AND TEPPLES SO INCREDIBLLY MUCH!!!

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Mon Oct 13, 2014 3:58 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 937
Location: cypress, texas
Honestly, I don't understand draw_sprite.

Code:
0C6D1                             draw_sprite: ;must set x prior to calling draw_sprite
0C6D1
0C6D1                                 ;jsr onscreen
0C6D1
0C6D1
0C6D1                                ; t0-t2 are temporary zero page locations holding
0C6D1                                ; the address of a particular sprite layout and the
0C6D1                                ; number of sprites left to draw
0C6D1 BD 7A E0                       lda sprite_layouts_lo, x  ;<-- ABSOLUTE INDEXED ADDRESSING
0C6D4                                ;1l1 nothing here.
0C6D4 85 09                          sta t0
0C6D6 BD AE E0                       lda sprite_layouts_hi, x  ;<-- ABSOLUTE INDEXED ADDRESSING
0C6D9 85 0A                          sta t0+1
0C6DB BD E2 E0                       lda sprite_layouts_count, x  ;<-- ABSOLUTE INDEXED ADDRESSING
0C6DE 85 31                          sta t2
0C6E0 A0 00                          ldy #0
0C6E2                                ; oamIndex is a variable tracking how far you've written
0C6E2                                ; into shadow OAM (customarily at \$0200-\$02FF)
0C6E2 A6 0B                          ldx oamIndex
0C6E4                              @loop:
0C6E4                                ; If you have the address of an array in a zero page pointer,
0C6E4                                ; you use the (d),y addressing mode and increase Y to go
0C6E4                                ; to the next byte.
0C6E4 B1 09                          lda (t0+0), y  ;<-- INDIRECT INDEXED ADDRESSING
0C6E6 C8                             iny
0C6E7                                ;ect. start
0C6E7 18                             clc
0C6E8 65 06                          adc oY
0C6EA 9D 00 02                       sta sprite, x  ;<-- ABSOLUTE INDEXED ADDRESSING
0C6ED E8                             inx
0C6EE
0C6EE B1 09                          lda (t0+0), y
0C6F0 C8                             iny
0C6F1 9D 00 02                       sta sprite, x
0C6F4 E8                             inx
0C6F5
0C6F5 B1 09                          lda (t0+0), y
0C6F7 C8                             iny
0C6F8 9D 00 02                       sta sprite, x
0C6FB E8                             inx
0C6FC
0C6FC B1 09                          lda (t0+0), y
0C6FE C8                             iny
0C6FF 18                             clc
0C700 65 03                          adc oX
0C702 9D 00 02                       sta sprite, x
0C705 E8                             inx
0C706
0C706                                ;end ect.
0C706 C6 31                          dec t2
0C708 D0 DA                          bne @loop
0C70A 86 0B                          stx oamIndex
0C70C 60                        +end  rts ;end of draw_sprite

Ok so I've been through this code... it has undergone verification... except for one thing. My oY value is at #\$A8, but on my emulator window the sprite is drawn standing on #\$D0. The sprite is 32 pixels tall and so it should be standing on #\$C8 . If I give it #\$B0 she will be standing on #\$D8 which is not good because the ground is at #\$D0. I don't understand why this is happening and I hope you can help me.
Thanks for reading though this,
Matthew (unregistered)

edit: I guess I should say that I've searched my .lst file for "sprite" and I've stepped through each search result and only one instance seemed like a possible problem... it was in this code
Code:
init_sprites:
; Clear page #2, which we'll use to hold sprite data
lda #\$00
ldx #\$00
-       sta sprite, x
inx
bne -

; initialize Sprite 0
lda #\$00;70
sta sprite                ; Y coordinate
lda #\$4
sta sprite+1        ; Pattern number
sta sprite+3        ; X coordinate
; sprite+2, color, stays 0.
rts
it was under my ;initialize Sprite 0 comment... it initialized sprite 0 to #\$70... but I changed that to #\$00 and the problem is the same.

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Mon Oct 13, 2014 5:37 pm

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1251
I've got 16 bytes at the end of zero page RAM I use for debugging. \$F0-\$FF. So whenever something is happening that I don't expect, I begin writing variables to \$F0-\$FF to see which of them is the culprit. Then I can find out why. I'm using \$F0-\$FF in these in the examples, but just replace my writes to \$F0-\$FF with whatever RAM you have entirely free.

Code:
lda (t0+0), y  ;<-- INDIRECT INDEXED ADDRESSING
sta \$F0;Is the offset we're adding correct?
iny
;ect. start
clc
adc oY
sta sprite, x  ;<-- ABSOLUTE INDEXED ADDRESSING
inx
lda oY
sta \$F1;Is oY correct at this point in time?

The above will only get you the result of one of the sprite's positions, but from the sound of things they're all 8 pixels down, so it's probably all the same problem. You can also break on writes to \$F1 to see what these values look like for each of the sprites.

The reason separate RAM is used, is because values like oY change multiple times a frame and you only care about what it is at this specific moment. (And also so you can break on writes more easily.)

Another approach is to briefly replace variables with the constants you expect.

Code:
lda (t0+0), y  ;<-- INDIRECT INDEXED ADDRESSING
iny
;ect. start
clc
adc #\$A8;The value that we expect should work
sta sprite, x  ;<-- ABSOLUTE INDEXED ADDRESSING
inx

If (for example) the above code still draws the sprite 8 pixels down, you may have ruled out oY as the cause. So the data itself at the address stored in t0 and t1 is wrong. Or it's not pointing where you think it's pointing.

So you can then do this

Code:
lda (t0+0), y  ;<-- INDIRECT INDEXED ADDRESSING
iny
;ect. start
clc
adc #\$A8;The value that we expect should work
sta sprite, x  ;<-- ABSOLUTE INDEXED ADDRESSING
inx
lda t0
sta \$F0
lda t0+1
sta \$F1

Verify the address stored in \$F0 and \$F1 with the label-it-points-to's address in your listing file. If it matches, the data itself is probably wrong. If it doesn't, the table that feeds the address to t0 and t0+1 (sprite_layouts_lo and sprite_layouts_hi) is probably wrong.

Debugging is identifying which of your variables doesn't have the value you expect by process of elimination, then tracing back how the wrong values might have gotten there. The above lists a couple of ways to think about problems like this.

Hmm... and actually, I'll take a guess. The data t0 and t0+1 is pointing to is wrong, but the address is correct. You were previously unaware that your emulator was hiding scanlines. So you may have created this data long ago and made the data compensate for this. Just a guess, though. The methods will help if it's wrong.

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

Top

 Post subject: Re: 8x16 and whatever else unreg wants to knowPosted: Tue Oct 14, 2014 6:59 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 937
Location: cypress, texas
Kasumi, thank you so much for these debugging methods!! I will always remember to yuse \$E0 through \$EF to check variable values... and SWEET thank you so much for showing me how to eliminate oY as the cause! ...well, there is still the problem because I am certain the address in sprite_layouts_lo and sprite_layouts_hi is correct... and the data it points to are our sprite definitions... it pointed to oY... all of those definitions are correct we think because they all start at oY. Do you have any other methods or ideas?

Oh I want to say that while laying on my bed and thinking all of this over I was happy to get the idea that there might be something wrong with variable values set near the beginning of reset: because I hadn't checked that part in forever... so I checked it, actually I checked all of reset: down to the cli... and well, nope - they are all correct. The oY problem could still be there but I don't know exactly where to look. My sister and I think I'm trying to find a needle in a haystack.

Top

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 84 of 97 [ 1452 posts ] Go to page Previous  1 ... 81, 82, 83, 84, 85, 86, 87 ... 97  Next

 All times are UTC - 7 hours

#### Who is online

Users browsing this forum: No registered users and 4 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