Joined: 8/3/2004
Posts: 100
Location: Michigan, United States
That's good another bug that will be fixed soon
Cool, that's good to hear. It doesn't matter what settings I was using. I had modified all of the settings, and nothing would work properly, even setting the buffer really high.
Also, when I used "use old update code" it would studder occasionally. Not skipping/crackling/popping, but almost like the sound was rewound and played back for a half-second. It would happen every 30-60 sec or so.
This is all at 100% speed.
I have various problems with the sound in FCEU off an on, with no direct causes that I can tell. I think the sound code is pretty unstable/buggy and is likely overrunning some buffers on playback... Sometimes it changes when I change FCEU versions, but it seems they eventually happen in any version. The most common problem for me is that the sound lags behind a lot (mario jumps, and 3-6 seconds later I hear the jump sound), but I haven't heard of anyone else having that problem. When I get cracking and popping sounds, I have the most success getting rid of it by turning the sound buffer really low (after turning it high and restarting FCEU and playing some game for a few seconds). EDIT: I found that actually increasing the buffer size fixed the delay problem, but the amount it needs to be increased to to avoid it isn't always the same. Changing the buffer size shouldn't cause this sort of behavior...
Phil wrote:
That's good another bug that will be fixed soon
Not quite yet, but hopefully soon, yes. The code determining what happens when it reads the memory is pretty complicated, but I can't find anything wrong with the way it's set up, so I haven't found what exactly is making the value be wrong. It might still be some unsaved variable I haven't found/noticed, since the bank-switching doesn't appear to happen until after it screws up, and if you advance to the same frame as the save was on and load it, it works fine, even if it crashes or resets when you load the save from any other frame.
OK, I think it's fixed, at least in MMC1 games. It was a problem with the saving, so to test it with that savestate you had, load the state then save it again, then test with that newly saved state.
Here's a new FCEU version.
- Fixed the reset bug with the MMC1 mapper saving
- Added auto-hold key functionality, mainly to make 2-player runs easier to make (set it in the input config dialog)
- Fixed the splitting of large AVIs (thanks to Andy Olivera for the fix)
- Made frame counter and input display status saved across FCEU sessions
- Increased the version number to 0.98.15 since leaving it the same was generating confusion
windows binaries:
http://www.filespace.org/nitsuja/fceu.zip
mirror: http://www.savefile.com/files/4359024
source code:
http://www.savefile.com/files/7104156
So another new version? I haven't tested the "Fixed the reset bug with the MMC1 mapper saving" if it is really ok but I trust you. So I edited my first post again.
I don't remember if "Pause the emu, play a movie in read only then save a savestate then load that savestate. It is recording from now. Well I am not sure if it is really that.
But I found that if you're playing in read only 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. (This bug is half fixed. You can still do those steps but the movie won't last eternally like before) " was fixed but I will retest with this latest version and report you.
[Edit]: Are you sure the source is updated because when I compile it myself, it says it is the 0.98.13 version in the about dialog and in you binary, it says 0.98.15.
Are you sure the source is updated because when I compile it myself, it says it is the 0.98.13 version in the about dialog and in you binary, it says 0.98.15.
Did you make the resources file with windres and recompile drivers\win\main.c?
Phil wrote:
I haven't tested the "Fixed the reset bug with the MMC1 mapper saving" if it is really ok but I trust you.
Well you can test it pretty easily with that state you posted, except make a new state on that frame to test with.
$ gcc src/drivers/win/main.c
src/drivers/win/main.c: In function `ShowAboutBox':
src/drivers/win/main.c:223: error: syntax error before "FCEU_VERSION"
In file included from src/drivers/win/main.c:276:
src/drivers/win/sound.c: In function `RawWrite':
src/drivers/win/sound.c:207: warning: use of cast expressions as lvalues is deprecated
Btw, I am compiling it the normal way. Maybe it's related of use of gcc 3.4.5 and you 3.4.2?
Then you must not have the right source, because I just downloaded it from the link I put above (http://www.savefile.com/files/7104156) and checked inside "fceu-0.98.15-src\src\Makefile" and found -DFCEU_VERSION=\"0.98.15\" in there.
It's because you haven't done it clean.
Normally, you should configure then make to compile any source(Though, it's win32, I agree that you can include a preconfig file but you didn't mention it). And ./configure is overwriting you config file.
Plz,include the version number in source not the makefile.
I see now one place where I missed changing it (because I didn't look for the version number outside of the src folder), that's probably what's making configure overwrite it for you. It shouldn't be hard to make it only defined in one place in source, though.
Joined: 4/20/2005
Posts: 2160
Location: Norrköping, Sweden
One question and one request:
1. After having recorded a movie with 0.98.15 and then choosing "Replay movie", it says on the info that the movie was done with version 0.98.13... This is of course no big thing at all, but I'm guessing it's an easy thing to fix.
2. Would it be possible to implement turbo buttons for the other buttons besides A and B? I know that there aren't a lot of places you need to have turbo functions for the other buttons, but it could prove useful at times.
Besides these small details, your latest patch is very good. :)
Major bug with AVI encoding. After 15:14 of recording, it seems to stop recording video. I've tried with both Techsmith and AVIZlib codec. It happens with the latest version. It never occured before with blip's version. Note that it also happens with an older version of nitsuja. I thought maybe it was me but today, with more testings, I know it is not the case.
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
You mean version 13 by nitsuja?
I successfully made an AVI of my 19 minutes long Final Fantasy III work in progress run with it. It seems to work fine to me.
Note that I'm using the Windows version.
I would like an option to add logo when recording. It will prevent me to re-encode the AVI twice.
By logo, I meant the small intro in published movies.
I think it should be an option that is always activated. If no file selected then there's no logo. When one is chosen keep it and save it's path to config file.
Actually, the video is just corrupted, Mencoder(probably Vdub can) was able to repair it.
Are you saying that the AVI splitting feature is resulting in a corrupted AVI, or that it didn't split early enough to avoid corruption, or that it's not really a problem with FCEU after all?
Phil wrote:
I would like an option to add logo when recording.
What is the logo file exactly, an animated GIF or a folder of PNGs or a short AVI or something?
Actually, the video is just corrupted, Mencoder(probably Vdub can) was able to repair it.
Are you saying that the AVI splitting feature is resulting in a corrupted AVI, or that it didn't split early enough to avoid corruption, or that it's not really a problem with FCEU after all?
No, my video is only 700 MB but anyway it is probably a minor problem. Maybe it's from my side.
nitsuja wrote:
Phil wrote:
I would like an option to add logo when recording.
What is the logo file exactly, an animated GIF or a folder of PNGs or a short AVI or something?
How about all of them?
Something that I just found:
When recording AVI it relies on FCEU's Drawing Area option. Could you set it to always use 256*240 for people that are using different reolution when playing. It's just that I just wrote a guide and someone got a problem because of that.
I don't know if that's a good idea - what if you want to output a different height than 240? I thought the height for NTSC was supposed to be less than that, 224 (First line=8, last line=231), although I just checked and both of mine were at a default of 240, and the option doesn't change on its own.
Emulator Coder, Site Developer, Site Owner, Expert player
(3598)
Joined: 11/3/2004
Posts: 4738
Location: Tennessee
Well I was told to post my FCEU problem here...
I've been TASing the game Dragon Warrior 4 for about 8 month now. I'm using Phil's patched version of blip's FCEU because Nitsuja's didn't exist until I was halfway done and it desynchs in it.
anyway,
Whenever I character is leveling up, the game frequently locks up during the re-recording process. Loading a savstate prior to this lock up correct the problem SEEMINGLY. Upon replay, the point where I loaded the savstate will inevitably desynch. This is a nasty bug since I record large portions of game only to find I have to redo it. Also, it seems to become more common as I approach the end of the run (at this point the run is almost 2 hrs long). The length of the movie may not have anything to do with it though, since I do more leveling up at the end, so I could just be perceiving it to be more common.
