thanks for pointing that out. I misunderstood the "frames" value in the bizarre fcm spec so all FCM percentages were incorrect. The number of frames I thought the movie had was only the number of times that the controller state changed. your Solstice example had near 17k frames, not 4k. Also since no one was posting I didn't bother to continue updating but now I'm up to v0.6, and it supports FCM (correctly now, thanks!), FM2, GMV(no support for XYZ buttons yet), SMV, M64 (the analog stick is considered one button, either used or unused per frame), and writing out the data to a text file. This should work with any supported replay format* but it will only show stats for player 1.
TODOs: add vbm support, add GMV's XYZ support, make tabs for movies with multiple controllers, clean up display code, post source
Proof that it works:
and link to v0.6: http://www.mediafire.com/?a0chh0i0vqi
*If there is a two-player+ run of a nintendo64 game, with actual input on more than 1 controller, the stats are likely to be extremely inaccurate through no fault of my own. Blame the m64 spec creator or mupen's input API writers.
I'm up to v0.6, and it supports FCM (correctly now, thanks!), FM2, GMV(no support for XYZ buttons yet), SMV, M64 (the analog stick is considered one button, either used or unused per frame), and writing out the data to a text file.
Nice work!
Because I"m on a mac, I can't try it out, but this seems like a cool widget. This might pave the way for stat lists.
I'll give this a go on the IBM-compatible sometime. Should be interesting, despite the 'dancing' that goes on sometimes.
I'm just some random guy. Don't let my words get you riled - I have my opinions but they're only mine.
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
One tool that would be very useful would be one that can delete button input given certain conditions. Take Solstice for example, that game only accepts input when RAM address 0020 is 0. However, it's very inconvenient to manually only press buttons when it's 0, so you usually hold down the buttons all the time.
What I'm thinking about is a tool that can delete all input from a movie file when a certain RAM address has or hasn't a certain value, and that this should be done for each and every frame in the movie. I realize that information about RAM addresses isn't stored in movie files, so this tool would somehow have to play the movie file in the emulator and change it from there, or something...
Randil, I see what you mean but A) very few movies would even be able to benefit from that B) it would probably be easier to have lua take care of it in an emulator that supports it. Then you could start playing a movie in read-only, but have a copy of that file somewhere, and lua would check every frame to see if some ram check returns true and if so, turn off the button bits. ... though for the FCM format specifically, that would be a HUGE pain to code in lua, and also the .fcm would end up bigger with multiple button toggles than if it was just holding it the whole time.
All other formats might have an easier time though :)
Also, VBM support added. v0.7.
TODO: add GMV's XYZ, allow multiple controllers, clean up processing code, post source and be done. (Eventually add PSX format lol)
for the FCM format specifically, that would be a HUGE pain to code in lua
But for fm2 it would be pretty simple... start recording a new movie, open the movie file directly in Lua, and have it send the buttons when needed. I have some code somewhere to read fm2 movies if you want to try it out Randil :)
Couldn't you do something where a script would try to play through your movie, checking at each frame if removing input changes the game memory? If inputs are truly ignored, then removing them should have no effect on the game state. That would be a portable, if rather brute-force, way to clean up input files.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Hehe, me neither. :P I read through the code, but I'm not that good a programmer so I didn't understand much of it either. But reading the comments, it seems like it could do remove input from a movie file.
Derakon wrote:
Couldn't you do something where a script would try to play through your movie, checking at each frame if removing input changes the game memory? If inputs are truly ignored, then removing them should have no effect on the game state. That would be a portable, if rather brute-force, way to clean up input files.
Yeah, this was pretty much what I was thinking too. A Lua script could be one way of doing it, but I don't know if/how a Lua script can take care of input from a movie in read-only mode. (unless that is what Bisqwit's script does)
I realize that this tool would probably make the movie-file larger in many cases, but if the goal is to produce a run with as few frames with input as possible, it would be a very useful tool.
And thanks for the .fm2 code offer alden, but I'm not a good programmer so I would probably just be confused. :)
Button press counter. Requires x_functions library.
Looks best with Acmlm's version of FCEUX.
Basically, provides a counter for every controller detailing the number of times a button (any button) was pushed down. Not the duration, just pushed. Releasing does't add a count either.
(Left: FCEUX vanilla. Right: FCEUX-.)
The bar shows (presses mod 50). After 50, another bar appears that counts (presses / 50). For refrence, our best record for 1-1 is 15 :)
(For refrence, FCEUX- looks for DLLs in "dll/". This is to keep the main folder, you know. Organized.)
Edit: Oops. Forgot to mention, Select will clear the counter. Good if you're resetting a game or reloading a savestate without reloading Lua :)
Also, another edit... SMB1 1-2 may provide an interesting challenge, as constantly walking will put you face to face with a Koopa in a one-block-tall corridor ... and running constantly will give you goomba problems :) Of course both can be accomplished with good timing.
I still think that key releases should also be counted. Maybe add it as another value? (Perhaps make it optional if both are shown, or only the key presses value is shown.)
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Why exactly? Keypresses and keyreleases are 1:1. Eg. You cannot release a button that has never been pressed.
In fact, it can be proven that at any time, the number of button presses (a key that is held in frame n while it was not in frame n-1) is always 1 more than the number of buttonreleases (a key that is no longer held in frame n while it was in frame n-1). It's not exactly rocketscience...
No, they aren't. Not all pressed keys must be released by the end of the movie.
This can make a difference: For example one movie could complete a game while keeping the right arrow key pressed for the whole movie, while another releases the right arrow key before the end of the movie. Otherwise they could be identical. If we count key releases, the first movie is more optimal.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Easily fixed by treating the movie as if it had an extra empty frame at the end of the movie (that would cause all buttons to be released, no matter what)....
If you're going to be that anal about keypresses, multiply the count by 2 and subtract one for every button you're holding down at the end. Congratulations, you win.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Warp wrote:
Fixed? You consider it a problem which needs fixing?
Wtf? Are you really so dense that you can't see what I mean? I'm sorry but I'm trying to help and make you see that there was no "problem" in the first place. But if you wanna go ahead and make it difficult for yourself then fine. But don't be crying here when people are telling you http://www.doingitwrong.com/
In fact, it can be proven that at any time, the number of button presses (a key that is held in frame n while it was not in frame n-1) is always 1 more than the number of buttonreleases (a key that is no longer held in frame n while it was in frame n-1).
I challenge this. I believe that the number of presses is X more than the number of releases, where X is the number of buttons currently held down. And X does not necessarily equal 1.
I'm just some random guy. Don't let my words get you riled - I have my opinions but they're only mine.
Fixed? You consider it a problem which needs fixing?
Wtf? Are you really so dense that you can't see what I mean?
I suppose I am. I presented an argument why key releases should also be counted (whether you think it's a valid argument or not is a different issue). You responded with some kind of "fix" (your own words). A fix to what? Problems are fixed. I see no problem here.
I'm sorry but I'm trying to help and make you see that there was no "problem" in the first place.
By suggesting a "fix"? Yes, maybe I am dense, because I don't get it.
But if you wanna go ahead and make it difficult for yourself then fine. But don't be crying here when people are telling you http://www.doingitwrong.com/
Now I *really* don't understand what is it that you are saying. Exactly what am I doing wrong? I don't get it. Maybe your subtle hints just escape me and I really am so dense.
The only potential argument I can at all see for counting button releases is that you can hold a button all the way though the movie (say, Start, in SMB1) and decrease the count by 1 as opposed to only pushing it for one frame.
Do enlighten me if you have something better other than that silly idea, because... well, it makes little sense.
Yes Warp, Yes you are. Nobody should doubt it at this point.
Exactly what is your point in insulting me, Mr. "I have made 17 posts so far"?
I argumented that, in my opinion, two movies can differ in keypresses when we also count key releases: One movie can be more optimal than the other because it performs less key releases.
The only counter-argument to this I have seen is that this "problem" (what problem?) can be "fixed" by automatically counting all keys as being released at the end of the movie. Moreover, I have been told that if I want to make such a distinction, I'm doing something "wrong".
Well, excuse me if I just can't understand how this solves anything, or how it is any kind of counter-argument to my opinion, or what exactly I am doing "wrong" here.
You seem to agree with qFox, Mr. Cheezwizz, and even so much that you feel so confident that you can insult me. Then please explain to me what I am not understanding here, since I am so "dense".
Xkeeper wrote:
Do enlighten me if you have something better other than that silly idea, because... well, it makes little sense.
I am really puzzled now. In a forum where we create movies where we attempt to optimize every single frame off, where everything counts, you are saying that in a "minimal keypresses" competition saving key releases is a "silly idea" and that it makes little sense?
Sure, the savings may be minimal, but since when have minimal savings been inconsequential in TASes?
If someone posted a submission and wrote something like "I performed this trick here because it saves one frame" would you respond to him with "that's a silly idea and it makes little sense"?
Sure, the savings may be minimal, but since when have minimal savings been inconsequential in TASes?
If someone posted a submission and wrote something like "I performed this trick here because it saves one frame" would you respond to him with "that's a silly idea and it makes little sense"?
The point is that this would only affect up to 8 buttons, and often only one.
Consider SMB1; if you're going for minimal presses, the only probable difference would be holding Start thoughout the entire movie.
Not releasing a button that would need to be pressed again later wouldn't be an "optimization" for this, because you would want to not release it for sheer button presses.
Basically, counting releases as well will only impact the end of a movie. Counting presses only will have a much more noticable effect.
Edit: In short, the only "optimization" would be holding down the final buttons all the way to the end, which is a very, very silly thing to base a claim of "optimzation" on.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
The reason, I guess, is that not counting presses from before or after a movie sounds a little cheap to me. I would think it's fair to say that any key pressed at the first frame of a movie, at some point was not before the movie, and should be counted as a keypress. The same argument applies at the end of a movie, at some point you're bound to let go of any button, hence any buttons pressed at the last frame of a movie should be counted as a release. Write up some examples, counting like this you will ALWAYS get as many presses as releases. And that is why we find it somewhat redundant to explicitly count buttonreleases as well.
-- PS nobody will stop you from counting them though! And we'll all agree that the number of releases is equal. We might disagree on the buttons pressed before or after a movie. But for me personal that's something we won't agree on then.
Is there even ground to argue buttons pushed before a movie? Considering movies (here) are supposed to begin from power-on, then the least that could be done for minimal presses is start the character with no buttons pushed, no accelleration, and preferrably just before control is possible.
(e.g., a minimal presses run of SMB 1-2 would optimally started as Mario is walking to the pipe or otherwise on an intermission.)
I am not entirely sure I understand this part of the argument though. :|
and link to v0.6: http://www.mediafire.com/?a0chh0i0vqi
*If there is a two-player+ run of a nintendo64 game, with actual input on more than 1 controller, the stats are likely to be extremely inaccurate through no fault of my own. Blame the m64 spec creator or mupen's input API writers.%20(PRG0)%20[!]-3.png)
%20(PRG0)%20[!]-2.png)
(Left: FCEUX vanilla. Right: FCEUX-.)
The bar shows (presses mod 50). After 50, another bar appears that counts (presses / 50). For refrence, our best record for 1-1 is 15 :)
(For refrence, FCEUX- looks for DLLs in "dll/". This is to keep the main folder, you know. Organized.)
Edit: Oops. Forgot to mention, Select will clear the counter. Good if you're resetting a game or reloading a savestate without reloading Lua :)
Also, another edit... SMB1 1-2 may provide an interesting challenge, as constantly walking will put you face to face with a Koopa in a one-block-tall corridor ... and running constantly will give you goomba problems :) Of course both can be accomplished with good timing.
