No luck getting it to compile(I had already looked at that thread). I may try again in the future, but for now I'd just like to put in a minor feature request for the next release:
* Add an option to disable the on-screen text(ROM info, movie end, speed changes, etc.), or change it so the text isn't recorded to the AVI.
EDITED: Uh, not that I know of, I guess.
There is a newer (official) Snes9x version in the works, which is not quite ready yet, but it will certainly be linux-friendly and it will incorporate much of the improvement9 changes (and, incidentally, fixes for all of the problems/suggestions that I see posted on this page).
If anyone cares, I am discontinuing the "Snes9x improvement" branch. It will be replaced by the next official release of Snes9x, except for the purposes of playing existing movies.
Here is a windows version of v1.5:
http://www.snes9x.com/phpbb2/viewtopic.php?t=2831
Great job of nitsuja as usual for converting it to a windows port which wasn't available for this version before.
Only problem is most (if not all) snes9x movies from previous versions on this site won't playback on this one because it has a different movie format.
Thanks guys. :) I got the Windows executable from rapidshare, BUT the source has been removed (not enough downloads) and filexoom doesn't respond over here. :(
Could you upload it again? If not then just send it to creaothceann{at}web{dot}de ... thanks in advance.
That and reset recording, which doesn't change anything in the header. The extra fields in the header for peripheral support will occur after fields from previous versions, so tools or other things that look at SMVs should work on the new version as well, except for the input of movies with peripherals. Mouse/superscope/justifier movies won't be easily editable by external tools or hex editors, because Snes9x checks that type of input in a different way (it can change in-between frames or not at all for several frames, so storing one set of input per frame in the movie would not work).
Will it be possible to determine at what time particular peripheral input belongs without playing movie? Of will it be like in M64 movies?
Like M64, for peripheral input.
Maximus wrote:
Is backwards compatibility with < 1.5 SMVs planned?
No, because it's practically impossible. It could run a second executable when you open an older movie, but it'd be pointless because you can easily do that without going through a different version first.
OK, got the source. :)
Btw. are there plans to record the values the game reads from the controller registers (4016h & 4017h iirc) instead of recording the current input of a frame? This was discussed here...
Forgive me if I'm a tad ignorant as far as the inner workings of the emulators are concerned, but what would be the advantage of storing those values versus frame input?
Btw. are there plans to record the values the game reads from the controller registers (4016h & 4017h iirc) instead of recording the current input of a frame?
There aren't plans to do that that I know of. And I think there would be something else to take into account besides when those two registers are read (autojoypad emulation? 0x4218 to 0x421f).
4016 rwb++++ JOYSER0 - NES-style Joypad Access Port 1
Rd: ------ca
Wr: -------l
4017 r?b++++ JOYSER1 - NES-style Joypad Access Port 2
---111db
[...]
Note that Auto-Joypad Read (see register $4200) will effectively write
1 then 0 to bit 'l', then read 16 times from both $4016 and $4017. The
'a' bits will end up in $4218/9, with the first bit read (e.g. the B
button) in bit 15 of the word. Similarly, the 'b' bits end up in
$421a/b, the 'c' bits in $42c/d, and the 'd' bits in $421e/f. Any
further bits the device may return may be read from $4016/$4017 as
normal.
The effect of reading these during auto-joypad read is unknown.
See the section "CONTROLLERS" below for details.
So the automatic reading uses these registers as well.
Maximus wrote:
Forgive me if I'm a tad ignorant as far as the inner workings of the emulators are concerned, but what would be the advantage of storing those values versus frame input?
No more desynced movies!
Different emulator builds may cause the game to read the controller registers on different frames, causing them to miss the right data. They get the data for another frame (the one before or after).
By enumerating the reads instead they can't be missed, since no emulator build would break the game so much that it wouldn't read at all.
EDIT: Existing movies could easily be converted - just go through the file, save the keypresses and skip the "empty" frames.
Hmm... I'll try it and see if it really solves any desync problems. If it does, it would be worth at least having an option for it. Do you know what registers are equivalent to those for peripherals?
They are connected to the same gamepad ports, so the peripherals are using the same registers. They just have a different data format (see anomie's docs and snestech.txt if you're interested), but for movie recording/playback this shouldn't matter.
Mmmh, one thing that could break the conversion of older movies (assuming there's a need for that) is if the player pushed buttons when the game wasn't reading from the registers. This would then need manual fixing, I guess.
Mmmh, one thing that could break the conversion of older movies (assuming there's a need for that) is if the player pushed buttons when the game wasn't reading from the registers. This would then need manual fixing, I guess.
Couldn't the conversion still work by playing back with the old method while recording with the new one? Or are you saying pressing buttons at certain times can have effects other than the reading of those registers? Of course, it would have to be done in the older emulator because only that can play the movie based on frames without desync, and I have a feeling that most converted movies still won't play back properly in newer versions. But it's not a big deal if so because they wouldn't play back anyway and that's not the main purpose of doing this.
Couldn't the conversion still work by playing back with the old method while recording with the new one? [...] Of course, it would have to be done in the older emulator because only that can play the movie based on frames without desync, and I have a feeling that most converted movies still won't play back properly in newer versions.
Well, if you want to have both methods in one emulator, then of course it'd work as usual.
nitsuja wrote:
Or are you saying pressing buttons at certain times can have effects other than the reading of those registers?
Not directly - the reading is done by the game; button presses don't cause x86-like interrups or something like that.
An example: In Super Metroid there's a point where Samus is carried by a Chozo statue across a field of spikes, and the player can't control anything for a few seconds. There's been a movie posted though where the author pressed the appropiate shoulder button (L or R) as if giving commands to the statue. (Viewers who have input display enabled can watch this.)
Now if the game is still reading these pad changes but discards them, then there wouldn't be a problem for the conversion. But if the game doesn't access the input registers then a movie converter would add the inputs up and feed them back when the game begins reading "real" input again.
IMO it's safe to say that less than 50% of all SNES movies on tasvideos will have that issue, probably much less but I'm bad at guessing. The rest, maybe only a handful, would require some manual fixing, ie. removing that unnecessary input.
