fire - NESdev BBS

fire
by lynxsolaris on 2006-03-01 (#10256)

Just wondering ... in the original Legend of Zelda ... what gives the fire in the dungeons that flickering look? Is it like load flame sprite set one ... count down (with like a bne loop) and then load flame sprite two and have that repeat over and over?

Thanks.

by Celius on 2006-03-01 (#10258)

are you referring to this fire?:

I think they just flip the sprite horizontally to make it look like a dancing flame. They probably do it like this:

Say here's the flame (this fire looks horrid...)

You'd want to store $40 in the sprite's attribute byte to get it to flip. But if your not careful, if you store $40 in every sprite attribute making up that flame, it will look like this:

But say this is what tiles make up the sprite:

00 01
02 03

You'd want to switch those tiles around, and then flip it. Like this:

01 00
03 02

And you'd get this lovely image:

They probably change the attribute from $00 to $40 and from $40 to $00 and swap tile indexes like every 10, 15 frames or so. I don't know for sure, but it looks like that's what they do.

Am I talking out of my ass? Or am I making any sense?

by Quietust on 2006-03-01 (#10259)

To summarize: there is only one set of sprites (4 tiles total) used for the flame, and the animation is accomplished solely by mirroring the graphic horizontally (by using the appropriate sprite attribute bit AND swapping the left and right halves).

by lynxsolaris on 2006-03-01 (#10260)

thanks for the explaination. where would code like that usually take place? main loop, NMI ?

by Celius on 2006-03-01 (#10261)

Probably NMI. Usually things like this happen in an NMI routine. And since it has to do with sprites, and dealing with sprite DMA, it'd probably be best that it'd be in NMI.

by Dwedit on 2006-03-02 (#10262)

Personally, I'd put it in the Game Logic, as what a fire object does during its turn, or better yet, separate animation logic from game logic.

by tokumaru on 2006-03-02 (#10264)

lynxsolaris wrote:
thanks for the explaination. where would code like that usually take place? main loop, NMI ?

It really depends. The quick way to have something happen at the constant rate of 60 times per second (once per frame) is by putting it in the NMI. So, if you do the "flame logic" somewhere in the NMI it will work just fine. But as your project grows bigger, you'll want to avoid putting much stuff inside the NMI, so it doesn't get too big and there is a risk that 2 NMI's will overlap (you saw how overlaping NMI's can be nasty).

Eventually you'll want to put this along with the main game logic, where you'll also be processing the player's movements and collisions, physics, enemy/object AI, and all that stuff. And you'll probably want all that outside of the NMI. Some commercial games do have all their logic inside NMI, though. I guess that if you keep a "last NMI ended fine" flag and check it at the start of every NMI you can have all your code there, because if an NMI starts before the last one finished it will just detect that and RTI. And you'd lose a frame, as expected.

by lynxsolaris on 2006-03-02 (#10269)

Thanks for the information.