Emulator Coder, Site Developer, Site Owner, Expert player
(3574)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
FCEUX along with BizHawk is a primary emulator used to record NES TASmovies.
The src is maintained via svn at sourceforge.
It is linux & windows compatible.
The win32 version compiles with VS2010, VS2008 or VS2005.
Any coding help is greatly appreciated. If interested, I can be PMed on the forums.
We have a channel at freenode on #tasemu for discussing development issues.
Our bugs list is actively maintaned, so any bug reports are greatly appreciated:
https://sourceforge.net/tracker/?group_id=13536&atid=113536
Edit by DarkKobold: Updated irc channel
I just started using this the other day. And one complaint I have is, if I'm trying to create a save state, because I saved accidentally, I have to watch the entire video up to that point. This takes a long time. The max speed I can crank it to is 6400%. By my calculations, unless I've done something wrong, 6400% should get me anywhere in the movie right fucking fast. But it seems to be running, more realistically, much slower than that. Is this a bug only on my end? Is it possible to increase the playback speed, via programmatic patching, and is it possible to tell an emulator, given a movie file and a rom, to create a save file at a specified time point?
I am in a class where I need to contribute to an open source project. I think I might just have found the project, presuming it's not too complicated.
I just started using this the other day. And one complaint I have is, if I'm trying to create a save state, because I saved accidentally, I have to watch the entire video up to that point. This takes a long time. The max speed I can crank it to is 6400%. By my calculations, unless I've done something wrong, 6400% should get me anywhere in the movie right fucking fast. But it seems to be running, more realistically, much slower than that. Is this a bug only on my end? Is it possible to increase the playback speed, via programmatic patching, and is it possible to tell an emulator, given a movie file and a rom, to create a save file at a specified time point?
Try going into Config and then Sound. Under Quality, if it's not set to Low then set it to Low. Give that a try (I'm assuming that's your problem as it sounds like you're getting hardly any speed up). I honestly can not hear a difference in sound quality on either setting but that may not actually be what it's for (probably a priority setting or something like that).
Okay. My sound quality was on Low, but I turned it off anyway. So, on 6000%, the movie should be 60 times faster. This means, that for an hour video (60 minutes), it should only take 1 minute to view the whole thing. This is certainly not the case, at least on my end. How would it be realistic to improve this?
Another idea, more interesting to me, is adding a rewinding feature. It seems as easy as automatically saving states for some time interval, and just loading them back until the user finds the place he wants to be. Save states could add up in size, which is a concern. Is there a better way of doing this, or a good reason why it hasn't been done yet?
Emulator Coder, Site Developer, Site Owner, Expert player
(3574)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
First of all 6000% is only 60 times faster is your CPU can handle it. Also, at least right now, if the speed is faster than your cpu can handle FCEUX seems to go slower than a speed it can handle. For instance, on mine, 800% is faster than 6400%. Secondly, you should be using turbo instead. And in the new release, turbo will be mighty fast.
As far as the sound, turning off the sound doesn't keep it from processing. For instance, if quality is on highest but sound is turned off, it will still go slower. It is on the to do list to look into that.
As for rewind, it already exists in FCEUX and is called auto-save. Enable it in the config menu and assign a hotkey to load last auto-save. It works like what you describe except there is a limit of 4 slots and they save at 256 frame intervals.
Damn. There goes my idea.
What about being able to provide a specific time in a video, and having it go there? I imagine graphic rendering and sound take a lot of the processing time. Couldn't we just disable outputting the video and sound to the screen, but having the game play the keypress file until a certain point, at which time functionality returns as normal for the user?
Emulator Coder, Site Developer, Site Owner, Expert player
(3574)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
The long awaited FCEU 2.1.0 is now released: http://fceux.com
This is a major release that features a multitude of fixes and features for TASers. See the changelog for details (its massive and I don't want to paste it here).
One note though. If you use your pre-existing fceux.cfg, most of your hotkeys will be "off by 1". My apologies!
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
Nice improvements. I played around with this emulator this morning, and it's looking really cool.
Perhaps I'm the only one, but I personally miss some features that Memory Viewer had in the old FCEU. More precisely, these features:
(If you're not familiar with the memory viewer, here's what it looks like.
I will refer to the fields as shown in the picture above.
*Memory poke: This still works in FCEUX, but I found it a bit more convenient in the old FCEU. In FCEU, you could enter a RAM address in field A, and enter a hexadecimal value in field B. When you press "Poke Me!", that address was instantly set to that value. This can still be done in the Hex editor, but I find it a bit more inconvenient because it can take some time to find the right address. Perhaps a solution where you keep Hex editor as it is, but add this "Poke me!" feature that FCEU had?
*Memory file dump: You could dump the values of all addresses from RAM position C to D. When you pressed "Memory file load", field E, the emulator loaded these RAM values. This tool is really useful for finding RAM addresses - Let's say you're looking for the RAM address for Boss HP in a game. If you store all RAM addresses from 0000 to 01A0 when Boss HP is 1, and then load this file when boss HP is 5, and his HP doesn't change, you know that the RAM address for boss HP is not between 0000 and 01A0.
Perhaps I'm the only one who really uses these old features. :) But it would be nice to see them implemented, it's the only reason I still hang on to ol' .28, otherwise FCEUX is superior.
*Memory poke: This still works in FCEUX, but I found it a bit more convenient in the old FCEU. In FCEU, you could enter a RAM address in field A, and enter a hexadecimal value in field B. When you press "Poke Me!", that address was instantly set to that value. This can still be done in the Hex editor, but I find it a bit more inconvenient because it can take some time to find the right address. Perhaps a solution where you keep Hex editor as it is, but add this "Poke me!" feature that FCEU had?
Better: Have a "Go to address..." shortcut. Ctrl-G maybe (if not customizable?).
Click that, type in an address in hex, and the hexeditor scrolls to that address and automatically selects the correct offset.
I was actually missing this feature, because Transhexltion (or whatever) has it, and VBA hsa it (although much crappier)... it would make jumping around a lot easier and faster, especially when trying to scroll to 0xC500 from 0x0100.
*Memory file dump: You could dump the values of all addresses from RAM position C to D. When you pressed "Memory file load", field E, the emulator loaded these RAM values. This tool is really useful for finding RAM addresses - Let's say you're looking for the RAM address for Boss HP in a game. If you store all RAM addresses from 0000 to 01A0 when Boss HP is 1, and then load this file when boss HP is 5, and his HP doesn't change, you know that the RAM address for boss HP is not between 0000 and 01A0.
File -> Dump RAM. Though it's far easier to:
- Select the bytes you want to copy
- Edit -> Copy
- Open a text editor, any will do
- Paste there
- When ready to restore your RAM copy, select all of the text you pasted and copy it to the clipboard
- Go to the starting offset in the hex editor and select "Paste"
Seems a lot easier (at least, for me) than having to mess with files. Though I do agree that having an option to dump selected memory and load it into an offset would be useful in addition, this is an excellent substitute for the time being.
Perhaps I'm the only one who really uses these old features. :) But it would be nice to see them implemented, it's the only reason I still hang on to ol' .28, otherwise FCEUX is superior.
Perhaps instead of just copying old features, we could improve them. :)
Joined: 10/27/2004
Posts: 1978
Location: Making an escape
Nice. But this version reintroduces the "FCM no longer supported" error message bug.
Edit: Some functions also seem to be performing slowly. It takes nearly a second to load a savestate, a couple of seconds when a movie is active. This is odd, because I wasn't having this issue when I started. :/ (I've tried restarting the emulator, but that doesn't work)
Edit 2: I seem to have narrowed things down a bit. The repetitive error message seems to come from me moving the dll files*; putting them back got rid of the problem. However, their presence has no impact on the load time for save states.
On that note, I've looked into that a little bit. It would seem that the problem states are ones attached to movie files, and the further along the movie the state is, the longer the state takes to load. Plus, it recently went from two or three seconds to nearly ten to load one, even though I hadn't moved.
*Explanation: when I saw how many .dll files were in the zip, I decided to try and give them their own folder to keep from cluttering up the main folder, which apparently didn't work out. Do we really need this many dll files? If so, I would like to set a directory for them, if such would be possible.
A hundred years from now, they will gaze upon my work and marvel at my skills but never know my name. And that will be good enough for me.
Emulator Coder, Site Developer, Site Owner, Expert player
(3574)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Randil wrote:
*Memory poke: This still works in FCEUX, but I found it a bit more convenient in the old FCEU. In FCEU, you could enter a RAM address in field A, and enter a hexadecimal value in field B. When you press "Poke Me!", that address was instantly set to that value. This can still be done in the Hex editor, but I find it a bit more inconvenient because it can take some time to find the right address. Perhaps a solution where you keep Hex editor as it is, but add this "Poke me!" feature that FCEU had?
I don't know if you are familiar, but you can right-click a value and select "freeze". I think a better way of implementing your idea would be to add a "Freeze As.." menu option under freeze.
Emulator Coder, Site Developer, Site Owner, Expert player
(3574)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Ferret Warlord wrote:
It would seem that the problem states are ones attached to movie files, and the further along the movie the state is, the longer the state takes to load. Plus, it recently went from two or three seconds to nearly ten to load one, even though I hadn't moved.
Obviously movie savestates would be slower since they are storing movie data. However, they shouldn't be that slow unless you have a really slow computer! IIRC, you have vista. Problem is, no developr does. So Vista is in a "Use at your own risk state". (Perhaps there is a Vista user would be willing to help fix Vista related bugs)
*Explanation: when I saw how many .dll files were in the zip, I decided to try and give them their own folder to keep from cluttering up the main folder, which apparently didn't work out. Do we really need this many dll files? If so, I would like to set a directory for them, if such would be possible.
If you want to use Lua, you must have all those .dll files in that folder. If you don't use Lua, delete all of them but 7z.dll and you will be fine. You can set them to another directory. Acmlm & I tried to get them to be read from another folder but that failed. In a future release, I hope to find a way to get it set up that way.
Joined: 10/27/2004
Posts: 1978
Location: Making an escape
adelikat wrote:
Obviously movie savestates would be slower since they are storing movie data. However, they shouldn't be that slow unless you have a really slow computer! IIRC, you have vista. Problem is, no developr does. So Vista is in a "Use at your own risk state". (Perhaps there is a Vista user would be willing to help fix Vista related bugs)
Obviously, but this has never been a problem for any emulator I've used, including the previous FCEUX. They've all taken at most a tenth of a second to load, maybe half a second to a second if the CPU was busy at the time. And I use XP.
It's good to know I can safely get rid of those dll's, though. I'm not going to be dabbling in lua anytime soon.
Edit[/b]: Yes, definitely something is up with the new release. I just re-downloaded 2.0.3, and the movies and save states created with the new version took forever to load with it, but went back to no time at all as I started replacing them with the older version.
A hundred years from now, they will gaze upon my work and marvel at my skills but never know my name. And that will be good enough for me.
*Memory poke: This still works in FCEUX, but I found it a bit more convenient in the old FCEU. In FCEU, you could enter a RAM address in field A, and enter a hexadecimal value in field B. When you press "Poke Me!", that address was instantly set to that value. This can still be done in the Hex editor, but I find it a bit more inconvenient because it can take some time to find the right address. Perhaps a solution where you keep Hex editor as it is, but add this "Poke me!" feature that FCEU had?
I don't know if you are familiar, but you can right-click a value and select "freeze". I think a better way of implementing your idea would be to add a "Freeze As.." menu option under freeze.
No, no. You missed his point; he meant finding the address and poking in a byte, i.e. typing in a value.
What he meant was that old FCEU had 2 textboxes, "Address" and "Value" -- clicking "Poke" would set address to value immediately, only once.
The equivalent function in FCEUX is finding the address in the hex editor and typing in a value.
As for a good idea, skip "Freeze as" and do this instead: when you have frozen an address, make typing in a new value freeze it to that one instead. :)
A method that works well without that is to pause the emulator, type in a value, then freeze it and unpause, unfreezing if necessary.
Emulator Coder, Site Developer, Site Owner, Expert player
(3574)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Oh. Then Hex Editor can do just fine with that feature. So Randil is just complaining about having to scroll down to the address.
In that case, I like the idea of a Go to address (with ctrl+G hotkey) feature.
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
adelikat wrote:
Oh. Then Hex Editor can do just fine with that feature. So Randil is just complaining about having to scroll down to the address.
In that case, I like the idea of a Go to address (with ctrl+G hotkey) feature.
Yeah, Xkeeper explained my point very well. Overall, I think the Hex editor works well as it is, it's just that it takes me some time to find the right address among all the others. :) The "Go to address" feature sounds intriguing to me too.
Hmm... I've crashed into a few issues with 2.1.0:
While saving and loading states repeatedly trying to optimize some game, the load/save states take several seconds to finish, and each new one lengthened the time dramatically. A later look at the movie file, and I've got something that takes up about 22 MB. For something less than 2 minutes of gameplay, it sure takes up a lot of space all of a sudden. I have a backup copy of the movie file, so it's not like I lost anything with a ballooned up file I can no longer use (with any speed).
The related save-states are also hit with this size increase. I know it needs to keep entire movie files for bullet-proof rerecording, but these aren't small in the least. A few MB isn't a typical size, as far as I know.
The origin of the movie file is from version 2.0.2, copied over to continue in 2.1.0 . Whether or not this has anything to do with it, it's a mess. I suppose one question to ask is what's in that 22 MB, when the original file is certainly less than 0.2 MB.
Moving "another window" (such as Notepad) around the FCEUX screen sometimes causes part of the FCEUX screen to paint itself into "another window". It sticks with "another window" for a while as I move it around a bit. It clears itself back to normal after a while.
For lack of better words at the time, I refer to the same window as "another window" using quote marks, as I don't keep moving new ones around.
Memory watch puts the reported value of the first address into an unusual spot, that is, about two lines above where it should be. Irritating, but nothing major.
Just stuff I observed. Seems I'm going to keep using 2.0.2 for a while. I'm not sure how I can really give any support, other than say whatever is bugging me, in order to call attention to whatever the problem might be. I recognize that there is progress, and appreciate the time put into this.
Emulator Coder, Site Developer, Site Owner, Expert player
(3574)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
22mb is certainly wrong! I didn't not knowingly do anything that should have ballooned the movie or the savestates. Would you mind sending me your 22mb .fm2 and associated savestates (the ones that are larger than normal).
EDIT: Also, btw, .fm2 is a text based format. So you can open your movie in something like wordpad and get an idea for yourself what is going on.
Opening it myself using Notepad is an idea. Why I never thought of that after doing it to copy parts of my other runs... Using Notepad, I saw whitespace. Lots and lots of whitespace. Apparently, the whitespace is between the header and the movie input.
As for sending it, that might be a little tricky. Scratch that, putting it in a zip file might be good -- I'm sure it can compress megabytes of unchanging information really good. And indeed, 22MB of movie file is turned into 24 KB.
I'll see about sending it over, somehow. What would you suggest how I should send it? I have an idea myself, but I'd like to wait on that for a bit.
Joined: 10/27/2004
Posts: 1978
Location: Making an escape
I like to use Filefront.
Glad I'm not the only one who had this issue. I suspected a ballooning filesize was the problem, but I replaced the files before I could check.
A hundred years from now, they will gaze upon my work and marvel at my skills but never know my name. And that will be good enough for me.
I sent the files over, so I won't likely need further suggestions. Letting everyone here know that my files are now in someone else's hands. Hopefully, this will help to fix the bug that somehow appeared, seeing the actual result directly, rather than reading me type about it.
Emulator Coder, Site Developer, Site Owner, Expert player
(3574)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
FatRatKnight, thanks. I know exactly what the problem is now (and it wasn't me that did it, yay ;) )
For now you (or anyone with this issue) can fix the problem by deleting those extra null characters at the author field (or better yet, delete the author field entirely so they don't come back). There was 27.8 megabytes worth of those!
I'll get a fixed release for this asap
This bug was introduced when I committed a patch to fix up the SDL build. Prior to this, it crapped out when converting the UTF8 author name to UTF32 when the string's length was not even. This happened for converting fcm files to fm2 and when playing back somefm2 files as well.
The algorithm we use was found at http://www.codeproject.com/KB/string/UtfConverter.aspx (-> src/utils/xstring.cpp). Originally, it was the first version, now it's the second one. In both cases: sizeof(wchar_t) == 4 on Linux. I have absolutely no idea on how to fix this or why it even failed in the first place.
So if anyone knows what might have caused this or how to work around or fix it, suggestions/patches/hints/whatever are very welcome.
