Link's Sword Animation -- ? Technical data ?

Go down

Link's Sword Animation -- ? Technical data ? Empty Link's Sword Animation -- ? Technical data ?

Post by ZoriaRPG on Mon 1 Apr 2019 - 10:58

This will probably be a bit out of the normal range of topics here, but I expect that if anyone knows the specifics on how Link's sword animation functions, the Z3 RH wizards would be the most likely to be able to answer.

What I'd like to know, is all of the following:
What mathematical process is actually used in-game to position the sword? Is this a vector-based or sine/cosine pattern, or for Z3 manually position it based on a clk, and the current animation frame?

If the former, do any of you have a representation of that calc, that can be transcribed into C-style syntax?

If the latter, do any of you have docs on the number of frames of animation, the clock timer, and the positional offsets to Link's sprite in each frame (for his given valid directions)?

I could probably reverse-engineer some of this based on positional data from screenshots taken over a given number of game frames, but I would prefer knowing the precise model that the game logic is using for it.

Many thanks. -Z
ZoriaRPG
ZoriaRPG
Bee
Bee

Since : 2019-04-01

http://zeldaclassic.com

Back to top Go down

Link's Sword Animation -- ? Technical data ? Empty Re: Link's Sword Animation -- ? Technical data ?

Post by Puzzledude on Mon 1 Apr 2019 - 11:16

If the former, do any of you have a representation of that calc, that can be transcribed into C-style syntax?
This is called tracing, you trace the code with a debugger and swing the sword and the debugger will stop and point you to the code giving you a SNES address and what is executed. Of course the result will be ASM. So you need to go to that address via hex editor and see the code in hex and then disassemble it. But you will get an ASM code, rather than a C or C+ programming language.

If the latter, do any of you have docs on the number of frames of animation, the clock timer, and the positional offsets to Link's sprite in each frame (for his given valid directions)?
I believe the user SunGodPortal made a sprite hack in which he changed all Link's states with numbers. So you use this hack, swing the sword in slowmotion emulation and look up the frame numbers, which are then visible in the .bin file, where the entire gfx is decompressed to. This is how you know which frames of the main sprite are used when using the sword, facing in all 4 directions. There is also a problem, since you have regular swing, hold sword/stab position and spin attack.

Why you want to tackle with this is beyond me though. This animation as well as the hit-collision of the sword is something that no ALTTP hacker would probably ever tackle with, since this is not a subject to change.
Puzzledude
Puzzledude

Link's Sword Animation -- ? Technical data ? Image213

Since : 2012-06-20

Back to top Go down

Link's Sword Animation -- ? Technical data ? Empty Re: Link's Sword Animation -- ? Technical data ?

Post by ZoriaRPG on Mon 1 Apr 2019 - 11:51

Puzzledude wrote:
If the former, do any of you have a representation of that calc, that can be transcribed into C-style syntax?
This is called tracing, you trace the code with a debugger and swing the sword and the debugger will stop and point you to the code giving you a SNES address and what is executed. Of course the result will be ASM. So you need to go to that address via hex editor and see the code in hex and then disassemble it. But you will get an ASM code, rather than a C or C+ programming language.

Well, aye, obviously, if I wanted to manually inspect the ASM, and I knew exactly what every address was doing, so that I know where to begin with this particular game, that'd all work out wonderfully.

That's why I asked if anyone happened to know the method that is used, before I have to do all of that as extra leg-work.

I would sort of expect manual positioning data--I only need the standard slash, not the spin or charging frame data--but I really don't know how the mechanics were designed here. I figured that some of you might.


I believe the user SunGodPortal made a sprite hack in which he changed all Link's states with numbers. So you use this hack, swing the sword in slowmotion emulation and look up the frame numbers, which are then visible in the .bin file, where the entire gfx is decompressed to. This is how you know which frames of the main sprite are used when using the sword, facing in all 4 directions. There is also a problem, since you have regular swing, hold sword/stab position and spin attack.

Why you want to tackle with this is beyond me though. This animation as well as the hit-collision of the sword is something that no ALTTP hacker would probably ever tackle with, since this is not a subject to change.

Hmm, that would certainly be a useful interim solution. I don't need to regard the actual phase of Link's animation. I simply need to know how the sword moves relative to his in-game x/y, and how it is timed.

Practical application? Within the context of the Z3 ASM, very little. I haven't touched 65C816 in over 25 years, for anything practical. I used to programme for the //gs platform, once upon a time, but in this circumstance, I'd like to plot an accurate representation to transplant into ZQ 2.55.

I could probably reference how Christopho did it in Solarus, but that is a complete OOP nightmare, and reviewing the src for it is more work than figuring it out from a SNES debugger would ever be, simply because of the size and general structure of the engine basecode.

I was hoping to simplify the matter. If no-one knows, that's fine, but perhaps someone does. Worst case, is that I end up with a simularcum thats as close as it 'needs' to be to satisfy the userbase.

Perhaps one of these aeons, I'll get back into romhacking, but I spend 50hrs a week as-is dedicating time to open-source projects, so, time for that sort of thing is scarce.


Last edited by ZoriaRPG on Mon 1 Apr 2019 - 11:57; edited 1 time in total (Reason for editing : Typo correction; clarification.)
ZoriaRPG
ZoriaRPG
Bee
Bee

Since : 2019-04-01

http://zeldaclassic.com

Back to top Go down

Link's Sword Animation -- ? Technical data ? Empty Re: Link's Sword Animation -- ? Technical data ?

Post by eyeballkid on Thu 4 Apr 2019 - 3:09

ZoriaRPG wrote:
I could probably reference how Christopho did it in Solarus, but that is a complete OOP nightmare, and reviewing the src for it is more work than figuring it out from a SNES debugger would ever be, simply because of the size and general structure of the engine basecode.

I might be wrong, but I don't think you need to look at the source code at all.

Here's one of the sprite sheets used:
https://github.com/solarus-games/solarus-alttp-pack/blob/master/data/sprites/hero/sword.sword2.png

Here's the mapping:
https://github.com/solarus-games/solarus-alttp-pack/blob/master/data/sprites/hero/sword2.dat

What the engine does is just check whether the sword sprite touches something (enemy, switch, etc.). The math you are looking for is in how the sprite sheet is made. Which makes me think you could extract it from there, instead of the ALttP rom...
eyeballkid
eyeballkid

Link's Sword Animation -- ? Technical data ? Image213

Since : 2016-12-26

Back to top Go down

Link's Sword Animation -- ? Technical data ? Empty Re: Link's Sword Animation -- ? Technical data ?

Post by ZoriaRPG on Sun 7 Apr 2019 - 9:37

eyeballkid wrote:
ZoriaRPG wrote:
I could probably reference how Christopho did it in Solarus, but that is a complete OOP nightmare, and reviewing the src for it is more work than figuring it out from a SNES debugger would ever be, simply because of the size and general structure of the engine basecode.

I might be wrong, but I don't think you need to look at the source code at all.


Code:

directions = {

    { x = 0, y = 0, frame_width = 72, frame_height = 72, origin_x = 36, origin_y = 43, num_frames = 12 },

    { x = 0, y = 72, frame_width = 72, frame_height = 72, origin_x = 36, origin_y = 43, num_frames = 12 },

    { x = 0, y = 144, frame_width = 72, frame_height = 72, origin_x = 36, origin_y = 43, num_frames = 12 },

    { x = 0, y = 216, frame_width = 72, frame_height = 72, origin_x = 36, origin_y = 43, num_frames = 12 },

  },

Nay, it is pretty much useless information. Those are clearly just the initial position on the sprite sheet for each of the four directions that it can face, to derive a base tile value, that something else will modify when the sword sprite is positions, and its frame clock advances.

I don't know how the engine uses the array data in that file, to accomplish its slash.

It is purely the graphical data, not the object positioning, nor the hitbox position, both of which which must be elsewhere.

I'd honestly just make an array of positions and tiles, if I didn't care about it being accurate to the SNES. (Basically, what I'm looking for here, is if the original 816 code moved the sprite in some kind of arc, or if it used fixed position points relative to Link's sprite.)

I don't actually need to care about the graphics at all: Once I figure out the movement, and the number of frames for which the sprite lives, I can make any given frame use a specific tile, based on direction from a 2D array:

Code:
int swordframes[DIR][FRAMES]; //Graphical data
int swordpositions[DIR][FRAMES][2]; //Positional data

At that point, I would be using a clk, and on the nth frame, it reads the nth index of each array (twice for swordpositions, to get a specific x and y offset), then write the new x, y, and tile to the sprite.

That's entirely different from moving it on a calculated arc.

ZoriaRPG
ZoriaRPG
Bee
Bee

Since : 2019-04-01

http://zeldaclassic.com

Back to top Go down

Link's Sword Animation -- ? Technical data ? Empty Re: Link's Sword Animation -- ? Technical data ?

Post by eyeballkid on Sun 7 Apr 2019 - 12:42

ZoriaRPG wrote:
Nay, it is pretty much useless information. Those are clearly just the initial position on the sprite sheet for each of the four directions that it can face, to derive a base tile value, that something else will modify when the sword sprite is positions, and its frame clock advances.

I don't know how the engine uses the array data in that file, to accomplish its slash.

It is purely the graphical data, not the object positioning, nor the hitbox position, both of which which must be elsewhere.

I never said it was anything but how to cut the sprite sheet into pieces?!
And, yes, as I also said already: this is purely the graphical data. From which I think you can extract what you are after...

I'd assume the engine simply always puts one corner or the center at a fixed position compared to Link's position... Hence, the arc you are talking about is encoded in the sprites themselves. As for the hitbox, it could be as trivial as everything non-transparent is the sprite.


ZoriaRPG wrote:
I'd honestly just make an array of positions and tiles, if I didn't care about it being accurate to the SNES. (Basically, what I'm looking for here, is if the original 816 code moved the sprite in some kind of arc, or if it used fixed position points relative to Link's sprite.)

How do you know this is how it works in the ROM?


ZoriaRPG wrote:
I don't actually need to care about the graphics at all: [...]

I never suggested that you should.


ZoriaRPG wrote:
That's entirely different from moving it on a calculated arc.

Yet you can map out the position in this arc from the sprite, just as you suggest that you can put a sprite on the arc once you know it's mathematical function.
eyeballkid
eyeballkid

Link's Sword Animation -- ? Technical data ? Image213

Since : 2016-12-26

Back to top Go down

Link's Sword Animation -- ? Technical data ? Empty Re: Link's Sword Animation -- ? Technical data ?

Post by ZoriaRPG on Mon 15 Apr 2019 - 17:55

eyeballkid wrote:

I never said it was anything but how to cut the sprite sheet into pieces?!
And, yes, as I also said already: this is purely the graphical data. From which I think you can extract what you are after...

Thanks, but no. It's not useful data.

eyeballkid wrote:
I'd assume the engine simply always puts one corner or the center at a fixed position compared to Link's position... Hence, the arc you are talking about is encoded in the sprites themselves. As for the hitbox, it could be as trivial as everything non-transparent is the sprite.

The motion of the weapon (Solarus engine) is either hardcoded to sword objects, or it is a Lua script. Nothing is 'encoded' into a sprite. Collision like that really hasn't existed since the Atari 800. I wrote an engine recently that emulated this mechanic, in C-style code, using bitmap pixel reads to distinguish a specific colour pattern.

In general, if a foreground object wants to move, and the pixel to which it is about to move is not a bacground colour, it is about to collide with that other object. What I did, was basically similar to Berzerk, and it's purely for the purpose of showing a younger generation how this works.

See the old Atari docs on sprites, and missiles from the 5200/400/800 if you are curious: This differs radically from the 2600. Ahyway, that is certainly how we did this stuff decades ago. Now, you normally define four points for 2D, and 6 points for 3D objects (a rect, or a box, respectively), and check for overlap, often with a Pythagorean equation.

eyeballkid wrote:
ZoriaRPG wrote:
I'd honestly just make an array of positions and tiles, if I didn't care about it being accurate to the SNES. (Basically, what I'm looking for here, is if the original 816 code moved the sprite in some kind of arc, or if it used fixed position points relative to Link's sprite.)

How do you know this is how it works in the ROM?

I do not know how the movement works in-ROM. The specific reason that I posted this topic to the ROMhacking forum for Z3, was specifically to inquire how the original game handled this, versus trying to mimic it. I would prefer to implement this in the same manner as the original Z3 65C816 code did, but I naturally can do it in other ways that are similar, if not properly accurate.

I don't see it likely that I'll get the answer that I seek, so I will either need to go through the ASM and figure out what it is doing--not all that viable, because AFAIK, commented disassembly does not exist for this, and all I'd see are instructions to position the sprite, but not the method by which it occurs.

It was a long-shot, at best.
ZoriaRPG
ZoriaRPG
Bee
Bee

Since : 2019-04-01

http://zeldaclassic.com

Back to top Go down

Link's Sword Animation -- ? Technical data ? Empty Re: Link's Sword Animation -- ? Technical data ?

Post by eyeballkid on Tue 16 Apr 2019 - 2:23

I still think that looking at the sprite sheet and the actual animation in-game frame by frame would allow to reconstruct how it's working. But I understand/understood that you are after the actual assembler code.

Btw. "As for the hitbox, it could be as trivial as everything non-transparent is the sprite." was meant for Solarus, not for ALttP...

Anyway, maybe you want to directly ask the authors of Solarus how they do it? Or even where/how they sourced their method...
eyeballkid
eyeballkid

Link's Sword Animation -- ? Technical data ? Image213

Since : 2016-12-26

Back to top Go down

Link's Sword Animation -- ? Technical data ? Empty Re: Link's Sword Animation -- ? Technical data ?

Post by P-Tux7 on Wed 17 Apr 2019 - 17:08

I thought there was a disassembly of one of the LTTP ROMs, wasn't there?

P-Tux7
Rope
Rope

Since : 2018-11-12

Back to top Go down

Back to top


 
Permissions in this forum:
You cannot reply to topics in this forum