8x16 and whatever else unreg wants to know
Moderator: Moderators
Something I just thought of, (and I feel bad especially after harping so much to use temp RAM) is that you probably should not be using temp RAM in draw_sprite because that's run during your NMI.
If something that's not in your NMI uses those variables, and then the NMI interrupts and changes them before that something is done, bad things can happen.
But, something big I haven't seen must be up for the A button press thing. I can't even think of a theory for that one.
Edit: But I can say this. You've essentially got a check to make sure aFrame isn't an unsafe value. I can think of two things that aren't too great about how you're doing it.
One: You never fix aFrame if it's out of bounds!
Two: It's probably better to check/fix aFrame near whatever code actually updates its value.
I don't think doing so would fix your problem, but I do think it makes more sense.
If something that's not in your NMI uses those variables, and then the NMI interrupts and changes them before that something is done, bad things can happen.
But, something big I haven't seen must be up for the A button press thing. I can't even think of a theory for that one.
Edit: But I can say this. You've essentially got a check to make sure aFrame isn't an unsafe value. I can think of two things that aren't too great about how you're doing it.
One: You never fix aFrame if it's out of bounds!
Two: It's probably better to check/fix aFrame near whatever code actually updates its value.
I don't think doing so would fix your problem, but I do think it makes more sense.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
I've thought about this very much; thank you for telling me!3gengames wrote:Patching code like that with fixes you don't know why they work instead of fixing it will make bad code quickly that's harder to manage.
I was floored when I read this... so happy because maybe if I could fix this it could start working again. Then I got distracted by our food... it was good. Then the olympic opening ceremony was great when the queen arrived in the stadium in a Bond way... and when Mr. Bean showed up! He kept pressing that key on the keyboard! Hahahahahaha. And then I lost more time from the DragonBallGT movie. And then was distracted even more because Paul McCartney preformed Hey Jude toward the end of the ceremonies. It wasn't a night for progress on the videogame. But this early saturday morning is helpful! I've failed at finding a non NMI use of thoese temporary variables... so I renamed them VBt0 and VBt2 so it is very clear that they are used only in the NMI... vblank.Kasumi wrote:Something I just thought of, (and I feel bad especially after harping so much to use temp RAM) is that you probably should not be using temp RAM in draw_sprite because that's run during your NMI.
If something that's not in your NMI uses those variables, and then the NMI interrupts and changes them before that something is done, bad things can happen.
Thank you for this great advice Kasumi!Kasumi wrote:But, something big I haven't seen must be up for the A button press thing. I can't even think of a theory for that one.
Edit: But I can say this. You've essentially got a check to make sure aFrame isn't an unsafe value. I can think of two things that aren't too great about how you're doing it.
One: You never fix aFrame if it's out of bounds!
Two: It's probably better to check/fix aFrame near whatever code actually updates its value.
I don't think doing so would fix your problem, but I do think it makes more sense.
Now... I think I'll have to rewrite my scrolling code... when you rewrite code do you have to be prevented from thinking about the code you already wrote? I'm confused ...and tired... to sleep. Good morning to yall. Guh have to be up in 15 minutes... we'll be off to New Orleans.
Well, it'll do exactly nothing if the RAM isn't used elsewhere.unregistered wrote: I was floored when I read this... so happy because maybe if I could fix this it could start working again.
No. You can keep in mind what you think worked so the process goes faster. But as you reimplement each small part, verify it works exactly as expected before moving on.Now... I think I'll have to rewrite my scrolling code... when you rewrite code do you have to be prevented from thinking about the code you already wrote?
When it doesn't, you'll generally have much fewer things it could be, because everything you wrote before should work. It was already checked.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re:
Kasumi, thank you so much for answering my question!Kasumi wrote:No. You can keep in mind what you think worked so the process goes faster. But as you reimplement each small part, verify it works exactly as expected before moving on.Now... I think I'll have to rewrite my scrolling code... when you rewrite code do you have to be prevented from thinking about the code you already wrote?
Ok... my previous scrolling code is no longer there. But, the blinking that happens after 19 presses of the A button still occurs...Kasumi wrote:When it doesn't, you'll generally have much fewer things it could be, because everything you wrote before should work. It was already checked.
I hope this will work out good...
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
After much trying I was blessed to find the solution!!!!!!
Wow, thank you Kasumi so very much for these brilliant bits of knowledge! I tried to follow these steps....... they were the path! Now I can press the A button an unlimited amount of times and it always ends well! NO BLINKING anymore!!Kasumi wrote: Edit: ... You've essentially got a check to make sure aFrame isn't an unsafe value. I can think of two things that aren't too great about how you're doing it.
One: You never fix aFrame if it's out of bounds!
Two: It's probably better to check/fix aFrame near whatever code actually updates its value.
I used a bcs and it works!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!Kasumi[color=#FFFF00], on the previous page,[/color] wrote:For unsigned subtracting, the carry is clear when the result (in actual arithmetic, forgetting all the byte stuff) would have been negative. Otherwise, it's set.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
So draw_sprite should be moved out of vblank enitrely... if that's possible? But, draw_sprite writes to $0200-02FF... and that shouldn't be done outside of vblank, right?[color=#FFFF00]On the previous page,[/color] unregistered wrote:Hmm...Kasumi wrote:On another note: Provided I'm understanding it correctly, draw_sprite seems to be updating at least part of $0200-02FF. But you run update_sprite (which actually copies the sprite's data from $0200-$02FF) before it. This means whatever draw_sprite is writing will only appear during the NEXT vblank.
Edit: Hmm... I guess this DOES keep updates that don't need to be done before rendering after things that do which is good. But, I'd recommend moving it out of vblank entirely if that's possible.
Last edited by unregistered on Mon Aug 13, 2012 12:21 pm, edited 1 time in total.
Re: 8x16 sprite is really a 16x32 pixel image?
$0200-$02FF is CPU memory and has absolutely nothing to do with the PPU, so it can be accessed at all times without problems. It's the sprite DMA (which copies the contents of $0200-$02FF to the OAM) that must take place during VBlank.unregistered wrote:But, draw_sprite writes to $0200-02FF... and that shouldn't be done outside of vblank, right?
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
YES!! THANKS SO MUCH TOKUMARU!tokumaru wrote:$0200-$02FF is CPU memory and has absolutely nothing to do with the PPU, so it can be accessed at all times without problems. It's the sprite DMA (which copies the contents of $0200-$02FF to the OAM) that must take place during VBlank.unregistered wrote:But, draw_sprite writes to $0200-02FF... and that shouldn't be done outside of vblank, right?
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: 8x16 sprite is really a 16x32 pixel image?
What are these .deb files? There is one for each new .nes file.... why?
Last edited by unregistered on Wed Aug 15, 2012 9:01 am, edited 1 time in total.
Re: 8x16 sprite is really a 16x32 pixel image?
They're just debug files made when you use FCEUX's debugger.
Re: 8x16 sprite is really a 16x32 pixel image?
Every time you use the debugger with a game an annoying .deb file is created. I find that really annoying when I'm developing, so I added a command to delete .deb files in the batch file that assembles the project.
Re: 8x16 sprite is really a 16x32 pixel image?
The same here.
Re: 8x16 sprite is really a 16x32 pixel image?
How else would you recommend saving breakpoints from one run to the next?
Re: 8x16 sprite is really a 16x32 pixel image?
Maybe putting it in it's own file directory and not in your projects directory, like it does with snapshots and such.