Added the ability to play Famtasia/VirtuaNES/Nintendulator movies directly from FCEU by interfacing with nesmock.exe. (It creates *_autoconverted.fcm and plays that.) Of course this does not guarantee they will stay synchronized, but I've had success playing old Mario, Arkanoid, and Gimmick! FMVs so far (without even fiddling with the offset fields).
AVI garbled sound bug fixed
AVI audio/video sync fixed
AVI splits to filename_part#.avi after about 1.9 GB
Quitting the program normally while recording an AVI no longer corrupts the AVI.
Quitting the program normally while recording a movie no longer truncates (which required hex editing to fix) all of your progress since the last time you stopped recording.
Fixed resuming a movie to properly update the emulator version number in the movie.
Read-only option of playing a movie is now saved.
Made input settings of which peripherals are on reset to gamepads upon playing a movie so you don't have to reset it yourself to play movies of games with peripherals.
Gave frame advance sound, and added option to mute it
Rewrote sound update code to make sound a little better when different speeds are used and also to allow the game to emulate at a noticeably higher maximum speed than before. Also added an option to use the old code in case that works better for some situations.
If you specify to save something to a nonexistent directory, the directory (or directories) will be created.
Possibly fixed some problem with save states. (Removed a suspicious hack that looked like it could change a save state to something different than what it was saved as, which might have been causing desyncs or other problems. This will not help with save states made with earlier versions, so make sure your save states are new (saved in this version) from playing from movie start.)
Made the windows 48x48 icon less crappily scaled
Changed default movie directory (if you didn't override it) to .\movie instead of .\fcs
I was thinking about doing some other stuff but I think that's enough changes for now to justify a new release.
Ok first thing I had noticed. When using turbo key and you release it, there's a delay. Wasn't there before.
And the turbo key doesn't go as fast as FCEU can. 1600% speed is clearly faster.
I will test other things later.
Turbo skips a lot of frames, the delay is only apparent in the video and it is the frame skip catching up to the next frame after slowing back down. Also, turbo turns off all limitations and skips all waiting so it runs as fast as possible. Turbo and 1600% both run at the same speed for me, except turbo skips many more frames than 1600% does so each graphical update is slower to happen even though it's emulating the same speed or faster.
I said: Turbo skips a lot of frames, the delay is only apparent in the video and it is the frame skip catching up to the next frame after slowing back down.
(it's not intentional but it's not a major problem either)
Well, and?? It should not have that SOOOOOOOOOOOOOO long delay. Since turbo and 1600% are the same speed, why not using 1600% for turbo?
Imo, the turbo function is now a little clumsy.
OK, it's only between about 0.1 and 0.5 seconds of a delay for me, which seems fine for going out of a mode like fast-forward, but I'll look into it. I was probably wrong that it's just the frame skip, though, I think what's happening is that fast-forward neglects the sound buffer somewhat so on resuming it waits until the sound is ready.
OK, I found a change to the sound buffering code that fixed it. I updated the links in the post above with the fixed version. EDIT: Uh, actually wait a sec, I think that slowed it down, now it really is slower than 1600%. EDIT2: OK, now it's really fixed.
Phil wrote:
Since turbo and 1600% are the same speed, why not using 1600% for turbo?
Because they're not the same speed; if your computer is fast enough, turbo should be even faster than 1600%. The problem is fixed now anyway.
Awesome! So what turned out to be the ultimate cause of the desync?
The spontaneous exit when choosing "Full Frames (Uncompressed)" might be caused by a bad setting in FCEUI_AviBegin():
bi.biSizeImage = 4 * bi.biWidth * bi.biHeight;
That 4 should be a 3, since we switched from 32-bit to 24-bit RGB.
Out of curiosity, as a possible (major) optimization, how hard would it be to change the convert_buffer variable in the avi_file struct to a three dimensional array? I ask because do_video_conversion(), given how often it's called, sucks up a ridiculous amount of operations finding the proper byte in a one-dimensional array. I estimate about 20 wasted operations in a loop that runs over three million times per second. Just a thought...
Here's a permanent(if needed) home for the new exe/src...
Current as of 1/22/06 20:45 EST...
Binaries: http://www.visionsofdoom.us/misc/fceu-0[1].98.15-rerecording.zip
Source: http://www.visionsofdoom.us/misc/fceu-0[1].98.15-rerecording-src.7z
When using frame advance and show inputs is on, we don't see them.
Edit: CorePNG codec isn't working well. In fact, FCEU either crashes when stopping recording or the AVI is 0 byte.
How about an option to allow replay movie? What I mean, sometimes I want to replay a movie but when it is in an other dir, I must browse and blah blah blah. It really annoys me.
Awesome! So what turned out to be the ultimate cause of the desync?
I don't know. The number of sound samples generated didn't quite match the number of video frames. I looked at the Linux AVI recording patch and found no differences to timing in there that I had not already tried, so I'm not sure how it works with that...
Andy Olivera wrote:
The spontaneous exit when choosing "Full Frames (Uncompressed)" might be caused by a bad setting in FCEUI_AviBegin():
bi.biSizeImage = 4 * bi.biWidth * bi.biHeight;
That 4 should be a 3, since we switched from 32-bit to 24-bit RGB.
Ah, this seems likely. Apparently every other codec, including ffdshow set to Full Frames (Uncompressed), corrects for it somehow, while that doesn't.
Andy Olivera wrote:
Out of curiosity, as a possible (major) optimization, how hard would it be to change the convert_buffer variable in the avi_file struct to a three dimensional array? I ask because do_video_conversion(), given how often it's called, sucks up a ridiculous amount of operations finding the proper byte in a one-dimensional array. I estimate about 20 wasted operations in a loop that runs over three million times per second. Just a thought...
This is easy to do, but mainly because there's an easier way to optimize out the repeated calculations than making it into a 3D array (which would either slow it down from extra indirection and memory alignment changes, or be exactly the same as a 1D array and only conceptually 3D).
Actually, any decent optimizing compiler should perform this optimization on that loop automatically, and then some, but I wouldn't know if that's true of gcc.
Phil wrote:
When using frame advance and show inputs is on, we don't see them.
I take it that means this is a feature you'd like. OK...
Phil wrote:
Edit: CorePNG codec isn't working well. In fact, FCEU either crashes when stopping recording or the AVI is 0 byte.
Maybe it's the same thing that's making uncompressed not work.
At replay movie it also links to all the savestates now.
/Edit
Like Phil already mentioned... the 1% speed (and 3 and 6) don't work properly anymore, which is, to me, one of the most importent options.
/Edit 2
I also noticed I couldn't see the author info for Angerfists, and Dehackeds run, and when I tried to make a rerecords in the movie, to change something, stopped the movie, and tried to watch it again, the movie wouldn't play.
At replay movie it also links to all the savestates now.
I don't understand what you mean by this.
Baxter wrote:
Like Phil already mentioned... the 1% speed (and 3 and 6) don't work properly anymore, which is, to me, one of the most importent options.
To fix it, activate Sound options->Use old update code. (Until the new update code is fixed for the < 25% case.)
Baxter wrote:
I also noticed I couldn't see the author info for Angerfists, and Dehackeds run, and when I tried to make a rerecords in the movie, to change something, stopped the movie, and tried to watch it again, the movie wouldn't play.
In the list of selectable movies, when you press "replay movie", you can select all the movies that have the same rom checksum AND all the savestates you made from that game.
I was talking about 1 movie... Angerfist and Dehacked made it, it's the megaman 4 movie that's just been submitted (you can download it at the submitted movies).
In the list of selectable movies, when you press "replay movie", you can select all the movies that have the same rom checksum AND all the savestates you made from that game.
Oh, so selecting those savestates isn't working. It probably broke from making any change to the items in that menu because it used to be hardcoded which items are the savestate ones.
Baxter wrote:
I was talking about 1 movie... Angerfist and Dehacked made it, it's the megaman 4 movie that's just been submitted (you can download it at the submitted movies).
Oh, OK, just found it. Uh, that movie file doesn't have any author info or ROM info or MD5 info in it at all. They must have converted it back to FCM with nesmock or something and then not bothered to use the --set options to restore those things, and not entered any author info in the first place. (I'll take a look at this other, more serious problem you mentioned about it, though.. edit: ok, I know what the problem is, this is a major bug but shouldn't be too hard to fix.)
In the list of selectable movies, when you press "replay movie", you can select all the movies that have the same rom checksum AND all the savestates you made from that game.
Actually, I still don't understand what you mean by this. Do you mean it used to do that and now it doesn't, or do you mean that it does it now but it shouldn't? I have never seen any savestates in the replay menu in any version of FCEU, and savestates are not even looked at at all when populating the movie list. Did you mean the "record movie" dialog instead of the "replay movie" one? That one does have save states listed, but they appear to be working for me.
He means, when savestates are in movies dir then you want to replay movie, savestates are considered movies in file box. In other words, FCEU should only put .fcm file only.
Oh, I didn't know it did that, as my savestates aren't in the movie dir.
BTW (Andy), optimizing do_video_conversion() is making encoding a heck of a lot faster, that was a good idea to do that.
I can't compile the latest version using any of the 3 compilers available for Ubuntu 5.10.
...
...
mappers/6.c:74: error: ‘apIRQHook’ undeclared (first use in this function)
...
apIRQHook? That file says MapIRQHook on that line. Sounds like your sed ate a character after the line break. Maybe not all of the line breaks are Windows-style and it will take a more complicated replacement (than the one currently listed) to handle it properly.
I fixed a bunch of bugs in FCEU and added a few minor features:
Found what really made the "random desync bug" happen, and hopefully it's gone for good now.
Fixed a bug where re-recording from a movie file that had gone through nesmock would corrupt the movie header.
Fixed output of some AVI codecs (including uncompressed) to not crash.
Optimized AVI output - it should be much faster now.
Fixed slow-motion of things below 25% speed
Fixed something with fast-forward
Frame counter and/or input display now go into AVI recordings. (It won't be legible if the codec's video quality is too low, of course.)
Save state and other messages aren't instantly obliterated by a running frame counter / input display anymore.
You can replay the currently playing movie from the start (without browsing to it) by choosing to Reset the emulator while a movie is playing (or while it is recording in read-only mode). This also fixes a bug because resetting during a movie used to inject a reset into the still-playing movie (causing certain desync).
Made save state files never appear in the movie replay list
Made the failure of nesmock to convert a movie (of a format it didn't expect) more likely to be detected.
Maybe fixed some bug having to do with loading non-movie save states in a movie or vice-versa or input looping. (Non-movie save states used to contain garbage movie data that was always loaded.)
Added XP-style support, which has the side-effect of making unicode characters (in the author info field) now display correctly instead of as ? characters (if you're running XP - otherwise it should be the same as before). Note that the extra manifest file in there (if using Windows XP) is required for fceu.exe to run.
Apparently some of the line breaks are inconsistent, which isn't fixed yet.
Great! You fixed everything mentioned!
There is one small problem though... when trying to play existing movies (like all movie on nesvideos) the emulator says:
"Warning: Found unknown save chunk of type 74.
This could indicate the save state is corrupted
or made with a different (incompatible) emulator version."
Then the movie plays, but all movie I tried desync at some point :(
Oh... well that sounds like a not-small problem to me. It's odd, since I was mainly playing old movies for testing and never saw that happen, but I'll check some other ones.
Hmz... you are right, I had bad luck at the ones I was trying out, most movies do play without desyncing.
It depends on the game I guess... but for some of the more important nes games the movies do desync.
