Joined: 6/13/2006
Posts: 3300
Location: Massachussetts, USA
Heck props to both runs being great so far...
both AVI's and .m64's available is best for everyone, as I remember before I didn't have Mupen/correct ROM so I had to rely on AVI... plus the AVI's were encoded beautifully.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
I encode the AVI beautifully before sending to youtube, so it uploads faster.
I just thought it's less of a hassle to watch it online than downloading a m64 so you wouldn't have to fiddle with files / emulators. I thought i'd please everyone using youtube, I guess i was wrong.
When i make a testrun of RR i'll post a m64 wip and that'll be the last one before submission. Right now i've finished TTC with a mistake on the 2nd star which i'm not gonna remake because it doesn't waste much time and there was heavy luck manipulation on the later stars. So i have 110 stars done now.
Joined: 5/2/2006
Posts: 1020
Location: Boulder, CO
I look foreward to seeing it FODA. I really dont have the bandwitch to be downloading the AVIs to keep up with your run, but I'm really excited to seew hat you have.
I encode the AVI beautifully before sending to youtube, so it uploads faster.
I just thought it's less of a hassle to watch it online than downloading a m64 so you wouldn't have to fiddle with files / emulators.
I like the youtube links better since I can rewind them and it requires far less effort to start watching.
This signature is much better than its previous version.
I enjoy the ease of use of youtube as much as the next guy but it really hurts to watch 320x240 in full screen when I know the m64 would let me watch it at 1600x1200. Either way any wip is a good wip.
I enjoy the ease of use of youtube as much as the next guy but it really hurts to watch 320x240 in full screen when I know the m64 would let me watch it at 1600x1200. Either way any wip is a good wip.
I don't have much knowledge of TASing, but is it possible that you can go back and redo stars that you feel could be optimized further? Since Mario has the same exit animation after getting every star, you can cut out the part where he gets the star, improve upon it, and then paste it back in.
As long as you keep the "entering the painting" animation intact, it shouldn't affect the rest of the run.
Or does going back and redoing a star permanently screw up the .m64 file?
Borg Collective wrote:
Negotiation is irrelevant. Self-determination is irrelevant. You will be assimilated.
Hex editors can edit anything, why does everyone keep saying M64 movies can't be edited? I think it's possible to fix previous stars, based on the way I've seen this game run with Spezzafer's movie until near the end of Bowser 3 without desync when a small change was introduced at the start. But this game seems to have some randomness with (at the least) enemy movement, so you would need to redo a few other stars in addition to the ones you change, probably more than you would think.
My point is that with a video file converted to flash, a full screen pop-up cannot compete with the source the video file was made form in the first place, if that makes any sense. here's a random shot from AKA's wip to illustrate.
[URL=http://img169.imageshack.us/my.php?image=mariowm9.png][/URL]
The only star strat that would save signififcant time is the cage star, I've tried hex editing with m64 and it was a nightnare since I normally create copies of moive file and then delete it so I know which point to cut out but all the input seems to be stored in a m64 permanently so you can't erase parts and hex edit stuff in, but the game should be good because there is almost no randomess in terms of the setup of the paint worlds.
all the input seems to be stored in a m64 permanently so you can't erase parts and hex edit stuff in
Again: what? These are the only tricky parts about hex editing an M64, most of which aren't really tricky:
The frame counter in the emulator shows 2 types of frame counts (video, and input). You have to use the right one or you'll be editing in the completely wrong part of the file.
You should do the editing while the movie is not open in the emulator, otherwise the emulator will keep using the unedited copy of the movie that's in memory, like with SMV or VBM.
Each 'frame' of input is 4 bytes, you have to know that. But that's easier than GMV's 3 bytes, because most hex editors can group by 1, 2, or 4 bytes at a time, but not 3. You also have to add in the header size, of course.
If you increase the length of the movie, you have to increase the frame counts in the movie (see above link), like for SMV. But presumably this won't be a problem since you're trying to make the movie shorter, not longer.
EDIT: Sorry; I misread your post. Well, I hope the above info is useful to someone. Leaving the input at the end of the movie file is sometimes helpful, sometimes not. In this case it means you need to convert from VIs to bytes one extra time to know where you should paste the input at.
AKA wrote:
but the game should be good because there is almost no randomess in terms of the setup of the paint worlds.
I think FODA explained what would desync, but I can't remember it out of these 100 pages. You're right that it shouldn't be a lot in this game, but I wouldn't be surprised if it would mean he has to redo 20 stars (and go through a bunch of hex editing sessions) just to change one star early on.
Finished DDD and I'm now on Bowser#2 although the weird thing is that in terms of input I'm 41.67 secs ahead but in terms of frames I'm 37.9 secs ahead. obviously this is through lag which isn't noticable when TASing. I've personally decided to ignore lag issues as that would mean putting the camera in obscure places and destroying the run from a viewers point of view which would be like watching something simalar to Goldeneye.
approximately how many seconds would lag cost you throughout the whole run? If it is a significant number, then you should probably use bad camera angles.
Borg Collective wrote:
Negotiation is irrelevant. Self-determination is irrelevant. You will be assimilated.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
? frames are repeated in lag, so it's the same. it goes by the real time the emulator takes to run it. if it lags in the emulator, it counts as time.
even if it didn't, that should be fixed. it's obvious what we want to minimize is the real time, nothing else.
[/URL]
