It is currently Mon Oct 23, 2017 1:11 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1382 posts ]  Go to page Previous  1 ... 82, 83, 84, 85, 86, 87, 88 ... 93  Next
Author Message
PostPosted: Wed Oct 15, 2014 1:57 am 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1021
Quote:
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

That doesn't prevent your sprite definitions from being wrong. Did you check the actual data? Can you just post that table?

And you are certain the addresses in sprite_layouts_lo/hi are correct, but did you actually check the addresses?

If something is wrong, you really can't be sure without checking. So actually check if you haven't. If you have, tell me what you actually did check or I can't help.

If this adds 8 to your sprites
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

And this doesn't
Code:
lda #$00  ;<-- INDIRECT INDEXED ADDRESSING
                             iny
                                ;ect. start
                             clc
                          adc oY;The value that we expect should work
                       sta sprite, x  ;<-- ABSOLUTE INDEXED ADDRESSING
                             inx

(Note that above will obviously draw all sprites at the same y location, but if it's the right starting location the problem is probably your definitions)

If the top of the sprite is offset by 8 in both of these, then something is probably changing sprite,x later.

What this all boils down to is this: You are checking if the constant you put in works, while reading the data doesn't. If the correct constant works, and the data doesn't, that means you're obviously not getting that value from the data. Which means the data is wrong, or the pointer is set up incorrectly.

If the correct constant and data both give the same result, that rules out that variable/data as the problem. (Or the correct constant you are supplying is actually not correct. :wink:

So be specific about what happens when you do both of the above, share the data tables and their addresses, post what's in t0 and t0+1 when you do this.

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


Top
 Profile  
 
PostPosted: Wed Oct 15, 2014 5:43 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 800
Location: cypress, texas
Kasumi wrote:
Can you just post that table?
I would have posted the table, but my sister is the boss and she didn't want me to post the table.
The table is correct. :)

Kasumi wrote:
And you are certain the addresses in sprite_layouts_lo/hi are correct, but did you actually check the addresses?
Yes I remember checking the addresses in my listing file and they pointed to oY. I just checked the t0 offset after she has fallen to the ground... it is either $06, $0E, $16, or $1E. oY is always $A8. I'm sorry, I hope to regain and retain my thoroughness.

Kasumi wrote:
If something is wrong, you really can't be sure without checking. So actually check if you haven't. If you have, tell me what you actually did check or I can't help.
That makes sense, ok.

Kasumi wrote:
If this adds 8 to your sprites
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
Yes it does... my sprite is standing on #$D0.

Kasumi wrote:
And this doesn't
Code:
lda #$00  ;<-- INDIRECT INDEXED ADDRESSING
                             iny
                                ;ect. start
                             clc
                          adc oY;The value that we expect should work
                       sta sprite, x  ;<-- ABSOLUTE INDEXED ADDRESSING
                             inx

No. Actually, it does add eight... she (32 bits tall) is still standing on #$D0.

Kasumi wrote:
(Note that above will obviously draw all sprites at the same y location, but if it's the right starting location the problem is probably your definitions)

If the top of the sprite is offset by 8 in both of these, then something is probably changing sprite,x later.

What this all boils down to is this: You are checking if the constant you put in works, while reading the data doesn't. If the correct constant works, and the data doesn't, that means you're obviously not getting that value from the data. Which means the data is wrong, or the pointer is set up incorrectly.

If the correct constant and data both give the same result, that rules out that variable/data as the problem. (Or the correct constant you are supplying is actually not correct. :wink:

So be specific about what happens when you do both of the above, share the data tables and their addresses, post what's in t0 and t0+1 when you do this.
Thank you for all of your help so far. You have really helped me Kasumi! :D I need to do the rest of this by myself. Please forgive me for asking you, "Do you have any other methods or ideas?" I don't mean to milk or squeeze every bit of help out of you. Thank you for all of your help so far; I can do this. :)


Top
 Profile  
 
PostPosted: Thu Oct 23, 2014 12:58 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 800
Location: cypress, texas
Thank you so much Kasumi!!!!!!!!! :D
unregistered wrote:
Kasumi wrote:
As well, related to collision: Consider that I know the tile a position is in is collision enabled. I need to eject upwards. My tile size is a power of two.

Code:
lda position
and #%00001111;For 16
sta temp

lda position
clc
sbc temp
sta position

Done. How does it work? A tile for this example is 16 pixels. So the lowest 4 bits of the position will tell us how far we are into the tile. Say we're at 0000, the very top of the tile. We want to eject one pixel. So we clear the carry to subtract 1 extra. And subtract 0.

Say we're at 1111 ($F). That's the bottom of the tile. To get outside, we want to subtract sixteen. Which... is $F+1, so the same thing works. It works in all the cases. (with square tiles.)
I'm going to answer this part later... thank you for giving me some more time to think about it. :)


edit: Rolly noly goaly toly... well, I just used this SWEET code that works for everything... and it ejected my character to $B0... which is looks like she is standing 8 pixels below $D0... it says 176... which = $B0. How does that happen? I remember doing something a long time ago... but I can't remember right now... well... back to this fun problem I go.


Top
 Profile  
 
PostPosted: Thu Oct 30, 2014 4:05 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 800
Location: cypress, texas
Right now I'm getting the address $06 as data. How do I get my accumulator value "$06" to become an address? Please help me. :)


Top
 Profile  
 
PostPosted: Thu Oct 30, 2014 5:03 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1021
unregistered wrote:
edit: Rolly noly goaly toly... well, I just used this SWEET code that works for everything... and it ejected my character to $B0... which is looks like she is standing 8 pixels below $D0... it says 176... which = $B0. How does that happen?

This isn't a forum that makes a topic unread upon edits, so I never saw this until today. And I have no idea. I can't know from the information I have.
Quote:
Right now I'm getting the address $06 as data. How do I get my accumulator value "$06" to become an address? Please help me.

I don't understand the question. Are you asking how to indirectly access data starting from $0006? $0600 maybe? Something else?

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


Top
 Profile  
 
PostPosted: Thu Oct 30, 2014 5:07 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10067
Location: Rio de Janeiro - Brazil
I'm assuming $06 is some sort of offset? If that's the case, here's my answer:

If the data you want to access is 256 bytes or less, the easiest thing to do is transfer the number (offset) from A to X or Y and use absolute indexed addressing. It's as simple as TAX; LDA BaseAddress, X;

If the total of data is more than 256 bytes, you'll need to create a pointer in Zero Page and use Indirect Indexed addressing. You'll have to do a 16-bit addition of the offset with the base address and store the result in Zero Page. Then you can LDA (Pointer), Y to read the data. Y should be 0 in this case, because the full address is in the pointer already, but the 6502 doesn't have an indirect addressing mode that isn't indexed.


Top
 Profile  
 
PostPosted: Thu Oct 30, 2014 9:27 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 800
Location: cypress, texas
tokumaru wrote:
I'm assuming $06 is some sort of offset? If that's the case, here's my answer:

If the data you want to access is 256 bytes or less, the easiest thing to do is transfer the number (offset) from A to X or Y and use absolute indexed addressing. It's as simple as TAX; LDA BaseAddress, X;
SWEET SASSY MOLASSY!!!! TOKUMARU WE SHOULD REQUEST ALL NES 6502 PROGRAMMERS TO ENGRAVE THIS ON ONE OF THEIR ARMS :P :lol: :shock: :)

tokumaru wrote:
If the total of data is more than 256 bytes, you'll need to create a pointer in Zero Page and use Indirect Indexed addressing. You'll have to do a 16-bit addition of the offset with the base address and store the result in Zero Page. Then you can LDA (Pointer), Y to read the data. Y should be 0 in this case, because the full address is in the pointer already, but the 6502 doesn't have an indirect addressing mode that isn't indexed.
THANKS TOKUMARU FOR THIS ENTIRE RESPONSE!! :D :D

Here is my code now... all of the new code instructions are CAPITALIZED
Code:
  draw_sprite: ;must set x prior to calling draw_sprite
   
      ;jsr onscreen
      
    
     ; t0-t2 are temporary zero page locations holding
     ; the address of a particular sprite layout and the
     ; number of sprites left to draw
     lda sprite_layouts_lo, x  ;<-- ABSOLUTE INDEXED ADDRESSING
     ;1l1 nothing here.
     sta t0
     lda sprite_layouts_hi, x  ;<-- ABSOLUTE INDEXED ADDRESSING
     sta t0+1
     lda sprite_layouts_count, x  ;<-- ABSOLUTE INDEXED ADDRESSING
     sta t2
     ldy #0
     ; oamIndex is a variable tracking how far you've written
     ; into shadow OAM (customarily at $0200-$02FF)
     ldx oamIndex
   @loop:
     ; If you have the address of an array in a zero page pointer,
     ; you use the (d),y addressing mode and increase Y to go
     ; to the next byte.
       TYA
       PHA ;------------->
     lda (t0+0), y  ;<-- INDIRECT INDEXED ADDRESSING
       TAY
       LDA $0000, y ;<-- engrave this on your arm! :P :)
       STA t2+1
       PLA ;<-------------
       TAY
     iny
     ;ect. start
       LDA t2+1
     clc
     adc oY
     sta sprite, x  ;<-- ABSOLUTE INDEXED ADDRESSING
     inx
   lda oY   
   sta $E1
   lda t0 
   sta $E2 
   lda t0+1 
   sta $E3 
    
    
     lda (t0+0), y
   sta $E6
     iny
     sta sprite, x
     inx
    
     lda (t0+0), y
   sta $E7 
     iny
     sta sprite, x
     inx
    
           TYA
      PHA ;--------------->
     lda (t0+0), y
       TAY
      LDA $0000, y
      STA t2+1
      PLA ;<---------------
      TAY
    
     iny
       LDA t2+1
     clc
     adc oX
     sta sprite, x
     inx
    
     ;end ect.       
     dec t2
     bne @loop
     stx oamIndex
+end  rts ;end of draw_sprite
...Now Kasumi and tokumaru, I don't mean for yall to trudge through all of that code... I just want yall to see the CAPITALIZED instructions that I added. Now my code doesn't add #$03 to every x value. Our sprite is drawn at the oX value #$00 now (right up next to the left side of the screen). My sister helped me to learn that it was starting with #$03 because oX is at address $0003. oY is at address $0006 so the same should happen to that value... but it doesn't yet for some reason... it's kind of weird.

edit.

edit2: I want to point out that there are two groups of CAPITALIZED code... one before the adc oY part... and then one before the adc oX part. Both groups should be the exact same code... I will double check that tomorrow... goodnight yalll everyone. :)

edit3.


Top
 Profile  
 
PostPosted: Thu Oct 30, 2014 11:55 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1021
I'm not sure I understand the purpose of the new code. t0 and t1 have the address we want to load the data from. Y keeps track of how far into the data we are.

Code:
 TYA;We're pushing the value in Y
       PHA;To the stack
     lda (t0+0), y  ;We're loading from the data. So shouldn't this mean the value we've meant to load is now in A?
       TAY;But then we move it into Y
       LDA $0000, y;And load a zero page variable?
       STA t2+1
       PLA ;<-------------
       TAY

This code suggests your table whose address is stored at t0 contains a zero page index that contains the actual value you want. This is not necessarily bad, but why the extra step? Why not just store the actual value you want rather than a reference to a variable that contains that value?

Quote:
My sister helped me to learn that it was starting with #$03 because oX is at address $0003

I'm not sure I understand. Where the variable is on the zero page should have no bearing on what its initial/current value would ever be.

If your table was set up like this:
Code:
sprite_layout_one:
.db $00;Y offset for sprite 0
.db $00;Tile for sprite 0
.db %00000000;Attributes for sprite 0
.db $00;X offset for sprite 0

.db $00;Y offset for sprite 1
.db $01;Tile for sprite 1
.db %00000000;Attributes for sprite 1
.db $08;X offset for sprite 1

.db $08;Y offset for sprite 2
.db $02;Tile for sprite 2
.db %00000000;Attributes for sprite 2
.db $00;X offset for sprite 2

.db $08;Y offset for sprite 3
.db $03;Tile for sprite 3
.db %00000000;Attributes for sprite 3
.db $08;X offset for sprite 3

;Sprite 0 is drawn using tile index #$00 directly at the X and Y position.
;Sprite 1 is drawn using tile index #$01 eight pixels to the right of the X position, and directly at the Y position
;Sprite 2 is drawn using tile index #$02 directly at the X position, and eight pixels below the Y position
;Sprite 3 is drawn using tile index #$03 eight pixels to the right of the X position, and eight pixels below the Y position

You'd already have all the info you need by accessing sprite_layout_one. Like so:
Code:
@loop:
lda sprite_layout_one,y;This is how far the sprite is OFFSET from our Y position
clc;So we add it to the Y position
adc oY
sta sprite,x
iny
inx

lda sprite_layout_one,y;Tile index
sta sprite,x

iny
inx

lda sprite_layout_one,y;Sprite attributes
sta sprite,x

iny
inx

lda sprite_layout_one,y;This is how far the sprite is OFFSET from our X position
clc;So we add it to the x position
adc oX
sta sprite,x

iny
inx

dec t2
bne @loop
stx oamIndex
rts


The only thing missing in the above is the indirect part.

Code:
;If the low and high bytes of sprite_layout_one were in t0 and t1, the following two lines of code would access the same value. (And put it into A)

lda sprite_layout_one,y
lda (t0),y


So a full version might look like...
Code:
; t0-t2 are temporary zero page locations holding
; the address of a particular sprite layout and the
; number of sprites left to draw
draw_sprite:

lda sprite_layouts_lo, x
sta t0
lda sprite_layouts_hi, x  ;<-- ABSOLUTE INDEXED ADDRESSING
sta t0+1

lda sprite_layouts_count, x  ;<-- ABSOLUTE INDEXED ADDRESSING
sta t2

ldy #0
ldx oamIndex; oamIndex is a variable tracking how far you've written
; into shadow OAM (customarily at $0200-$02FF)

@loop:
lda (t0),y;This is how far the sprite is OFFSET from our Y position
clc;So we add it to the Y position
adc oY
sta sprite,x
iny
inx

lda (t0),y;Tile index
sta sprite,x

iny
inx

lda (t0),y;Sprite attributes
sta sprite,x

iny
inx

lda (t0),y;This is how far the sprite is OFFSET from our X position
clc;So we add it to the x position
adc oX
sta sprite,x

iny
inx

dec t2
bne @loop:
stx oamIndex
rts

sprite_layout_one:
.db $00;Y offset for sprite 0
.db $00;Tile for sprite 0
.db %00000000;Attributes for sprite 0
.db $00;X offset for sprite 0

.db $00;Y offset for sprite 1
.db $01;Tile for sprite 1
.db %00000000;Attributes for sprite 1
.db $08;X offset for sprite 1

.db $08;Y offset for sprite 2
.db $02;Tile for sprite 2
.db %00000000;Attributes for sprite 2
.db $00;X offset for sprite 2

.db $08;Y offset for sprite 3
.db $03;Tile for sprite 3
.db %00000000;Attributes for sprite 3
.db $08;X offset for sprite 3

;Sprite 0 is drawn using tile index #$00 directly at the X and Y position.
;Sprite 1 is drawn using tile index #$01 eight pixels to the right of the X position, and directly at the Y position
;Sprite 2 is drawn using tile index #$02 directly at the X position, and eight pixels below the Y position
;Sprite 3 is drawn using tile index #$03 eight pixels to the right of the X position, and eight pixels below the Y position


sprite_layouts_lo:
.db <sprite_layout_one

sprite_layouts_hi:
.db >sprite_layout_one

sprite_layouts_count:
.db 4;There are four sprites in sprite_layout_one


So if you did
Code:
ldx #$00
jsr draw_sprite

You'd get a 16x16 metasprite composed of tile $00 for top left corner, tile $01 for the top right corner, tile $02 for the bottom left corner, tile $03 for the bottom right corner. All with no flipping, and palette 0.

I have zero idea what your tables look like or how your data is stored. So here's a way store the data and access it that might be different from what you're doing.

I did test the above, but full disclosure: I tested it very briefly and I had to convert its syntax to NESASM, so something small done in that process may have fixed a potential issue. But I can fix this if it's broken. I cannot help fix what you have without... the rest of what you have.

edit: I made a test rom, because lately I've been making a lot of mistakes by trying to help without testing my code. And since the test rom exists, may as well attach it. It is the definition of quick and dirty, you've got to edit RAM manually to see the sprite move. ($03 and $04 are its X and Y positions respectively.) After initialization it literally does nothing but run this routine in the main loop every frame. The NMI updates palettes so the sprite is visible, and of course does the sprite DMA. Nothing else. (Also, adc oY and adc oX end up assembled as absolute not zero page, because I didn't bother doing zero page the nesasm way when converting.)


Attachments:
main.nes [24.02 KiB]
Downloaded 68 times

_________________
https://kasumi.itch.io/indivisible
Top
 Profile  
 
PostPosted: Tue Nov 04, 2014 11:57 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 800
Location: cypress, texas
:oops: :oops: :oops:
qbradq, on page 3, wrote:
So your example above becomes:

Code:
aY EQU 10
aX EQU 20
.db aY, $80, $00, aX, aY, $81, $00, aX +1



Remember, the .byte and .db directives emit a byte of data into the output ROM file. The EQU directive (and it's cousin, the = operator) create symbols within the assembler that you can use latter on.
tokumaru, also, a post or two later, on page 3, wrote:
Symbols are just "nicknames" for numbers. These numbers can represent memory locations (which is the case of labels and variables) or numeric constants (values you commonly use throughout the program).

They exist only in the source code to make programming easier (just imagine if you had to remember the addresses of everything!), they do not exist in the assembled program.


So you would think I would have learned that symbols do not exist in the assembled program... but no after being given this on page 4
tepples, on page 4, wrote:
Code:
hero_frame1:
  .db aY,    $80, $00, ax, aY,    $81, $00, aX+8
  .db aY+8,  $90, $00, aX, aY+8,  $91, $00, aX+8
  .db aY+16, $a0, $00, aX, aY+16, $a1, $00, aX+8
  .db aY+24, $b0, $00, aX, aY+24, $b1, $00, aX+8

I changed the aYs to oYs and the aXes to oXen... and so that is how our sprite definitions have been till now... but tomorrow I am going to change everything all of them back to aY and aX. That will be a start in the right direction, I think. :)

edit.


Top
 Profile  
 
PostPosted: Wed Nov 05, 2014 10:36 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 800
Location: cypress, texas
Kasumi wrote:
edit: I made a test rom, because lately I've been making a lot of mistakes by trying to help without testing my code. And since the test rom exists, may as well attach it. It is the definition of quick and dirty, you've got to edit RAM manually to see the sprite move. ($03 and $04 are its X and Y positions respectively.) After initialization it literally does nothing but run this routine in the main loop every frame. The NMI updates palettes so the sprite is visible, and of course does the sprite DMA. Nothing else. (Also, adc oY and adc oX end up assembled as absolute not zero page, because I didn't bother doing zero page the nesasm way when converting.)

Kasumi, thank you so much for this test rom!! :D I just figured out how to edit RAM manually in FCEUX 2.1.5! I clicked Tools>Cheats... and this window came up where I then entered 0003 in the "Address:" box and 80 in the "Value:" box... and then I clicked the Add button and WALAAH!!! :D It moved the sprite down :shock: to the middle of the screen! (So I think your definitions are backwards...)
Quote:
($03 and $04 are its X and Y positions respectively.)
should be "($03 and $04 are its Y and X positions respectively)", I think. : )

edit: And guess what you were right to say you didn't understand why I added my capitalized code to draw_sprite. I just commented all of those capitalized code lines away and our 32 pixel tall girl is standing on $D0! JUST LIKE MARIO!!! AND ALL OF THE OYS AND OXEN ARE AYS AND AXES NOW!!!!! IT'S SWEEEEEEEEEEET!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WOO HOOO THANK YOU KASUMI!!!!! :D :D :)


Last edited by unregistered on Wed Nov 05, 2014 12:06 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed Nov 05, 2014 12:02 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10067
Location: Rio de Janeiro - Brazil
unregistered wrote:
I just figured out how to edit RAM manually in FCEUX 2.1.5! I clicked Tools>Cheats... and this window came up where I then entered 0003 in the "Address:" box and 80 in the "Value:" box... and then I clicked the Add button

That's actually patching, not RAM editing. The difference is that patched bytes can't be changed by the game program (i.e. $03 will always read back as $80 even if the game program tries to store something there). Sometimes that may even be the desired behavior, but other times you may actually want to change values and let the game code manipulate them after that. When that's the case, you can use FCEUX's hex editor. There you can select what kind of memory you want to see (e.g. ROM, RAM, VRAM), and then you can just click on the bytes to input new values. There are also options to freeze and unfreeze values.


Top
 Profile  
 
PostPosted: Wed Nov 05, 2014 12:11 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 800
Location: cypress, texas
tokumaru wrote:
unregistered wrote:
I just figured out how to edit RAM manually in FCEUX 2.1.5! I clicked Tools>Cheats... and this window came up where I then entered 0003 in the "Address:" box and 80 in the "Value:" box... and then I clicked the Add button

That's actually patching, not RAM editing. The difference is that patched bytes can't be changed by the game program (i.e. $03 will always read back as $80 even if the game program tries to store something there). Sometimes that may even be the desired behavior, but other times you may actually want to change values and let the game code manipulate them after that. When that's the case, you can use FCEUX's hex editor. There you can select what kind of memory you want to see (e.g. ROM, RAM, VRAM), and then you can just click on the bytes to input new values. There are also options to freeze and unfreeze values.
Thank you so much tokumaru!! :D Well... um... how can I just click on the bytes to input new values? I've never tried that... will try that! Thanks! :D


Top
 Profile  
 
PostPosted: Wed Nov 05, 2014 12:16 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1021
Hah, yep $03 and $04 backwards. Sorry about that. Even when I made sure the code worked, I messed up the description. :lol:

Quote:
I just figured out how to edit RAM manually in FCEUX 2.1.5!

Tokumaru ninja'd, but I'm adding that cheats also might affect later boots. (Even if you close FCEUX and open it again, the value may remain frozen or "cheat'd" depending on your settings.) I definitely prefer the hex editor.

Edit: Yes, just scroll to the byte you want, click it and start typing.
Quote:
I am going to change everything all of them back to aY and aX.

It's not even required to do that. You can have just the offset value. (If aY and aX are both zero, anyway. Otherwise it may still be convenient to have them as global offsets to add to the other offsets.) Glad it's working either way!

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


Top
 Profile  
 
PostPosted: Wed Nov 05, 2014 4:50 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 800
Location: cypress, texas
Kasumi wrote:
Hah, yep $03 and $04 backwards. Sorry about that. Even when I made sure the code worked, I messed up the description. :lol:

Glad you are laughing. :)

Kasumi wrote:
Quote:
I just figured out how to edit RAM manually in FCEUX 2.1.5!

Tokumaru ninja'd, but I'm adding that cheats also might affect later boots. (Even if you close FCEUX and open it again, the value may remain frozen or "cheat'd" depending on your settings.) I definitely prefer the hex editor.
Thanks, me too. :)

Kasumi wrote:
Edit: Yes, just scroll to the byte you want, click it and start typing.
This would have been very helpful... thank you Kasumi! :D I reached a point of confusion where I didn't know what to do to make the hex editor work like tokumaru described... so I just tried typing. :)

Kasumi wrote:
Quote:
I am going to change everything all of them back to aY and aX.

It's not even required to do that. You can have just the offset value. (If aY and aX are both zero, anyway. Otherwise it may still be convenient to have them as global offsets to add to the other offsets.) Glad it's working either way!
Thanks! :D

edit.


Top
 Profile  
 
PostPosted: Thu Nov 06, 2014 11:32 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 800
Location: cypress, texas
Shiru, on page 46, wrote:
There is no official NES programming manual available, but you can easily find the SNES one, if you are just interested what an official doc looks like.
Shiru, I want to buy the SNES one... how do I find it?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1382 posts ]  Go to page Previous  1 ... 82, 83, 84, 85, 86, 87, 88 ... 93  Next

All times are UTC - 7 hours


Who is online

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