8x16 and whatever else unreg wants to know

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

I'd suggest going back and finding where the A 19 times bug as, as there shouldn't be any reason that happens, especially in such an odd circumstance. 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.
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Post by Kasumi »

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.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

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've thought about this very much; thank you for telling me! :D
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.
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! :lol: 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: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.
Thank you for this great advice Kasumi! :D

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.
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Post by Kasumi »

unregistered wrote: I was floored when I read this... so happy because maybe if I could fix this it could start working again.
Well, it'll do exactly nothing if the RAM isn't used elsewhere.
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?
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.

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.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re:

Post by unregistered »

Kasumi wrote:
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?
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.
Kasumi, thank you so much for answering my question! :D
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.
Ok... my previous scrolling code is no longer there. But, the blinking that happens after 19 presses of the A button still occurs... :?
I hope this will work out good...
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

After much trying I was blessed to find the solution!!!!!! :D
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.
Wow, thank you Kasumi so very much for these brilliant bits of knowledge! :mrgreen: I tried to follow these steps....... they were the path! :D Now I can press the A button an unlimited amount of times and it always ends well! NO BLINKING anymore!! :D :D :D
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.
I used a bcs and it works!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! :D :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

[color=#FFFF00]On the previous page,[/color] unregistered wrote:
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.
Hmm... :|
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? :?
Last edited by unregistered on Mon Aug 13, 2012 12:21 pm, edited 1 time in total.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 sprite is really a 16x32 pixel image?

Post by tokumaru »

unregistered wrote:But, draw_sprite writes to $0200-02FF... and that shouldn't be done outside of vblank, right? :?
$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
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

tokumaru wrote:
unregistered wrote:But, draw_sprite writes to $0200-02FF... and that shouldn't be done outside of vblank, right? :?
$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.
YES!! THANKS SO MUCH TOKUMARU! :D
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 sprite is really a 16x32 pixel image?

Post by unregistered »

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.
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by 3gengames »

They're just debug files made when you use FCEUX's debugger.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 sprite is really a 16x32 pixel image?

Post by tokumaru »

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.
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by Shiru »

The same here.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 sprite is really a 16x32 pixel image?

Post by tepples »

How else would you recommend saving breakpoints from one run to the next?
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Re: 8x16 sprite is really a 16x32 pixel image?

Post by 3gengames »

Maybe putting it in it's own file directory and not in your projects directory, like it does with snapshots and such.
Post Reply