Locked



1 2
20 21 22
29 30
Joined: 9/26/2007
Posts: 55
Location: Michigan
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.html http://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.
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Yeah, they have been down for awhile. Fortunately JXQ is da man and has taken the time to host all the emulators. http://jxq.skuzz.com/emu/
It's hard to look this good. My TAS projects
Joined: 9/26/2007
Posts: 55
Location: Michigan
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.
Post subject: Re: FCEU 0.98.16 development (Current bugs in 1st post)
mz
Emulator Coder, Player (79)
Joined: 10/26/2007
Posts: 693
Phil wrote:
Looking over the changes since 0.98.15 (or possibly earlier) to fix whatever is causing the palette corruption and AVI recording problems (High priority)
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...
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.
Post subject: Re: FCEU 0.98.16 development (Current bugs in 1st post)
Active player (411)
Joined: 3/16/2004
Posts: 2623
Location: America, Québec
mz wrote:
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)
It seems to work well.
mz wrote:
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.
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.
mz wrote:
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...
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?
mz
Emulator Coder, Player (79)
Joined: 10/26/2007
Posts: 693
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.zip http://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).
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.
Active player (411)
Joined: 3/16/2004
Posts: 2623
Location: America, Québec
Ok, just edited the 1st post. *Avi Recording fixed *Link in about dialog is ok
Post subject: Re: FCEU 0.98.17 development (Current bugs in 1st post)
mz
Emulator Coder, Player (79)
Joined: 10/26/2007
Posts: 693
Ok, here's version 0.98.18: http://popibot.com.ar/fceu-0.98.18.zip http://popibot.com.ar/fceu-0.98.18-src.zip
If you play a movie and you try to load a state that isn't from the movie, you get an error message but it starts recording from now. (High priority)
That bug should be fixed now.
When FCEU does have 2 windows opened such as "Memory Watcher", FCEU becomes CPU hungry and it causes many problems like "Turbo is unstable".
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.
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.
P.JBoy
Any
Editor
Joined: 3/25/2006
Posts: 850
Location: stuck in Pandora's box HELLPP!!!
Emulator Movie Front has seemed to have lost compatibility post-0.98.5. Is this a problem with emumovfront or with FCEU?
mz
Emulator Coder, Player (79)
Joined: 10/26/2007
Posts: 693
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.
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.
P.JBoy
Any
Editor
Joined: 3/25/2006
Posts: 850
Location: stuck in Pandora's box HELLPP!!!
Sweet, thanks
Active player (411)
Joined: 3/16/2004
Posts: 2623
Location: America, Québec
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.
mz
Emulator Coder, Player (79)
Joined: 10/26/2007
Posts: 693
FCEU v0.98.19 http://popibot.com.ar/fceu-0.98.19.zip http://popibot.com.ar/fceu-0.98.19-src.zip *New command line argument: -playmovie "moviefile.fcm". It will play the movie automatically in read-only mode. Emulator Movie Front works fine now.
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.
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3573)
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.
It's hard to look this good. My TAS projects
mz
Emulator Coder, Player (79)
Joined: 10/26/2007
Posts: 693
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).
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.
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Well, thanks for what you have done. Its awesome. And I am glad _someone_ is interested it fixing fceu up some.
It's hard to look this good. My TAS projects
Emulator Coder, Former player
Joined: 10/2/2005
Posts: 563
Location: Toronto, Ontario
mz wrote:
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
mz
Emulator Coder, Player (79)
Joined: 10/26/2007
Posts: 693
FCEU v0.98.20 http://popibot.com.ar/fceu-0.98.20.zip http://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
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.
Joined: 11/26/2005
Posts: 285
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.
mz
Emulator Coder, Player (79)
Joined: 10/26/2007
Posts: 693
FCEU v0.98.21 http://popibot.com.ar/fceu-0.98.21.zip http://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)
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.
Active player (411)
Joined: 3/16/2004
Posts: 2623
Location: America, Québec
Ok, I've just tested that newest release as I didn't take time to test precedent versions and here my reports.
mz wrote:
If you play a movie and you try to load a state that isn't from the movie, you get an error message but it starts recording from now. (High priority)
That bug should be fixed now.
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.
mz
Emulator Coder, Player (79)
Joined: 10/26/2007
Posts: 693
Phil wrote:
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.
Active player (411)
Joined: 3/16/2004
Posts: 2623
Location: America, Québec
mz wrote:
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à.
mz
Emulator Coder, Player (79)
Joined: 10/26/2007
Posts: 693
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.
Active player (411)
Joined: 3/16/2004
Posts: 2623
Location: America, Québec
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. ;)
1 2
20 21 22
29 30

Locked