nesdev.com
https://forums.nesdev.com/

8x16 and whatever else unreg wants to know
https://forums.nesdev.com/viewtopic.php?f=10&t=7451
Page 45 of 97

Author:  3gengames [ Thu Jul 26, 2012 8:02 pm ]
Post subject: 

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.

Author:  Kasumi [ Fri Jul 27, 2012 2:05 am ]
Post subject: 

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.

Author:  unregistered [ Sat Jul 28, 2012 3:17 am ]
Post subject: 

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.

Author:  Kasumi [ Sat Jul 28, 2012 7:03 am ]
Post subject: 

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.
Quote:
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.

Author:  unregistered [ Fri Aug 03, 2012 10:20 am ]
Post subject:  Re:

Kasumi wrote:
Quote:
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...

Author:  unregistered [ Thu Aug 09, 2012 4:30 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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, on the previous page, 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 :)

Author:  unregistered [ Mon Aug 13, 2012 10:07 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

On the previous page, 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? :?

Author:  tokumaru [ Mon Aug 13, 2012 10:29 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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.

Author:  unregistered [ Mon Aug 13, 2012 12:18 pm ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

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

Author:  unregistered [ Wed Aug 15, 2012 8:55 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

What are these .deb files? There is one for each new .nes file.... why? :)

Author:  3gengames [ Wed Aug 15, 2012 8:58 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

They're just debug files made when you use FCEUX's debugger.

Author:  tokumaru [ Wed Aug 15, 2012 9:47 am ]
Post subject:  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.

Author:  Shiru [ Wed Aug 15, 2012 9:51 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

The same here.

Author:  tepples [ Wed Aug 15, 2012 9:57 am ]
Post subject:  Re: 8x16 sprite is really a 16x32 pixel image?

How else would you recommend saving breakpoints from one run to the next?

Author:  3gengames [ Wed Aug 15, 2012 10:02 am ]
Post subject:  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.

Page 45 of 97 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/