It is currently Sat Dec 16, 2017 4:19 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1389 posts ]  Go to page Previous  1 ... 81, 82, 83, 84, 85, 86, 87 ... 93  Next
Author Message
PostPosted: Mon Oct 06, 2014 8:40 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 807
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. ... :? ... :x (mad at myself cause I'm still confused)


Top
 Profile  
 
PostPosted: Mon Oct 06, 2014 9:40 am 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1046
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. ... :? ... :x (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
 Profile  
 
PostPosted: Mon Oct 06, 2014 10:04 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 807
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. ... :? ... :x (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
 Profile  
 
PostPosted: Mon Oct 06, 2014 10:50 am 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1046
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
 Profile  
 
PostPosted: Mon Oct 06, 2014 12:30 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 807
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!! :D :D


Top
 Profile  
 
PostPosted: Wed Oct 08, 2014 3:08 pm 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Wed Oct 08, 2014 3:12 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
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
 Profile  
 
PostPosted: Wed Oct 08, 2014 7:15 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10165
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
 Profile  
 
PostPosted: Fri Oct 10, 2014 4:30 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 807
Location: cypress, texas
Thank you 3gengames!! Thank you tokumaru!! :D
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!! :D 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
 Profile  
 
PostPosted: Fri Oct 10, 2014 5:02 pm 
Offline
User avatar

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

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


Top
 Profile  
 
PostPosted: Fri Oct 10, 2014 5:05 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19348
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
 Profile  
 
PostPosted: Sat Oct 11, 2014 11:03 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 807
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!!! :D


Top
 Profile  
 
PostPosted: Mon Oct 13, 2014 3:58 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 807
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
 Profile  
 
PostPosted: Mon Oct 13, 2014 5:37 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1046
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
 Profile  
 
PostPosted: Tue Oct 14, 2014 6:59 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 807
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! :D :D ...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
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1389 posts ]  Go to page Previous  1 ... 81, 82, 83, 84, 85, 86, 87 ... 93  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 forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group