It looks like the N64 emulator of choice is going to be Mupen64.
I was going to copypaste the contents of the respective message in the VBA thread, but it looks like there are other factors.
✓ There's a way to detect its format (against, say, audio files)
✓ The file format contains information about video playback rate (Hz) (if non-constant)
✓ There's a way to detect if the movie begins at console power-on
✓ The file format contains rerecord count
✓ There's a way to calculate movie length without iterating the whole file through (there must be a method that works for all movies that are accepted by the emulator, including files that have garbage beyond the end of the stream)
✓ The file must be one piece (no separate required savestate files)
✓ The movie must be immune to savestates and saveRAMs present in the movie watcher's system
Things marked with ✓ are ok, things marked with X are either not ok or need verifying.
There seems to be an issue with leftover SRAM files (file extension ".eep"). If I watch the Mario64 movie close to its end, and attempt to restart it, it's not going through the Princess and Lakitu intro scene, but instead Mario immediately starts outside the castle outside.
It would be nice if a movie could just be loaded and it works, just like that.
X The biggest problem in N64 games we can expect is the emulator compatibility.
Basically, each N64 game is a different story, as for how it works in Mupen64, and under which plugin settings it can be expected to be run. It can easily become an unnecessarily big amount of work if it's the controller settings are not standardised, and need to be manually changed every time a new movie is loaded.
X Another issue we haven't decided yet, is what are the standards we use in the encoding of the AVI/MKV files. Resolution, antialias settings, and so on. Same for the screenshots.
✓ Of course, we need people to have ROMs of N64 games, too...
[Edit: Dropped down the "announcement status"]
X The file must be one piece (no separate required savestate files)
Separate savestate files are not required for from-start movies. Currently they are required for from-snapshot movies, which should change although that also shouldn't affect submissions.
Bisqwit wrote:
There seems to be an issue with leftover SRAM files (file extension ".eep"). If I watch the Mario64 movie close to its end, and attempt to restart it, it's not going through the Princess and Lakitu intro scene, but instead Mario immediately starts outside the castle outside.
It would be nice if a movie could just be loaded and it works, just like that.
This is already being handled in the Windows version - it goes through and clears out .eep (and .sram and mempak) files on playback or recording "from start" movies. I think DeHackEd said he is not handling this in his version yet, although the code I have for it is platform independent so it should be not hard to add in a call to that code... (the function is called VCR_clearAllSaveData(), implemented in vcr.c)
Separate savestate files are not required for from-start movies. Currently they are required for from-snapshot movies, which should change although that also shouldn't affect submissions.
Okay. I changed my mind, it may actually be an opportunity if the savestate is not embedded.
And since it's not an encumbering thing for reset-based movies, it doesn't matter.
nitsuja wrote:
This is already being handled in the Windows version - it goes through and clears out .eep (and .sram and mempak) files on playback or recording "from start" movies. I think DeHackEd said he is not handling this in his version yet, although the code I have for it is platform independent so it should be not hard to add in a call to that code... (the function is called VCR_clearAllSaveData(), implemented in vcr.c)
The biggest problem in N64 games we can expect is the emulator compatibility.
Basically, each N64 game is a different story, as for how it works in Mupen64, and under which plugin settings it can be expected to be run.
Perhaps a bigger problem is that, if none of the judges have a setup capable of rendering the game accurately enough (this mostly means the graphics card, I think) or supporting the plugins that the game works with, somebody else may have to do the encoding. (I say TNSe should get to encode some of these, minus whatever texture stuff he was showing earlier.) Even Mario 64, the most widely supported game, is (in my opinion) not accurate enough (has many avoidable graphics glitches) in the full-video AVIs I've seen of it so far.
As for what plugins will work with which games, I think that is mostly up to the person doing a run of the game to work out. If they can't get the game to emulate well enough then they shouldn't be submitting a movie of it.
Bisqwit wrote:
It can easily become an unnecessarily big amount of work if it's the controller settings are not standardised, and need to be manually changed every time a new movie is loaded.
I made a change to vcr.c that makes this situation a little better - if you have too many controllers enabled, the movie will still play with only a warning given beforehand. And I combined all the multiple warnings into 1 warning, in case there is more than 1. If somebody uses a mempak or rumble pak (for instance to skip an intro sequence that warns it is missing), it will still need to be enabled (I haven't found a way to change the input plugin's settings), but at least the warning generated will be better than simply having an unexplained desync.
Bisqwit wrote:
Another issue we haven't decided yet, is what are the standards we use in the encoding of the AVI/MKV files. Resolution, antialias settings, and so on. Same for the screenshots.
(EDIT: disclaimer: I'm not usually one to even watch the AVIs, so it's probably best not to take what I have to say about this too seriously.)
For the AVIs/MKVs, I vote for 640x480 with codec quality lowered as necessary to make a reasonable file size (with antialiasing on only if it makes the file size smaller). I think this will actually appear more accurate than (or, at least as accurate as) rescaling it to the smaller size (as the encoding effectively reduces the resolution/detail anyway). The alternative is to use the exact game's resolution (possibly with scaling from a higher one), but this is potentially more of a hassle because it would require finding what the game's exact resolution is, which is not the same for all games.
As for screenshots, those probably have to become 256x192 somehow... using antialiasing (except where it causes noticeable weirdness) and scaling down from 512x384 would probably be best for this.
Bisqwit wrote:
Of course, we need people to have ROMs of N64 games, too...
Well, this apparently hasn't been a problem so far, at least for Mario 64...
