PDA

View Full Version : Creating movies based on key strokes


zilmar
29th March 2007, 11:48 PM
It does seem like this could be a good feature to add to project64. Which emulator on what system do you think implements this feature the best? I will look at how this works and see if I can do the same thing on pj64.

Smiff_
29th March 2007, 11:48 PM
to be clear: we are talking about saving (recording) the sequence of commands from the input plugin to a small pj64-specific data file. so you'd need the same emulator and the same rom to "play" the "recording" back.
saving to a video format (mpeg4 in an .avi container etc) is a related but extra feature that we might consider later, after this first part is done. so please keep discussion at this time only to how you want input recording and playback features (how the gui should look etc.), and not to creating standalone video files.
zilmar if this is wrong and you want to do the whole thing now please delete this post, sorry. (being on dialup is making team communication bad atm)

Anonymous
29th March 2007, 11:48 PM
I think this would be a very useful feature. I myself, have been having to use FRAPS up to this point, and would not the file size be smaller if it was a pj64 data file? I would certainly use this feature and show my support.

mudlord
29th March 2007, 11:49 PM
I personally think the best approach would be to use a similar system to that used by Nitsuja's build of Mupen64. The format used by that simply logs the keystrokes, as well as using a savestate to store progress (to allow for re-recording, etc..). Also, in that Mupen build, several other features were added to help create the speedruns, like frame advance etc...Maybe that can be a likely way? Also, Snes9x uses a nice method for videos too...

Smiff_
29th March 2007, 11:49 PM
well, give us a list of the nice features/controls to have, please? :)

also if there's already some kind of standard file format for this we could go with that, i'm not sure? it'd be nice to be compatible with other n64 emus, but probably that won't work out.

mudlord
29th March 2007, 11:49 PM
Yeah sure, the main things used by that particular method are:

Frame advance: A method to run through a game, frame by frame, in sections
Re-recording: The main feature needed for those movies
Speeding up/slowing down of the game
Fast-forwarding (like a turbo function)

Most of those methods might be mapped to hotkeys (which will help out the authors with movie recording). Also, with this format, it will be helpful in the movie file to log the plugins used, author of the file, length of file, ROM used to make the file..

mudlord
29th March 2007, 11:49 PM
As a note, it might not work with the movie files being emulator-independant. This can mainly be due to timing, as you know, emulators handle this all differently, and this recorded videos might not work right on all emus, due to sync...Which is a major issue with doing these sort of movies(as desyncs can often ruin a movie). How the modified Mupen64 build does this all through the emulator core, it doesn't do this via specifically crafted input plugins...

Smiff_
29th March 2007, 11:49 PM
ok you want fast-forward and rewind, which means auto states every x seconds (more granularity the better i guess.. would every 10 seconds be enough? buffer these in ram (going to use lots! could do something like every 5 seconds for last 30 seconds, every 10s for last 2 mins, then every 30s for 10 mins, etc) perhaps a command for user to insert their own points. maybe display these in a nice table that would let you rename labels and click to jump between points? i'm not sure if a time slider or a vertical list is better.
metadata is a great idea also, pop a dialog for this after saving the recording. or if we have a form open, let you fill in fields any time.
you're right of course that compatibility with other emus is never going to be good until all emus have accurate timing (i.e. never). even keeping the demos working within pj64, when there are core fixes, could be difficult.
there might be ways of re-syncing it by saving a checksum into the file of important core register states or something like that. at least we would know on playback when emulation is not matching the original and stop playback & display msg as soon as it goes wrong.
something else: do cheat codes need to be allowed for movie makers? if so, the file would have to contain the time that each code was enabled and not allow user to change cheats during playback. to ensure compat with diff cht files, the actual code needs to be copied into the movie file too. obviously you check(sum) the rom and emulator version. i am not sure what difference video plugins may make as they access the framebuffer.. it may even be a good idea to include rdb settings in the movie file?
quite a lot to think about :o i guess zilmar can get the basic record and pay working before adding all the ui..

mudlord
29th March 2007, 11:49 PM
I'm not very sure on the best timing methods to do autosaves of savestates, maybe that can be up to the person doing the speedrun/movie (like how you described it). What I meant about the fast-forward, is that it fast forwards execution of the game, like a turbo button. This used often in those tool-assisted speedruns to skip uninportant parts, when recording. I do believe though that savestates are done externally, and they are not stored in the movie file when making the movie directly, but they are used like for saving hard spots to speedrun, and then they can record from there...

I agree about the metadata :). How Nitsuja does that in his Mupen build, is by having it when the movie is saved for the first time, like to set the author's name, and filename of the movie file, and then the emulator in the movie file notes down the plugins used, ROM CRC, length of file in hours/minutes/seconds and other stuff like that.

As for cheats, I dunno if cheats are needed. What I understand, is that cheating using cheat devices when making speedruns is actually discouraged, and that the movie makers actually discover thier own glitches in games (like on TASVideos.org, the movies must be of untouched games, that is, not hacked internally. Thats just one of the rules). And since N64 movie makers are just using Mupen, which doesnt support cheats, they might not be doing anything, other than directly hex-modifying the movie file, for changes to how data is inputed. But, I'm not too familiar with speedrun politics.

I also think that getting the very basic recording and playback is important, before adding in the speedrun specific features into the emulator core. That way, maybe even speedrun movie makers might be able to elaborate on what features they might need for thier movies.

mudlord
30th March 2007, 01:09 AM
Of that last point, I got in contact with a member from tasvideos.org. Generally, for emulator movies, there is a list of standard features. Here's the list of features needed to add this sort of speedrun movie support: http://tasvideos.org/DesiredEmulatorFeatures.html

This might help in working out what to add in regards to emulator movie support.

Smiff_
30th March 2007, 02:45 AM
excellent mudlord, thanks
(h*ly h*ll, this is months of dev on its own.. i don't know much will be done. that is perfect info though thanks)

Jabo
30th March 2007, 06:25 AM
Yes we've been throwing ideas back and forth on this for a while, it is a very large feature, I remember realizing this about texture packs when I was half way into developing it. I think this feature is worth it, there is an entire scene built around this and I think shining more light on it and promoting it would be something worthwhile -- not before netplay tho ;-)

Anonymous
2nd April 2007, 08:55 AM
check out zsnes's fastforward feature (press ~) it just disables frame limit while it's held down. of course, i don't know about the audio syncing factors since i know if i select the option to sync the audio to the game, the enabling and disabling the frame limit won't have any affect

Smiff_
2nd April 2007, 10:38 PM
SNES emus actually draw 1 frame in x to fastforward. we cant/won't do this, so fastforward is mostly just a case of running the system as fast as we can. fine on fast systems, useless if you're at 100% cpu anyway (less an issue now).
the "other" kind of fastforward is when you've rewind, then you can jump forward through states again.. not sure which people want, the ability to replay or just a repeat?

Anonymous
5th May 2007, 08:29 AM
As far as N64 emulation goes Mupen64-rerecording handles recording of this manner the best. If it was implemented I would highly recommend support for Mupen64's native ".m64" movie file format. ;)

Anonymous
12th January 2008, 05:49 PM
I know I'm resurrecting an old topic, but I thought I'd clear one thing up: the reason tas likes the cheats to be stored in the movie file is so they know what cheats, if any, were used. If the movie file uses a cheat code, they know to quickly disqualify it.

Anonymous
18th January 2008, 02:13 PM
oi wtw w twe wwe tew we ew ;D >:( :(

Anonymous
23rd January 2008, 11:58 AM
VisualBoy Advance implements this feature, but it doesn't work to well in games where things can randomly happen, for example in pokemon games, when you go into grass.

Anonymous
27th February 2008, 06:31 AM
i use smart notebook recorder