Post subject: Re: 8x16 sprite is really a 16x32 pixel image?
Yes, this is correct. I like to think about it this way: the carry flag, in subtractions, is actually a value that can be borrowed if necessary. After the subtraction (CMP acts just like SEC + SBC, except it doesn't change A), if the carry is still set, a borrow wasn't necessary, so the value in A was large enough for you to subtract from it as much as you did (it's >= the value you subtracted). If the carry is clear, a borrow was necessary and the value in A wasn't large enough (it's < than the subtracted value).
Ah yes, I was correct in my guess!! Thank you so much tokumaru!
I have a loop in my code.
How would be a good way to set that up... something simple maybe? And these lines of code will be in the middle of my large loop. I'm trying to use one of those temp variables Kasumi recommended me.
It sorta depends on how long the loop is/what registers you need.
If it's long, I might just store whatever is in t6 or t6+1 into a new temp variable or a register and then just always use the new temp variable or register.
That one is probably best, because it doesn't add setup time to each loop after the first like the others. It just came to mind third.
Or I might do something totally different depending on the setup of the loop. But there's some ideas.
This one rocks!! (I just figured it out! ) Thank you Kasumi!!! They are all good though, thanks very much!
AND GOODNESS!! THIS FORUM JUST KEEPS GETTING BETTER AND BETTER, THANKS YALL! Edit: It's kindof slow right now...but maybe that's because there's been lot of my time coding these days.
Ahhh, I see now... after rereading and understanding your dark orange text up there... now, now... thank you so much Kasumi!!! Brilliant! I'm a step closer now! I'm in for some more gettin' dirty coding, I think.
Is there a simple way to do this? I'm trying to make a simple solution.
Have a counter that counts upwards each run. Calculate counter AND 7, if result is zero, lda t6+1, otherwise lda t6. If counter starts at zero this will load t6+1 on the first run too. If you don't want that you can initialize the counter to a different value.
Using branch also loses some maintainability (in case the code above changes so that the zero flags value isn't a constant anymore). I tend to avoid this optimization. It sure would be nice to be able to do runtime assertions... (I'm considering implementing something like that in NintendulatorDX).
Emulator-side runtime assertions are implemented in FCEUX.
runTimeAssert "A == 0 && C"
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.
There's the ^ code that shows the addresses.
WHY IS $002D AT #$00?????????