Project: Framedisplay for [U] version

[Madao]

If the frame display is down for good, we could re-upload it excluding the pics, keeping whatever it's necessary for it to work.


Ok, thanks for that.
I don't really care about the invincible frames of the upsmashes, I think that having the unique stuff from each character is more important, like having the shine cancel for Fox, parry for Yoshi, etc.

Can't I measure aerials with your frame counter in the cheat engine? I used that with Samus' Bair and got 39, which is the same number of frames shown in the Frame Display program. (I couldn't get to 39 reading Toomai's chart)

Frame display program is still available, I just don't know why the links keep changing lol. Frame counter works great, except for things that are long, like edge recovery. For those you have to use 2 frame counters instead of one. The best method is to use the Player 1 frame counter for most things, because it goes to 0 everytime you do a new action (although I think the frame number starts at 0, so keep that in mind for the numbering). When you want to measure things like edge recovery, then you manually set player 2 aerial counter to the same value as the player 1 frame counter, then you just keep going until you see player 1 frame counter reset to 0 after doing the last part of the action. You can use the yoshi chart as a reference, and test out edge recovery to see how I did it. I just figured that using the frame counter might be confusing (which it is, but I got the hang of it now).

Just thought about something... From when do you start recording? Do you include the frame delay or not? What I've done so far (I hope it's right) is load a save file with the game paused, input the attack, then run the command, so it includes the frame delay.

I don't include the frame delay, except for running attacks, which has an extra delay. I haven't seen any gif's that include it, so I did it like everyone else did (including the japanese frame display).

 

[mixa]

Just thought about something... From when do you start recording? Do you include the frame delay or not? What I've done so far (I hope it's right) is load a save file with the game paused, input the attack, then run the command, so it includes the frame delay.

This was the first thing I noticed when I opened that program, they didn't include the frame delay. I think it's better to include, but this is just an arbitrary preference.

And I remember reading this in some thread but I forgot, why are we counting all the frames prior to recording the moves?

 

[Sangoku]

Ah so since I've recorded it, I've missed the last frame... I'll redo it all again.

Oh so should I include it or not? If so I assume I'll just have to add 1 to Madao's values?

Counting frame beforehand allows to record only the needed number of frames.

Edit: I don't get it though, the numbers you gave are including the frame delay, I checked by jumping afterward.

Edit 2: No, actually it includes two empty first frames since the script starts with an F12... So we have the first screenshot on the frame of input, the next frame which is the frame delay, then the attack starting.

ARGHHGHOSRHGNSH I'm completely lost. Is it normal your numbers include 2 empty frames?

 

[Madao]

Ah so since I've recorded it, I've missed the last frame... I'll redo it all again.

Oh so should I include it or not? If so I assume I'll just have to add 1 to Madao's values?

Counting frame beforehand allows to record only the needed number of frames.

Edit: I don't get it though, the numbers you gave are including the frame delay, I checked by jumping afterward.

Well, idk because I don't think we fully understand the input delay. Also most other people skip the input delay. It would be confusing for half the people to include the 1 frame input delay, and the other half to skip it. If you prefer to add it, then it's fine, but I'd want to figure out how the input delay works before I add it in because it's still confusing to me lol. Also, all it would show is one frame of you not doing anything.

 

[Sangoku]

Well, idk because I don't think we fully understand the input delay. Also most other people skip the input delay. It would be confusing for half the people to include the 1 frame input delay, and the other half to skip it. If you prefer to add it, then it's fine, but I'd want to figure out how the input delay works before I add it in because it's still confusing to me lol. Also, all it would show is one frame of you not doing anything.

Actually 2 frames if you saw my edit

Then I can not include them but I need to subtract 2 from your numbers, right?

 

[Madao]

Actually 2 frames if you saw my edit

Then I can not include them but I need to subtract 2 from your numbers, right?

Sigh, I need to do some mupen testing then. I used Nemu for my frame data (since breakpoints are faster than going frame by frame). With Nemu, when I need frame by frame mode, the 2nd frame is the start of the attack. Say I pause it in Nemu, and hold Up A, after advance frames 2 times, that is frame #1 for most people (the start of the actual move). I'm pretty sure the timing is the same in mupen.

Also, are you using fraps or mupens screenshot? Fraps works a little weird where if you screenshot while it's paused, it will record the next frame and not the current one, so the timing also depends on what your screenshot method is. Also you should use the japanese frame display as a reference whenever you get confused. It will also help you determine whether it's worth adding the extra frame delay or not, since you can compare the difference. For instance, some attacks give you invulnerability at the beggining of the attack, so you will see what it looks like to add the input delay frame, or not. I will double check in mupen right now. Don't start recording until you figure out whether or not you are going to add the input delay or not.

 

[Sangoku]

Sigh, I need to do some mupen testing then. I used Nemu for my frame data (since breakpoints are faster than going frame by frame). With Nemu, when I need frame by frame mode, the 2nd frame is the start of the attack. Say I pause it in Nemu, and hold Up A, after advance frames 2 times, that is frame #1 for most people (the start of the actual move). I'm pretty sure the timing is the same in mupen.

Exactly, that's why if I start recording when inputting the move, I have two empty frames to begin with. But with this method, it ends at the perfect time.

Also, are you using fraps or mupens screenshot? Fraps works a little weird where if you screenshot while it's paused, it will record the next frame and not the current one, so the timing also depends on what your screenshot method is. Also you should use the japanese frame display as a reference whenever you get confused. It will also help you determine whether it's worth adding the extra frame delay or not, since you can compare the difference. For instance, some attacks give you invulnerability at the beggining of the attack, so you will see what it looks like to add the input delay frame, or not. I will double check in mupen right now. Don't start recording until you figure out whether or not you are going to add the input delay or not.

I'm using Mupen =/. The Japanese one has empty frames at the end of the moves (which is worse than the beginning ones IMO, since the beginning ones are actually what you get ingame after you input a move). Also they have sometimes weird things, such as Yoshi's second jab starting with a hitbox out the first frame.

Actually, I don't think it's such a bad thing to have those two empty frames in the beginning, so I'll continue that way.

Oh and I had already recorded half the moves for Yoshi lol. (with the 2 empty frames in the beginning)

 

[mixa]

I did this because I was getting confused too.


Yoshi Jab 1:

0. <input A>
1. frame delay
2. move starts
3
4. hitbox appears
5
6. last hitbox frame
7
(...)
21
22. move ends - last frame of lag
23. <input shield>
24. frame delay
25. parry starts - Yoshi is green

If you count from when the move starts (no frame delay), it's from frame 2 to 22 = 21 frames

Edited***
I had put 20 frames total

 

[Madao]

Exactly, that's why if I start recording when inputting the move, I have two empty frames to begin with. But with this method, it ends at the perfect time.

I'm using Mupen =/. The Japanese one has empty frames at the end of the moves (which is worse than the beginning ones IMO, since the beginning ones are actually what you get ingame after you input a move). Also they have sometimes weird things, such as Yoshi's second jab starting with a hitbox out the first frame.

Actually, I don't think it's such a bad thing to have those two empty frames in the beginning, so I'll continue that way.

Oh and I had already recorded half the moves for Yoshi lol. (with the 2 empty frames in the beginning)

As I suspected, Mupen pauses the emulator at a different point than Nemu does. This explains a lot of the confusion I had, (before, I would use Mupen for frame counting), but after I found good breakpoints, I decided to use nemu. It's no wonder why I was so confused lol. The delay appears to be the same between the 2 emulators (but the frame counter I use is off by 1), so I really was confused when it came to counting.

At least now we can put an end to the confusion. I tested Falcon's Up smash in Mupen. Say you pause the game while not holding any buttons, then you hold Up A, when you frame advance 2 times, that's the start of the attack. I would not recommend recording from when you paused (at the very least I'd start recording the next frame), since you didn't even input any buttons yet. This means that you have a choice between recording 1 extra frame of delay or not. When I pause the game, i start recording 2 frames later, but you can record at 1 frame later if you wish. As long as everyone knows whether you added the extra input delay or not.

 

[Sangoku]

mixa:
Yep, but by recording two frames early the numbers given by Madao fit perfectly (ie not ending too soon). And if you look at the Japanese FD, they use the no initial delay method, but their number of frames are the same as Madao's. This means they have 2 empty frames at the end instead of the beginning.

Wait I don't get it actually. It's not 20 frames in Japanese FD, it's 23.

Madao: yes I understood that since the beginning lol, but my question is then, do I subtract 2 systematically from your numbers? Because, as I said, they fit perfectly if we include the first two empty frames.

Edit: **** it, I'm done for today lol. These kind of details are killing me...

 

[mixa]

^ yes, my bad, I don't know what I was looking at, J FD has 23 for Yoshi's Jab 1 like you said.

This means they have 2 empty frames at the end instead of the beginning.

Ok, I think I know what they've done. It's on a loop.

If we measure Kirby's Utilt with no initial delay, it has 15 frames. But in the FD program, hitting spacebar makes the move reproduce itself over and over. Those 2 frames at the end serve to make this loop seem natural, had they left only 15 frames, you wouldn't have the input frame, or the delay frame. What happens:

On frame 15 Kirby is on his last frame of lag​

On frame 16 Kirby inputs Utilt​

On frame 17 we have the frame delay​

On frame 1, the attack starts.​

Had we stopped at frame 15 or 16, the looping would look broken.

Adding those 2 dead frames at the end simulates what a TAS Utilt spam would look like. It also means you can just look at the number 17 and conclude that it's possible to perform 1 Utilt each 17 frames.


Smart decision from the Japanese.

 

[Madao]

mixa:
Yep, but by recording two frames early the numbers given by Madao fit perfectly (ie not ending too soon). And if you look at the Japanese FD, they use the no initial delay method, but their number of frames are the same as Madao's. This means they have 2 empty frames at the end instead of the beginning.

Wait I don't get it actually. It's not 20 frames in Japanese FD, it's 23.

Madao: yes I understood that since the beginning lol, but my question is then, do I subtract 2 systematically from your numbers? Because, as I said, they fit perfectly if we include the first two empty frames.

Edit: **** it, I'm done for today lol. These kind of details are killing me...

Jab 1 is 23 frames for Yoshi (24 if you include the frame delay). I think the main confusion now is the 2 empty frames you're talking about. I did the shield buffer test, simply because I was confused. If I hold shield while doing Yoshi's jab, lets say you start with frame 0 which is input delay, frame 23 is the end of the move, 2 frames later (frame 25) you will see Yoshi turn green. So if you want to include input delay, just add 1 frame to each move. Tomorrow, just do the shield test and manually count the frames if you want to confirm when a move ends. Since it takes 2 frames for yoshi to turn green, I subtract the total by 2 if I'm counting frames using the shield buffer method.

Just don't screenshot that first frame you pause since you didn't even input anything. I hope this ends the confusion. The frame counter I use, goes to 0 everytime something ends, so it makes it easy for me to confirm when a move has ended.

Here's what you do if you want to include the frame delay. Yoshi's jab 1 = 23 + 1 = 24, so you pause the game, hold a, hit next frame, then start recording the 24 frames.

Since I skip the input delay, I pause the game, hold A, and hit next frame 2 times, and record 23 frames.

I should have brought up this frame delay issue much earlier, I just assumed no one else wanted to add that extra frame.

Lol jab 2 for Yoshi is confusing, because there is a frame delay in between the 2 jabs I believe that isn't included in the frame counter, i may have to change that. I find it interesting that I ended up doing the same method hijiki did, I bet he based the numbers off the frame counter too lol.

Ok, I think I know what they've done. It's on a loop.

If we measure Kirby's Utilt with no initial delay, it has 15 frames. But in the FD program, hitting spacebar makes the move reproduce itself over and over. Those 2 frames at the end serve to make this loop seem natural, had they left only 15 frames, you wouldn't have the input frame, or the delay frame. What happens:

Actually the 2 frames are the extra delay. You cannot do anything (aside from button input for the next frames) during these 2 frames. You can hold shield while doing utilt, and you won't see the shield until frame 18 (assuming frame 1 is the start of the attack).

 

[mixa]

Actually the 2 frames are the extra delay. You cannot do anything (aside from button input for the next frames) during these 2 frames. You can hold shield while doing utilt, and you won't see the shield until frame 18 (assuming frame 1 is the start of the attack).

Nooo... that means the japanese screenshots aren't standard. I assumed all moves had 2 dead frames at the end. ):

 

[Madao]

Nooo... that means the japanese screenshots aren't standard. I assumed all moves had 2 dead frames at the end. ):

I'm confused lol. Isn't it good to add them in? Since you cannot start another action until after frame 17. I'm prety sure the japanese frame display did the frames correct (aside from maybe jabs). I will have to do more testing on jabs.

Edit: When I said extra delay, I meant that your player state doesn't change until after those 2 dead frames.

 

[Sangoku]

Yeah mixa I get the idea behind that choice, so I guess we should do the same.

Madao, my problem is the following:
1: I pause
1: I input jab
1: nothing happens
1: I launch the script, so the first frame is recorded
2: nothing happens (frame delay)
3: jab starts
...
23: recording stops
23: I input shield
24: nothing happens (frame delay)
25: Yoshi turns green.

Conclusion: the move lasts 23 frames including the first two empty frames. So it should be 21 if we exclude them.

 

[mixa]

Madao, I misread you, sorry. Disregard my previous post, they're standard as far as I can tell (not sure about jabs).

But rereading the posts, we agree with each other. Except I was not calling the frame 16 and 17 delay because the move is over at 15. Nothing will come out until frame 18 because of the input frame + delay frame.

We should call it delay though, I guess. It's just a confusion I had: I would look at 17 and think "oh, so you're free to input anything at the next frame, frame 18"

I was thinking about if a frame data chart on moves should contain these 2 frames or not. I *guess* it should so the reader shouldn't have to do any math.

 

[Madao]

Yeah mixa I get the idea behind that choice, so I guess we should do the same.

Madao, my problem is the following:
1: I pause
1: I input jab
1: nothing happens
1: I launch the script, so the first frame is recorded
2: nothing happens (frame delay)
3: jab starts
...
23: recording stops
23: I input shield
24: nothing happens (frame delay)
25: Yoshi turns green.

Conclusion: the move lasts 23 frames including the first two empty frames. So it should be 21 if we exclude them.

Well if you want to exclude the 2 dead frames, then it's (my frame count -2 + your input delay). I thought everyone prefered to include the 2 dead frames since you cannot do anything other than buffer input for the frame after the 2 dead frames. In fact, if you exclude the 2 dead frames, you don't have to redo yoshi since I added the extra frames to the numbers. I hope you didn't delete your yoshi pictures ;/.

I was thinking about if a frame data chart on moves should contain these 2 frames or not. I *guess* it should so the reader shouldn't have to do any math.

I think for the frame chart, the 2 dead frames should be included, but for the frame display it's a matter of preference. I agree that the reader shouldn't have to do any math , which is why I considered doing <= and >= instead of < and > lol.

 

[Sangoku]

Wait, which two dead frames are you talking about? Ending ones? If so, then my recording hasn't them included, since I used the two extra frames at the beginning (cf. my previous post).

So do we agree that we should record from the moment the move starts (ie 2 frames after inputting something) until two frames after it ends because in theory the next move would be initiated (not input, but really started) the following frame?

I think that's the most logical way to do it, for the reason mixa gave. However, if that's the case, I really have to redo everything lol, but it's nothing, the longest part was to understand how to use this bulk rename program and how to make scripts.

 

[Madao]

Wait, which two dead frames are you talking about? Ending ones? If so, then my recording hasn't them included, since I used the two extra frames at the beginning (cf. my previous post).

So do we agree that we should record from the moment the move starts (ie 2 frames after inputting something) until two frames after it ends because in theory the next move would be initiated (not input, but really started) the following frame?

I think that's the most logical way to do it, for the reason mixa gave. However, if that's the case, I really have to redo everything lol, but it's nothing, the longest part was to understand how to use this bulk rename program and how to make scripts.

I was talking about the ending ones. So yes, if you want to including the 2 frames at the end, then you have to redo it. If you want to do it like most people have done, then you start at the moment the move starts and end 2 frames after it ends. I actually prefer it this way.
Just to be clear, I included the 2 frames after the end, so the only difference between my frame count and your frame count will be whether or not you include input delay and whether or not you include the ending 2 frames. I will have to look into Jab 2, so you should probably do Jab 2 last because i forgot to factor in the frame delay between jab1 and jab2.

I'm glad it seems you got the hang of the recording process as well as AHK. Most people (including myself) have a hard time learning how to use AHK when they first try it.

 

[Sangoku]

I finished Yoshi! Here is the yoshi folder to replace from the Japanese framedisplay in order to have it.

I didn't record every move (throws/get up attacks/etc.) because I don't know if we can add new moves to the Japanese program or if we can only modify the current ones.

The recording process really isn't that long/tedious. I guess the worst part is actually counting the frames beforehand lol.

What do you guys think of it? Are you satisfied with the current settings (mainly camera's)?

By the way, do you guys mind if I create a Framedisplay thread and move our messages there? I feel we're spamming this thread, since the original purpose of this one is for GIFs. It would be easier for everybody I think.

 

[mixa]

That was fast. Good stuff!

It seems that yes you can add new moves, since Madao's Fox has more moves than the original. I wouldn't know how simple the process is though. edit: ok, here's my illustrated guide:

Spoiler

I like the settings, great quality. I don't have a problem with the camera, if anything, some aerials' hitboxes went beyond what the camera could capture, but that's fine.

By the way, do you guys mind if I create a Framedisplay thread and move our messages there?

Agreed. Eventually this would need a thread of its own anyway.

 

[Madao]

Ya, I must say, you did a good job . The only thing different I'd like to see besides adding more moves, is the image sizes, but sometimes I have a silly habit of striving for perfection xD. Anyway, it's really up to you whether or not to make a separate thread, but I'm sure Fireblaster is cool with us bumping his thread.

The camera settings are nice, I like how it's more zoomed in than the japanese ones. The images load fast too. Oh another thing is, next time, translate the text for us . All you do is edit the state.txt file (that's also how you add new moves in).
I did the job for you this time though.
[collapse=State.txt]

Jab 1,a1
Jab 2,a2
Running Attack,da
Up Tilt,8a
Forward Tilt,6a
Forward Up Tilt,6a_shift1
Forward Down Tilt,6a_shift2
Down Tilt,2a
Up Smash,8s
Forward Smash,6s
Forward Up Smash,6s_shift1
Forward Down Smash,6s_shift2
Down Smash,2s
Nair,jna
Fair,j6a
Bair,j4a
Uair,j8a
Dair,j2a
Grab,grip
Neutral Special,nb
Up Special,8b
Down Special,2b

[/collapse]
Just copy it and paste it into the state.txt file inside of the yoshi folder.
It looks much better when it's in English.

 

[mixa]

Do any of you have a saved cheat engine file pre-set for recording? I thought of doing the parry manually to know if I can make Dream Land look like that before I get into the scripts, etc, but I can't seem to do it.

I couldn't make 2P disappear in Tranining mode (I could in VS)
I couldn't make the tree disappear completely: http://rook.codebrainshideout.net/img/images/mupen64rerecording201311102342.png

Also, if I take a screencap with Fraps .jpg, the file size is small but the quality isn't as good. What did you use to screencap, Sangoku? If you're using Mupen, what are your settings? My Mupen screenshots come out black.

 

[Madao]

Do any of you have a saved cheat engine file pre-set for recording? I thought of doing the parry manually to know if I can make Dream Land look like that before I get into the scripts, etc, but I can't seem to do it.

I couldn't make 2P disappear in Tranining mode (I could in VS)
I couldn't make the tree disappear completely: http://rook.codebrainshideout.net/img/images/mupen64rerecording201311102342.png

Also, if I take a screencap with Fraps .jpg, the file size is small but the quality isn't as good. What did you use to screencap, Sangoku? If you're using Mupen, what are your settings? My Mupen screenshots come out black.

I don't use a preset cheat engine script for changing the stage display. What I do is set middle bg to 0, then left click on "Lower Part of BG", scroll down to Bottom flower disabler, and hold shift then left click it, then press enter and set the value to 0. It will set all the highlighted variables to 0. For making player 2 invisible, you have to mess with the invisibility glitch variable. Like for me, as Falcon vs Falcon in dream land training mode, the normal value is 30, I change it to 80 and it makes player 2 invisible. Just try different numbers by 10 if 80 doesn't work (like 70,90,60, etc).

Lol i never noticed any significant difference in quality between fraps screenshot and mupen, but maybe it's my computer / plugin lol. I'm 99% sure Sangoku used Mupen to screencap. I will probably do more research on images, simply because it will be cool to use the best method possible. I know the fraps method does not produce the best quality possible, but when I screencap using printscreen (best quality that I know of), those images take longer to load in the frame display program. For gif's I know that printscreen is the way to go.

To fix the black screen, go to options, then video settings, then Rom settings, change Direct 3D Clear Mode from always to default (this is assuming you are using Jabo's Direct 3D6/3D8). Although if you decide to use fraps, using always is best because it clears that fps display from the screenshot.

 

[mixa]

gaaahhhh

I made the CPU get close to me, then forgot the camera moves.

Thanks for the answers, Madao.
How to lock the camera? I only found the Player 1 Camera Zoom which I had set and frozen to 0.

So, I still have to fix the image size, they're ~77kb each. That's kinda what Sangoku got, I suppose.
But they're way bigger than Madao's.

I don't know what we should settle for.

By the way, if you're Yoshi and want to make Fox disappear, the value for the invisibility glitch is F0.

 

[Madao]

I made the CPU get close to me, then forgot the camera moves.

Thanks for the answers, Madao.
How to lock the camera? I only found the Player 1 Camera Zoom which I had set and frozen to 0.

So, I still have to fix the image size, they're ~77kb each. That's kinda what Sangoku got, I suppose.
But they're way bigger than Madao's.

I don't know what we should settle for.

It's actually better to to use negative #'s for Player 1 camera zoom (if you want close up view). I usually use -10 for player 1 camera zoom and I also freeze player 2 camera to 0 or -1 depending on what I want. Just play with the numbers a bit so that you can set up the view to how you want, for each move (for instance I tweak the camera to have player 1 appear to the side, rather than the middle when I want to show projectiles).

Also just a reminder, if you want cheat engine to freeze values at a faster speed, go to edit, then general settings, then change the Freeze Interval to a smaller number if you wish.

This week, I'll spend a bit of time trying to figure out the best way to do images. So far the 3 methods I know are Fraps (small size but not best quality), Mupen (medium quality images, but bigger file size), and printscreen (size depends on your compression settings, but the quality is generally better and the main issue I have is the slower loading speed).

 

[Sangoku]

That was fast. Good stuff!

It seems that yes you can add new moves, since Madao's Fox has more moves than the original. I wouldn't know how simple the process is though.

Yup, I hadn't looked at Madao's file. Thanks for the guide, I'll add other moves (probably next weekend though ).

I like the settings, great quality. I don't have a problem with the camera, if anything, some aerials' hitboxes went beyond what the camera could capture, but that's fine.

Yeah, uair is tricky. I couldn't find convincing camera settings and changing the timing could help, but Yoshi would land before the end of the attack, which sucks.

Oh another thing is, next time, translate the text for us . All you do is edit the state.txt file (that's also how you add new moves in).

Oh I didn't know it was that easy, I thought it was a problem too. I'll do it, thanks!

Do any of you have a saved cheat engine file pre-set for recording? I thought of doing the parry manually to know if I can make Dream Land look like that before I get into the scripts, etc, but I can't seem to do it.

These are the settings I used (ordered by value):

Spoiler

0:
Bottom BG Part 2
Bottom Flower Disabler
Bottom Flowers
Bottom Part of BG
Dream Land Pool #2
DreamLand Pool #1
Hide Platform (2 = Hidden)
Left Fence
Lower Part of BG
Middle BG
P1 Shadow Radius
P2 Shadow Radius
Player 2 Camera Zoom
Remove Bottom BG
Right Fence
Top Flower Disabler
Top Flowers
Tree Eye Disabler
Tree Mouth
Tree Mouth Disabler
Tree eyes



40:
Invisibility Glitch


5555:
Dream Land Wind

-10:
Player 1 Camera Zoom

1:
Player 1 HUD
Player 1 Icon over Head
Player 1 Stock Icon
Player 2 HUD
Player 2 Icon over Head
Player 2 Stock Icon
Training Mode HUD #1 à 6




8/0:
Player 1 HitBox Code

Also, if I take a screencap with Fraps .jpg, the file size is small but the quality isn't as good. What did you use to screencap, Sangoku? If you're using Mupen, what are your settings? My Mupen screenshots come out black.

I used Mupen's screenshots. I have Jabo's Direct3D8 1.6 and default settings I guess. Windowed resolution 640x480, anisotropic filtering, full-scene antialiasing both off, brightness 100%, super2xsal textures, always use texture filter both unticked and advanced settings hidden.

Finally I don't think image method is really a concern to be honest. I think the method's efficiency is better, because if we choose a too complicated method, in the end we won't do the job. I know that with the current method, I wouldn't mind doing every character (provided I had the number of frames beforehand). Or I could easily do 5-6 with the counting.

 

[MCG]

I finished Yoshi! Here is the yoshi folder to replace from the Japanese framedisplay in order to have it.

I got inspired by your pictures and was curious to see how javascript could be used to display the animations. Turns out, not so great at normal speed (the image kinda flickers) but slower it's okay.

I'm not a programmer nor do I have much experience in programming (nor in javascript) but here's what it looks like :

Basically, put both this file (EDIT: link dead) and this file (EDIT: link dead) outside the /yoshi/ folder and activate javascript. As of right now, it only works for yoshi (because I didn't add the frame counts for the japanese moves).

 

[Sangoku]

I got inspired by your pictures and was curious to see how javascript could be used to display the animations. Turns out, not so great at normal speed (the image kinda flickers) but slower it's okay.

I'm not a programmer nor do I have much experience in programming (nor in javascript) but here's what it looks like :

Basically, put both this file and this file outside the /yoshi/ folder and activate javascript. As of right now, it only works for yoshi (because I didn't add the frame counts for the japanese moves).

Thanks for the input.

I downloaded both files and put them in the folder, but when I open the script nothing happens. Then if I open the html one, it opens in firefox and there's no animation. What am I doing wrong?

Also, is there an advantage of this method above replacing the Japanese files? Except from the potential copyright problem of using/modifying their software without asking.

Edit: OP's looking nicer!

 

[mixa]

OP's looking really good. I'm yet to try the autohotkey stuff.

Meanwhile, I made a video of me activating all the cheats in Cheat Engine to go from 0 to being ready to record as far as the appearance is concerned, which is an easy part of the process that might make potential collaborators shy away.

I used a more condensed table, and added some colors. Here is the link for the table.


http://youtu.be/Ov8pFX6qzXc

I'm still not sure about the camera though, since I haven't done any real testing yet. It seems like if you stay still too long, the camera rearranges itself.

I was gonna put captions, expliciting stuff, but I the video comes out really bad out of the editor, so
[collapse=here's what is implicit about the video for new people]In the beginning, clicking on the little computer button in the Cheat Engine window and selecting Mupen (00001A04-mupen64-rerecording.exe, or something similar) is how you connect the game to the cheat engine.

When I selected an address, I pressed Enter to modify the Value.

Near the end I froze 4 addresses, (put red Xs on the boxes), for that I pressed Spacebar.

For the blue and pink sections:

Right-click the first address, hold shift, right-click the last address of that same color, press enter, type in the number, press enter again.

For the invincibility glitch, I put F0. That doesn't always work. You have to guess numbers (10, 20, 30, etc).[/collapse]




Sugestions:

add the Mupen64-rerecording download link: https://code.google.com/p/mupen64-rr/downloads/detail?name=Mupen64 v8 installer.zip

40 invincibility glitch

40 doesn't work for everyone. I guess the number you have to put is Y, given Y = x*10. x being an integer. "F0" worked for me so, it's weird.

Training Mode HUD #1 à 6

I see you.

 

[Sangoku]

Thanks for providing more tutorials.

Camera shouldn't move if you freeze the values.

Edit: your info was added to the OP!

I see you.

LOL. I initially made that file for me, then I saw you asked for it and I thought, "great I already did it". Also it took me some times to realize after you pointed that out.

 

[MCG]

Thanks for the input.

I downloaded both files and put them in the folder, but when I open the script nothing happens. Then if I open the html one, it opens in firefox and there's no animation. What am I doing wrong?

Also, is there an advantage of this method above replacing the Japanese files? Except from the potential copyright problem of using/modifying their software without asking.

Edit: OP's looking nicer!

You have to put them outside the folder, not inside.

Pros:
-Provide an additional interface that could use the same "framework" the Japanese use.
-(Relatively) easier to add features.
-Portability. You only need a web browser. You can use it on Linux, OS X, Windows, etc.
-Similarity with a .gif with more controls.

Cons:
-I have not tested when the images are hosted but I doubt the images are loading fast enough. Maybe when they are already loaded in cache. It could work but it would need to be tested. And then again, you would have to upload 1gb + for every characters.

 

[Sangoku]

You have to put them outside the folder, not inside.

Pros:
-Provide an additional interface that could use the same "framework" the Japanese use.
-(Relatively) easier to add features.
-Portability. You only need a web browser. You can use it on Linux, OS X, Windows, etc.
-Similarity with a .gif with more controls.

Cons:
-I have not tested when the images are hosted but I doubt the images are loading fast enough. Maybe when they are already loaded in cache. It could work but it would need to be tested. And then again, you would have to upload 1gb + for every characters.

Ah thank you, it works.

However, the animations are too fast at 1.00 speed, did you set the correct timing for each frame (1/60 second)?

The main disadvantage I see with this method is the absence of inbetween values for hitbox/normal mode. Otherwise, if that was implemented that would be great. And the initial purpose was having the big file in local, so loading shouldn't be a problem. Of course, if loading is fast enough that we could have it online, it would be even better.

 

[mixa]

So for some reason I found the guessing game for the invisibility glitch really annoying, so I just went ahead and got all the values already.

Character Value Which CPU
yoshi f0 vs fox
samus 10 vs fox
kirby 40 vs fox
pikachu 80 vs fox
link 80 vs [U]kirby[/U]
dk 60 vs fox
luigi 50 vs fox
mario 00 vs fox
ness b5 vs fox
jigglypuff 60 vs fox
fox ? ? ?
falcon 90 vs fox

Can you put this info in the spreadsheet? So I can get it online and stuff.

 

[MCG]

Ah thank you, it works.

However, the animations are too fast at 1.00 speed, did you set the correct timing for each frame (1/60 second)?

The main disadvantage I see with this method is the absence of inbetween values for hitbox/normal mode. Otherwise, if that was implemented that would be great. And the initial purpose was having the big file in local, so loading shouldn't be a problem. Of course, if loading is fast enough that we could have it online, it would be even better.

The timer uses a value in millisecond and I think it doesn't like dealing with fractions (1000/60 ms for each frame). It might also be that the accuracy of the timer is not so great.

I'll look into transparency if I can superpose both images.

 

[Madao]

Lol nice guide. I hope more people become interested in contributing . I may make a few changes to Fox and reupload it, so I'll post a link later this week. I think I'm going to not bother with silly things like crouching anymore since it seems to be 7 frames for everyone I've tested. Lol I took the extra step and added hitbox info on some of Fox's attacks, but it's too tedious so I'm not going to keep doing that xD. I'm probably just going to stick with my fraps method for recording (the OCD in me has disappeared ).

Mixa, do you plan to do any characters? If so let me know, because I already did the frame counting for Falcon.

The timer uses a value in millisecond and I think it doesn't like dealing with fractions (1000/60 ms for each frame). It might also be that the accuracy of the timer is not so great.

I think people usually just do 16ms delay for 60 fps.

Also, for anyone screenshotting with fraps, you have to start the frame before the start of the move, because when you screenshot while the game is paused, it will only screenshot the next frame and it won't happen until after you unpause.

 

[tehz]

The timer uses a value in millisecond and I think it doesn't like dealing with fractions (1000/60 ms for each frame). It might also be that the accuracy of the timer is not so great.

I'll look into transparency if I can superpose both images.

Nothing in javascript is ever guaranteed, and that's especially true for timers. They'll fire when they'll fire. Also, you aren't pre-loading the frame images, so loading times could mess/are messing with the timing, too. Load times with local files shouldn't be an issue, but you never know. A good thing to do is to keep tract of your deltas between frames (really, between your setInterval fires), and then use that value to frame skip or wait if necessary. Here is like a really basic guide with some code snippets. Not the best solution, but that's what you give up for having frame control and running in any web browser. As a fall back, you could just have a GIF/aPNG that ran at the proper 60 fps for the 1x speed, and transition to the animated jpgs when people want to use the controls/change speed etc. (btw, can you set FPS in gifs? I don't really know. Maybe that's why the speed looks off for Sangoku)

Anyways, this looks like a good start! I've been wanting to write up something like this for a while (to learn how to use canvas to animate, play around with timers, etc.) but I've been really busy at work so I never got around to it. For the transparency, you could probably just use css opacity on the hitbox image and let the client handle the mixing between the non-hitbox and hitbox images. This assumes that characters are positioned in the exact same spot on the two images, though.

 

[mixa]

I think I'm going to not bother with silly things like crouching anymore since it seems to be 7 frames for everyone I've tested.

Mixa, do you plan to do any characters? If so let me know, because I already did the frame counting for Falcon.

hm, just now I realized that D-tilt with keyboard, unless ↓ is buffered, needs crouching.

I plan on doing Samus. I'll measure her moves sometime this week then looking into the script stuff. Yeah, I was aware that you were doing Falcon, you should put that on the spreadsheet.

 

[Sangoku]

This assumes that characters are positioned in the exact same spot on the two images, though.

That's the case, we actually record it to be this way because the Japanese Framedisplay is playing with transparency. And the speed looked off compared to in-game speed.

Madao, can you give me the frame counting you already did? Have you looked at my google doc yet? I did kirby and pika (not fully). The only weird thing is kirby's rock, because it's the only one different from the Japanese FD (either they made a mistake, or I made one, or it's really different in J and U).

By the way, let's try to be clear on who does what.

Samus is attributed to mixa (I'll add it to the OP).

Madao, are you planning on doing Falcon? If not, I can do it if you share the counting.

I'll take care of Kirby and Pikachu as well.

 

[Madao]

I will most likely do Falcon myself, but if I decide not to, I'll let you guys know. I've only written down attack duration for Yoshi, Fox, and Falcon. I will double check on the frame count before I post it, because I used a different method back then.

Lol I'm a bit surprised at the change of pace here xD. Tbh I wasn't sure if this project would ever be completed. I will take a look at kirby's down B. So what I will do today is some frame counting and double checking what I've already written down. If things go well, then I will be able to record Falcon this week.

Edit: Decided to finish pikachu's framecount for you. It took me ~35 mins (would have been much less if I wasn't carefully checking things). One thing I couldn't do was Up B, which fortunately you already did. I got different numbers than you for a few things though. Feel free to double check.
[collapse=Pikachu Frame Count]

down b            = 106 (shield came out at 107)
f roll            = 35
b roll            = 31
forward throw     = 29
back throw        = 42
edge recovery (f) = 34
edge recovery (s) = 69
edge attack (f)   = 49
edge attack (s)   = 89
edge roll (f)     = 49
edge roll (s)     = 99
get up            = 30
get up attack     = 49
get up roll       = 35
ducking           = 3

[/collapse]