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.
fire
Moderator: Moderators
-
- Posts: 2158
- Joined: Sun Jun 05, 2005 2:04 pm
- Location: Minneapolis, Minnesota, United States
- Contact:
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?
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?
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).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
- lynxsolaris
- Posts: 143
- Joined: Tue Jan 17, 2006 10:39 am
- Location: North Carolina
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).lynxsolaris wrote:thanks for the explaination. where would code like that usually take place? main loop, NMI ?
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.
- lynxsolaris
- Posts: 143
- Joined: Tue Jan 17, 2006 10:39 am
- Location: North Carolina