um, emulators don't pretend that buttons left pressed on the last frame of the movie will stay pressed until a person manually presses and lets go of the button again.
So, regarding the following text...
it is not a problem nor does it need fixing because all keys are released when a movie is over. I can modify my program to tell you which buttons were held on the final frame (before input ended and everything held was released), but having a separate release counter would be seriously no more informative than what I just suggested.
Progress report: m64s can be saved but their number of frames is completely incorrect. (Probably because of how n64 TASes have vertical interrupts and input frames which are rarely the same.) So it can save back frame information correctly* up to the final input frame and then it adds garbage frames or something. Anyway I won't bother posting it until I can get it to save it all correctly.
*I changed the view/edit format a bit for no reason other than it made my life easier. Example: if during a frame, you are pressing the analog stick (or using input plugin) all the way up and half way left, and also pressing Z and C up, the frame would look like "Z(C^)(X<64)(Y^127)"
EDIT: Well, it is ready but there are some restrictions for m64 editing. I don't know what will happen if you add or remove frames, but if you edit what's there, things should be fine. HOWEVER, since there is no way to tell how much real time has passed just by giving the movie input frames, and changing them can lead to inconsistencies due to variable framerate and blah blah blah, I wholeheartedly recommend that any m64 edited be run through the emulator once in a non read-only mode, have a savestate made on the final input frame, have the state loaded and terminate the movie so that realtime frames (used for submission times) reflect post-editing and not pre-editing. Nothing can be done about this afaik, sorry.
Anyway: Enjoy! and I'll try to fix any horrible bugs if they are mentioned.
And a big thanks to Maximus for writing such easy-to-read code and commenting well.
I think I remember reading somewhere that the different .NET versions can be installed side by side, so it might work if you install the .NET 2.0 framework (your 3.0 will still be installed as well for whatever you use it for).
I plan on adding m64 save support soon. I've already modified the source a bit to not have an incorrect error when trying to save it. "All" (hah) that's left now is to write the save function using the M64 format.
Edit: oh god, I see why it was never done. This is going to be some fun string parsing.
But that file lets you pick cutsceneless in the splitter options, so I don't know what you're asking for. For example, if you are using the haali media splitter in Media Player Classic, right click on the haali icon in your task bar, and pick "edition 2".
It would be pretty sweet if the final bowser could take the first two hits by flying off of the first into the second (and be thrown normally into the third).
Bowser's text can only appear after two conditions are met. 1) bowser is laying on his back and has finished his giving-up/relaxing animation and 2) mario is on the ground within a certain distance of bowser's body.
So the authors have time to kill while waiting for condition 1.
Welcome to nicovideo? :P
There's a comment button on the video player that toggles them for those who don't care about or like them.
You'd need to change the values at 0xC and 0x18 I think.
Anyway, this is a silly encode that has the new bowser fight, and I took some liberties with the screen format.
Ok, well I'm not happy with my encode. First of all the near clip plane shit is way more distracting than I'd hoped. Second of all, decimating 30 consecutive dupe frames makes for very weird-looking pause-skipping in the cutsceneless edition (probably because the I-frames are so far apart that it's all in one GOP or something). If I make another from the same source, I would decimate max 10 and maybe shave off another 50+MB from the video.
Anyway, here is the test encode (420MB), using the same sound file as raiscan's texture-mod encode. Comments/flames/opinions about cutsceneless option are welcome.
Cutscenes aren't all the same length. And it's not like a separate avi is being made. it's an option within one video file because technology is awesome like that. Open up video, and watch 2 hours and 59 minutes, -or- click "Edition 2" and watch 1 hour and 50 minutes (both include 11-minute ending) so you don't have to seek around. Hopefully simple, not annoying, and really easy to ignore for people who don't care and want to watch the nabooru talk forever and have all like 40 pause screens take 7 seconds each :P
You guys don't get it. the first hour is not what is interesting about this run and you should stop rewatching it if you find it boring. Most of it has been seen in previous runs. It's the adult portion (beginning at around 1h15m in, chapter entitled "Light Medalion") that is the most entertaining (well, except maybe the water temple, but still).
An hour into the cutsceneless version is ~1h45m into the normal version. 1 hour into the normal version is 43 minutes into the cutsceneless version.
In other news I should have the video portion of the encode with both chapter editions done before the coming weekend, but Raiscan is still trying to get an audio track that syncs.
That's the point of the cutsceneless version. So that you don't have to watch long sections of the movie with zero input. (I haven't finished it yet because I took a break, but about 1h30m, NOT counting the ending credits, will be snipped)
Have you really never played this game? The underwater pits actually suck you dowards towards their center so you go slower for a bit once you are past the halfway point of the pit
Anyway, voted yes for awesome tricks.
Sigh. I finished it last night and wrote like a wall of text about what I liked and didn't like but then my browser decided to not respond and take up 50% of the CPU. Letting it sit overnight didn't help it recover so... blah.
Edit: hooray for a bit of assembly knowledge. debugged and forced it out of an infinite loop.
They add up to 100% because they show the percentage of the movie where x number of buttons were pressed. first bar is a % of frames with no input. second is % of frames with only 1 button pressed down. Last bar is % of frames with 5 or more buttons pressed at the same time.
alden: the latest megaman movie has 56.2% of frames with no input. (don't trust the program's .fcm stats, they are (still) wrong, so convert to .fm2 first)
Halfway through watching the run.
-First, the bad:Because I am unfamiliar with this flavor of GTA, I dunno, some of the driving seems unoptomized. For example, sometimes from standstill you skid around so you face the right way before letting go of the brake but sometimes you back up a bit and then go forward, and sometimes you brake harder than I'd expect to be useful for a 90 degree turn. Also, to pick up some people yu are driving towards, you stop on the first possible frame which (maybe? again, unfamiliar with engine) makes the guy have to walk farther and we all know he walks slower than you can drive.
-And now the good: It's pretty entertaining and I've defintely laughed aloud a few times like the swat guys and the van in mission 2. I also like how inept you make the police seem, and how "easy"/fast some of the missions are.