Just did a whole format here; anyone else notice that all the mirrors for the rerecording versions of FCE are down?
[edit]
Well I can't read moonspeak but Google can.
http://www.emufc.com/tool.htmlhttp://www.emufc.com/upload/FCEU.rar
[/edit]
Basically this is for anyone else needing to grab them so they can watch the new Mario 3 run.
My my, that's so well done it brings me back to they heyday of Zophar's. :}
Under his most wanted he mentions more Linux builds which brings me to a question in the form of a statement: I find it curious that this site hasn't created it's own Apt repository for Debian/Ubuntu users to very easily add any version of a rerecording emulator or tool to their systems.
Probably not the thread for that, though. So, FCE Ultra... is there any possibility of getting HQ#X rendering windowed? When I take .16 fullscreen the palette goes wonky on me.
I was planning to do this, so I got the source from this post by DeHackEd. And... Well, it looks like that version doesn't have these bugs.
I'd like to know if anyone else can confirm this. Here's the version I compiled for Windows:
http://popibot.com.ar/fceu.zip(Note: I changed the version number to 0.98.17 to avoid confusion)
I was trying to do all this so I could be able to encode my submission, because the movie file desyncs with anything but 0.98.16, and to my surprise, DeHackEd's version records avi files without issues (no black screens) and doesn't desync.
EDIT: Today I got the "official" source from here, and it doesn't have these bugs neither... I guess no one has the real "Apr 21 2006" build source. I don't know why we use that version, anyway...
It seems to work well.
Indeed, it seems the audi and video stay in sync unlike older versions. However, I didn't 100% tested and confirmed it. But it sounds good so far. At least AVI recording is back.
Are you telling us that we could have compiled the source and AVI recording was working? If so, that doesn't surprise me.
The history of the .16 versions, yes, in plural, is weird. Luke had released some .16 versions then a .17 then switch back to .16 for unknown reasons. So, there are many .16 versions available and it appears that everyone doesn't have the correct version.
My other theory about the .16 version which AVI recording isn't working well is that it was built with the correct source but for some obscure reasons, maybe a beta version of UPX was used so that it has corrupted the .exe.
Another theory is that, indeed, the .exe available wasn't built with that source. The thing is that Luke himself had compiled that .exe . He might have 2 directories and built the wrong FCEU source.
If no, then I don't understand what you mean. :P
Anyway, I am currently in break of FCEU as I TAS SCV4 now. But if someone find a bug due to that build, post it. If no one, I will update the 1st post.
I agree with mz for the .17 version maybe .18 would be better as there is already one .17 version floating around on the net.
Mz, while at it, could you remove Luke's link website in FCEU about window as it is dead?
Ok, thanks for testing Phil. And yes, you understood well. :P Sorry for my english...
I uploaded the new version and its source here:
http://popibot.com.ar/fceu-0.98.17.ziphttp://popibot.com.ar/fceu-0.98.17-src.zip
The source has the missing file ("Makefile.in") and a few fixes in "file.c" and "video.c" so it doesn't throw errors during compilation. I also changed the link in FCEU about window to this thread.
I plan to release a .18 version soon, with some bug fixes (if I can fix them :P).
Ok, here's version 0.98.18:
http://popibot.com.ar/fceu-0.98.18.ziphttp://popibot.com.ar/fceu-0.98.18-src.zip
That bug should be fixed now.
The only change I made related to this is that now "Memory Watch" window will only update when emulation is not paused, so CPU usage should be much lower when you're only using frame advance. CPU usage should still be high if you're playing at normal speed, so "Turbo is unstable" and related bugs are still around.
It's most likely a problem with FCEU. Emulator Movie Front only seems to work with a special FCEU version.
As far as I understand, it passes this command line argument: -playmovie "moviefile.fcm" "romfile.nes"; but FCEU was never coded to read the "-playmovie" argument.
I can't find the source with that nitsuja's modification, so I'll try to make my own and re-release v0.98.18 with this.
I've never seen a "real" Windows version with -playmovie. However, the Linux version does have that command or similar one. And I remember Bisqwit had created a patch to build a Linux version with Cygwin to work on Windows.
So that might be that version.
To avoid confusion for having two 0.98.18 versions, I recommend it to be 0.98.19. And someday when most of the major bugs and new features are added in FCEU, I recommend it to be named 0.99.
Emulator Coder, Site Developer, Site Owner, Expert player
(3574)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
mz, you are my hero.
the AVI thing was long overdue. Thanks so much. Is there any hope you might fix a few other bugs in that list? At least a few seem like relatively simple tasks.
I personally would really like to see the memory watch be less of a resource hog. As FCEU frequently causes my computer to crash when using memory watch and having 2 fceu's open.
I did a minor improvement to Memory Watch in v0.98.18, but you'll only notice it if you're working with frame advance only. I'd love to see it not being such resource hog too, but sadly my knowledge in C and maths is really poor. Actually, I don't know C at all; this was the first time I saw some code. :P
Anyway, someone better than me should try to see if he can improve the UpdateMemWatch() function in memwatch.c; it's a really short function, but it's the one that takes all of the CPU power. I can't understand anything in it.
And I tried to fix other bugs too, but as I said, my C skills are really poor. I'll try to read some books about C now it got me interested in it, so maybe someday I will make a proper new version, with updated mappers and boards from fceu-mm too (I'd really like to have Startropics 1/2 and Power Blade 1/2 fixed someday).
It's good to see work being done on FCEU. I've got some time tonight so I'm going to see if i can merge some new mappers and boards into the source mz's working on. I haven't really done any work with C since college, but I'm assuming I still remember how :P I said I'd do this before, maybe this time I'll actually accomplish something :D
FCEU v0.98.20
http://popibot.com.ar/fceu-0.98.20.ziphttp://popibot.com.ar/fceu-0.98.20-src.zip
*Memory Watch uses much less CPU power now, in exchange of a slower refresh rate. Problems such as "Turbo is unstable" and crashes should be gone now.
Specifically, Memory Watch updates like this now:
*When emulation isn't paused it updates ~2 times per second.
*When emulation is paused it updates when you manually frame advance or load a savestate.
I'd like to hear some feedback on this, specially if someone thinks it doesn't update fast enough when playing in real time or if it should also update with some other action when it's paused.
@Maximus
It's great to read that. :D
In what language is FCEU written, really? I'm interested in programming, but I haven't settled for what to learn yet.
And I think learning how to modify FCEU and compiling it is a good exercise (and fun), so whether I'm going to learn C or C++ may be dependent on the source code of this program.
Also, those who feel like it are encouraged to PM me about what language I should learn and why.
Edit 10 seconds after posting: It's C, isn't it? I can't read properly. But still, go ahead and PM me.
FCEU v0.98.21
http://popibot.com.ar/fceu-0.98.21.ziphttp://popibot.com.ar/fceu-0.98.21-src.zip
*Memory Watch update speed is configurable now:
Explanation of settings:
*Low works exactly the same as v0.98.20. It's the default and recommended setting.
*High should work like v0.98.16 (very high CPU usage and lot of problems, but very smooth refresh rate).
*Normal is something between these two.
So... Everyone should configure it according to their needs and computer specs. Most people should be ok with low update speed, I've been TASing a couple of games with this setting without any issues.
(This will be my last release if no one comes up with bugs introduced with my changes. I'm sorry for the version numbers mess. And yes, I know that menu looks like crap. :P)
Ok, I've just tested that newest release as I didn't take time to test precedent versions and here my reports.
I've just tested it. I wouldn't say it's 100% fixed. The movie doesn't start recording, however, the state is still loaded and the movie plays endlessly where the state is loaded.
I will consider it 100% fixed when FCEU won't load such savestate and pop up an error message then continue playing the movie as where it was before the user requested to load such savestate.
mz wrote:
*Memory Watch uses much less CPU power now, in exchange of a slower refresh rate. Problems such as "Turbo is unstable" and crashes should be gone now.
Memory watch is indeed ok but not Memory Viewer.
I hope you will take the time to fix such issues and that one is really not your last version.
Edit: Updated the 1st post.
The movie doesn't start recording, however, the state is still loaded and the movie plays endlessly where the state is loaded.
I will consider it 100% fixed when FCEU won't load such savestate and pop up an error message then continue playing the movie as where it was before the user requested to load such savestate.
Uhm... It looks like we're not talking about the same bug, as I've never experienced that. Can you give me some precise steps to reproduce this bug?
Phil wrote:
Memory watch is indeed ok but not Memory Viewer.
Yeah, you're right. I've never used Memory Viewer, so I didn't want to mess with it. I'll see if I can make it update at the same speed as Memory Watch, if that's ok.
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
Can you give me some precise steps to reproduce this bug?
1. Start recording a movie and save a state.
2. Start recording a new movie(again). Don't overwrite the previous saved state.
3. Play that new movie and load the state from the 1st movie.
Voilà.
I see. Actually, that's a different bug. It may be related to this one:
If you're playing in read only mode and opening a savestate that is not from the movie but from an other movie when the emu is paused and save a savestate, it is playing the movie using the last input key recorded in the savestate in an endless loop.
Sadly, there's no solution to this. As far as I know, FCM files don't have a unique ID, so the emulator can't know if the savestate is from the same movie or not.
The bug I fixed was this one:
1. Save a state without recording or playing a movie.
2. Start playing a movie in read+write mode and load the state.
3. FCEU would give an error but still start recording over the movie, overwriting everything from that point (as if it would have loaded a valid state from the movie).
This one was possible to fix because FCEU can detect if the state was saved while playing or recording a movie; but, as I said, it can't detect if the state is from the same movie, so your bug will always be there until someone changes the movie file format.
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
You are right, you really fixed the bug I wrote and meant in the 1st post.
For some unknown reasons I thought it was the one I did mention above.
Oh well, it's sad you can't fix it too as it is also annoying.
Edit:
mz wrote:
Sadly, there's no solution to this. As far as I know, FCM files don't have a unique ID, so the emulator can't know if the savestate is from the same movie or not.
Ok I just thought of something since there is no ID but isn't there a way that FCEU detects the movie will play endlessly or something? Well, why it plays endlessly with always same input? There must be something.
So maybe FCEU should still load the state but it plays the movie at frame x where x is the frame of the state was saved from any movie. So FCEU would still play the movie but probably out of sync.
Or even better, if IIRC, isn't savestate storing the movie withing it. So FCEU could verify in the savestate for the movie and check for Author info if it is matching.
Of course, I find useful to load state from another movie to make comparisons. So, instead of locking completely that, FCEU could inform the user that the State is probably not from the movie so it might cause problems or something. It is just an idea.
Edit2: Oh, I forgot that the bug is in read only mode only. That would make things simpler if my idea of "author info" could work. So, yes, you could block loading the state. Of course, it won't prevent states from different movies with same author info to not be used but anyway, just to replicate that bug itself is rather tricky. So I think it might be a good solution.
Another solution since the movie is stored in the state. FCEU could compare some 40 random frames that are under frame X, which is the frame the state was saved, and if the inputs match, FCEU load the state and play the movie.
Or if both solutions are possible, you could mix them for better accuracy. ;)