8x16 and whatever else unreg wants to know
Moderator: Moderators
Re: 8x16 sprite is really a 16x32 pixel image?
That might be a function of the debugger you're using; FCEUX's debugger shows the current value of that memory location, so it will show the old value until you single-step past it.
Or I might be completely misunderstanding; if so, sorry.
Or I might be completely misunderstanding; if so, sorry.
Re: new question
What were you expecting exactly? At address $002D you used the .dsb statement, which reserves the specified amount of bytes, meaning you reserved one byte at that location. If your program doesn't store anything there, that memory position will remain undefined (RAM contains unpredictable values on power up). Emulators usually initialize the RAM to $00, $FF, or a mix of both, but on actual hardware the contents are unpredictable.unregistered wrote:WHY IS $002D AT #$00?????????
Now, it seems you are trying to initialize variables in RAM with .db statements. That doesn't work. Assemblers generate ROM code, and ROM files don't contain any RAM information, so you can't possibly ask for the assembler to initialize RAM values. This code:
Code: Select all
atttablerownums: .db $00, $20, $40, $60, $80, $a0, $c0, $e0
You'd need something like this to initialize that table like you want:
Code: Select all
;copy table from ROM to RAM
ldx #7
- lda table, x
sta atttablerownums, x
dex
bpl -
;table somewhere in ROM
table: .db $00, $20, $40, $60, $80, $a0, $c0, $e0
Code: Select all
;reserve 8 bytes for the table
atttablerownums .dsb 8
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
Thank you thefox, tepples, and bogax for helping me all of us!
An assert macro? I think I don't understand this. It's ok though. Thanks rainwarrior.rainwarrior wrote:You could implement an assert macro that reads or writes to a specific address, executes a bad opcode, or something else that is not dependent on the program counter. This would let you keep the same "assert" breakpoint from build to build.
Alternatively, you could try to auto-generate the .dbg file FCEUX uses based on compile symbols. This would be better, since you could then have asserts without any extra code in the ROM.
THANK YOU SO MUCH tokumaru!! I was expecting exactly what I thought wrong about .db statements... they seem to work correctly in another file... but I guess that file is included into RAM... I think i remember that...tokumaru wrote:What were you expecting exactly?unregistered wrote:WHY IS $002D AT #$00?????????
tokumaru, you are good at teaching! : ) Well... I think so. Thanks so much!tokumaru wrote:At address $002D you used the .dsb statement, which reserves the specified amount of bytes, meaning you reserved one byte at that location. If your program doesn't store anything there, that memory position will remain undefined (RAM contains unpredictable values on power up). Emulators usually initialize the RAM to $00, $FF, or a mix of both, but on actual hardware the contents are unpredictable.
Now, it seems you are trying to initialize variables in RAM with .db statements. That doesn't work. Assemblers generate ROM code, and ROM files don't contain any RAM information, so you can't possibly ask for the assembler to initialize RAM values. This code:...will reserve 8 bytes from $002F to $0036, but it will not initialize the values to the ones you specified. To initialize the memory to those values you'll have to manually LDA + STA the values there, the assembler just can't do it.Code: Select all
atttablerownums: .db $00, $20, $40, $60, $80, $a0, $c0, $e0
You'd need something like this to initialize that table like you want:And in RAM you'll just have:Code: Select all
;copy table from ROM to RAM ldx #7 - lda table, x sta atttablerownums, x dex bpl - ;table somewhere in ROM table: .db $00, $20, $40, $60, $80, $a0, $c0, $e0
Code: Select all
;reserve 8 bytes for the table atttablerownums .dsb 8
Re: 8x16 sprite is really a 16x32 pixel image?
Yeah, some platforms do copy whole programs to RAM (mostly home computers which had significant amounts of RAM in order to load programs from disks or tapes), and in those cases .db does work for initializing variables... On the NES however, that's usually not the case, since programs run mostly from ROM, so be careful with that.unregistered wrote:I was expecting exactly what I thought wrong about .db statements... they seem to work correctly in another file... but I guess that file is included into RAM... I think i remember that...
Heh, I normally suck at teaching stuff, so I'm glad you can understand my explanations.tokumaru, you are good at teaching! : ) Well... I think so. Thanks so much!
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
Thanks for your help lidnariq. FCEUX's debugger is so great!! I think I've learned what step-over and step-out do too!lidnariq wrote:That might be a function of the debugger you're using; FCEUX's debugger shows the current value of that memory location, so it will show the old value until you single-step past it.
Or I might be completely misunderstanding; if so, sorry.
- Step-over allows you to run the code that the method jsrs to but skip it entirely; it skips to the next line!
- Step-out let's you step out of a method and it also skips to the same next line that step-over would have skipped to... that's there for people like me who accidentally press step-into too many times.
edit
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
Your explanations have always worked out excellent, for me at least, because you can answer my questions!tokumaru wrote:Heh, I normally suck at teaching stuff, so I'm glad you can understand my explanations.tokumaru, you are good at teaching! : ) Well... I think so. Thanks so much!
Where can I find ROM? I'm extreemly confused.tokumaru wrote:Now, it seems you are trying to initialize variables in RAM with .db statements. That doesn't work. Assemblers generate ROM code, and ROM files don't contain any RAM information, so you can't possibly ask for the assembler to initialize RAM values. This code:...will reserve 8 bytes from $002F to $0036, but it will not initialize the values to the ones you specified. To initialize the memory to those values you'll have to manually LDA + STA the values there, the assembler just can't do it.Code: Select all
atttablerownums: .db $00, $20, $40, $60, $80, $a0, $c0, $e0
You'd need something like this to initialize that table like you want:And in RAM you'll just have:Code: Select all
;copy table from ROM to RAM ldx #7 - lda table, x sta atttablerownums, x dex bpl - ;table somewhere in ROM table: .db $00, $20, $40, $60, $80, $a0, $c0, $e0
Code: Select all
;reserve 8 bytes for the table atttablerownums .dsb 8
Why does your
table: .db $00, $20, $40, $60, $80, $a0, $c0, $e0
seem so unfair... see I can understand why.... !!!!! OK!
So would this work?
Code: Select all
lda #$00
sta atttablerownums+0
lda #$20
sta atttablerownums+1
lda #$40
sta atttablerownums+2
lda #$60
sta atttablerownums+3
lda #$80
sta atttablerownums+4
lda #$a0
sta atttablerownums+5
lda #$c0
sta atttablerownums+6
lda #$e0
sta atttablerownums+7
Last edited by unregistered on Sat Sep 15, 2012 10:13 pm, edited 1 time in total.
Re: 8x16 sprite is really a 16x32 pixel image?
Yeah, basically. It's just a loop that takes the data from the pointer in your program ROM, and puts those bytes after in to the RAM space that you need. RAM needs to have all the data needed to be there put in to it from program and data tables like that, remember that.
Re: 8x16 sprite is really a 16x32 pixel image?
Yes, that would work fine as well. I just used the loop as an example because with larger tables a long chain of LDA + STA would become impractical.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
YES!!!!!!!!!!!!!!!!!!!!
The attribute tables are looking correct now!
The attribute tables are looking correct now!
Ok... thank you 3gengames!3gengames wrote:Yeah, basically. It's just a loop that takes the data from the pointer in your program ROM, and puts those bytes after in to the RAM space that you need. RAM needs to have all the data needed to be there put in to it from program and data tables like that, remember that.
Yes, I agree. Thank you tokumaru!tokumaru wrote:Yes, that would work fine as well. I just used the loop as an example because with larger tables a long chain of LDA + STA would become impractical.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Back to collision detection...
Ok, here is some code I don't know the best way to make it work
This was rewritten today... moving the 2 inx-es to the top so that it would stop constantly incrementing by 32 everytime. It works correctly now until it reaches its first increment by 32... and then it continues to increment by 32 forever...
I know it needs some check that prevents it from incrementing 32 again. That seems like it could be a lot of code... thought maybe one of you could quickly find a grand solution... something that's easily added... but short and to the point.
Code: Select all
;macro increasesxby2andmaybeby32too h********************************************
; destroys x... kindof... X is destroyed and then saved at the very end after it gets it's new incremented value.
; increments x by 2...
; else, increments x by 32 if it becomes a multiple of 32...
;
;***********************************************************
macro increasesxby2or32 h
sta $ff
pha ;-------------------->
ldx h
inx ;always increment by 2
inx ;<--/
txa
;lda h
and #00011111b ;and then, if tileNum isn't a multiple of 32
bne + ;go and be done
clc
txa
adc #00011110b ;#30
+ sta h
tax
pla ;<--------------------
endm ;end of macro increasesxby2or32
I know it needs some check that prevents it from incrementing 32 again. That seems like it could be a lot of code... thought maybe one of you could quickly find a grand solution... something that's easily added... but short and to the point.
Re: 8x16 sprite is really a 16x32 pixel image?
I don't get what that's even doing. Either it needs to be incremented by 2 or 32. If it is by 2, just do INX INX. If not, do:
That will multiply X by 32. If you need to test to see if a value is a multiple of 32 (in the A register), do:
And if the 0 condition code is set (BEQ if true) then it is a multiple of 32.
I'm sorry I can't help with THAT piece of code, but that's the best I can do at this hour to maybe give you better ideas to write it. I don't think that's a macro you should be using to often, it's big and seems weird and complex honestly.
ETA: Didn't realize you know how to check for the 32 division thing, good job on that. But honestly I don't see where you'd need a program like this...
Code: Select all
PHA
TXA
ASL A
ASL A
ASL A
ASL A
ASL A
TAX
PLA
Code: Select all
AND #%00011111
I'm sorry I can't help with THAT piece of code, but that's the best I can do at this hour to maybe give you better ideas to write it. I don't think that's a macro you should be using to often, it's big and seems weird and complex honestly.
ETA: Didn't realize you know how to check for the 32 division thing, good job on that. But honestly I don't see where you'd need a program like this...
Re: 8x16 sprite is really a 16x32 pixel image?
When there's no need to increment 32, aren't you storing the wrong value into h? A is the altered value you used to check if X was a multiple of 32, why would you want to save that? If I'm reading it correctly, it would just be a matter of transformin + sta h into + stx h moving it to after tax.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
Thank you for replying 3gengames! It's a macro because I want it to be a macro... it is only to be used once, you're right.
edit: I did this and it still keeps incrementing by 32 forever... once it becomes a multiple of 32. Here is my code: good night yall.
Umm.... well... yes I am.tokumaru wrote:When there's no need to increment 32, aren't you storing the wrong value into h?
No I guess me was confused. Thank you for seeing that! So glad I asked the question!tokumaru wrote:A is the altered value you used to check if X was a multiple of 32, why would you want to save that?
...... give me a min...tokumaru wrote: If I'm reading it correctly, it would just be a matter of transformin + sta h into + stx h moving it to after tax.
edit: I did this and it still keeps incrementing by 32 forever... once it becomes a multiple of 32. Here is my code:
Code: Select all
;macro increasesxby2andmaybeby32too h********************************************
; destroys x... kindof. X is destroyed and then saved at the very end after it gets it's new incremented value.
; increments x by 2...
; else, increments x by 32 if it becomes a multiple of 32...
;
;***********************************************************
macro increasesxby2or32 h
sta $ff
pha ;-------------------->
ldx h
inx ;always increment by 2
inx ;<--/
txa
;lda h
and #00011111b ;and then, if tileNum isn't a multiple of 32
bne + ;go and be done
clc
txa
adc #00011110b ;#30
tax
+ stx h
pla ;<--------------------
endm ;end of macro increasesxby2or32
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: Back to collision detection...
Good morning NesDev.
After rereading your also helpful post 3gengames I might try using that code... though I think my adding 30 takes less cycles than your x32.
If the code is a multiple of 32 I chose to add 30. Thats after always adding 2 in the front.
edit: ok... kindof rewrote this...
Do you see any assembly problems or ways to improve this?
If the code is a multiple of 32 I chose to add 30. Thats after always adding 2 in the front.
edit: ok... kindof rewrote this...
Code: Select all
dontIncrement32 = true;
if (!dontIncrement32 && it's a mtple of 32) {
clc
adc #32
dontIncrement32 = true;
}
elseif (dontIncrement32) {
inx
inx
dontIncrement32 = false;
}
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
Kindof rewrote & corrected this pseudocode again... (sorry about the harsh edits to my last post; I failed yall. Please trust me again.)
Do you see possible improvments or corrections?
Code: Select all
haveAdded2 = false;
if (X is a multiple of 32) {
if (haveAdded2) {
txa
clc
adc #32
haveAdded2 = false;
}
else {
inx
inx
haveAdded2 = true;
}
}
else {
inx
inx
haveAdded2 = true
}
tax