Because the way it was before was extremely inaccurate by any standards, fairly arbitrarily chosen (and not very consistent) RGB values that nobody bothered to look at changing for a long time. And, many people agree that BMF's palette is a quite accurate, and I don't see how it can be any worse a default than the previous one. I seem to recall there being complaints about how bad the FCEU palette was, as well.
Okay, but once you've got the palette to your liking, I think you should make it a .pal file anyway so people can use it in other emulators too.
put yourself in my rocketpack if that poochie is one outrageous dude
Updated FCEU:
- VS system now records coin inserts and stuff (it used to check IsPlaying instead of IsRecording, so that input never got recorded)
- FDS eject/insert disk is fixed. (it used to always call eject so you could never insert)
- Random timing/desync issues that were apparent in playback of Mario 3 movies were fixed (or, worked around, at least. The problem was in the sound code, of all places.)
- Made peripherals not capable of interfering with playback (I think)
- 800% speed and fast-forward now skip frames, and new speeds (1600%) were added.
- Made a .pal file for the palette, and threw in some others to choose from
Updated FCEU:
- VS system now records coin inserts and stuff (it used to check IsPlaying instead of IsRecording, so that input never got recorded)
I have tested it and it is fully working.
nitsuja wrote:
- FDS eject/insert disk is fixed. (it used to always call eject so you could never insert)
Tested and it works pretty well. Also, the bug with NES ROM is no longer there.
nitsuja wrote:
- Random timing/desync issues that were apparent in playback of Mario 3 movies were fixed (or, worked around, at least. The problem was in the sound code, of all places.)
Great work. After playing the movie 5 times a row, it played it fine.
nitsuja wrote:
- Made peripherals not capable of interfering with playback (I think)
Ok, here there's some problems. Imo, you should test with Arkanoid or I could send a movie of that game.
nitsuja wrote:
- 800% speed and fast-forward now skip frames, and new speeds (1600%) were added.
Good, it stills uses too much CPU ( 400% speed makes my CPU almost full loaded) for a NES emulator but well, I guess I will be happy with it now.
Btw, when you are about to play a movie, when movie filename is similar to ROM name, FCEU no longer put it in file box.
Ok, here there's some problems. Imo, you should test with Arkanoid or I could send a movie of that game.
Yeah, I'll test Arkanoid, maybe if I try adding recording support for peripherals sometime.
Phil wrote:
Btw, when you are about to play a movie, when movie filename is similar to ROM name, FCEU no longer put it in file box.
Oh, I forgot to say I made 2 changes with this:
- There is now a Movies directory configurable in the Directories dialog. It's no longer the same as the Saves directory, so maybe you have to set your movies directory for it to find them.
- Instead of putting it in the box only if the filename is similar, it actually puts everything in the box that has the same MD5 for the current ROM (so it should find many more movies than before to put there). I forgot that some movies have all 0's for the MD5 though, so it should probably be changed to also add movies with a similar filename.
Phil wrote:
Great work. After playing the movie 5 times a row, it played it fine.
BTW, you might want to test some other movies and make sure they still stay in sync also, especially games with auto-scrolling sections. I tested a few but not a whole lot. The problem before was that a variable was starting out basically random, so I had to pick 1 value to always start it as, and I picked one that worked for all the movies I tested with. It's possible that that some movies need a different starting value to stay synchronized, and that the value I picked could be better to support more movies. (The problem was not necessarily specific to Mario Bros 3.)
Phil wrote:
Good, it stills uses too much CPU ( 400% speed makes my CPU almost full loaded) for a NES emulator but well, I guess I will be happy with it now.
If you want to try it, let me know if I broke the AVI support more than it already was with that change. (I haven't tried any AVI features yet.)
Btw, when you are about to play a movie, when movie filename is similar to ROM name, FCEU no longer put it in file box.
Oh, I forgot to say I made 2 changes with this:
- There is now a Movies directory configurable in the Directories dialog. It's no longer the same as the Saves directory, so maybe you have to set your movies directory for it to find them.
- Instead of putting it in the box only if the filename is similar, it actually puts everything in the box that has the same MD5 for the current ROM (so it should find many more movies than before to put there). I forgot that some movies have all 0's for the MD5 though, so it should probably be changed to also add movies with a similar filename.
The problem, that new feature doesn't work either.
nitsuja wrote:
Phil wrote:
Good, it stills uses too much CPU ( 400% speed makes my CPU almost full loaded) for a NES emulator but well, I guess I will be happy with it now.
If you want to try it, let me know if I broke the AVI support more than it already was with that change. (I haven't tried any AVI features yet.)
Sound at highest quality was the problem. I can't notice any differences between low and highest. So I will use low. I haven't tested AVI encoding but anyway, this should be fixed.
Here's my 3rd update to FCEU:
- Fixed replay dialog auto-fill-list to use configured movie directory and work better overall
- Fixed sound bug in low-quality sound code of mapper 69 that made the sound of Gimmick! (J) hang on pausing the game
- Added several new mappers from the fceu-mm project
- Random timing/desync issues that were apparent in playback of Mario 3 movies were fixed (or, worked around, at least. The problem was in the sound code, of all places.)
Would this work to make Genitso's movie not desync? Because it still is.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
- Random timing/desync issues that were apparent in playback of Mario 3 movies were fixed (or, worked around, at least. The problem was in the sound code, of all places.)
Would this work to make Genitso's movie not desync? Because it still is.
If you mean his amazing/glitch run at the water world airship, no. There he got a playback desync (the same one that is now fixed) and then re-recorded from that incorrect state, so according to the movie input he is supposed to die there and auto-correcting it would mean the game state has to suddenly change in the same way it did when it desynced for him. (In other words, any timing change that fixes the desync there will make the movie desync even earlier unless you only watch from a save state that's late enough in the movie.)
But, I am pretty sure that the extent of the desync is that 1 frame of lag disappeared that he thought was there when recording, which means that that movie can be fixed simply by removing 1 frame from it right before he's supposed to jump to avoid death there.
The trick is to make sure the "Enable RGBA" option is checked. This is due to the fact that for some bizarre reason the AVI output is in 32-bit RGBA format, instead of the standard 24-bit. I don't think this would be too difficult to change, since those extra eight bits aren't used. A 2GB split shouldn't require more than an if() statement or two.
On the other hand, I've been staring at the AVI code to see if I could find the sound sync issue and the only thing I can see is this: in FCEUI_AVISoundUpdate the final line of code is...
avi_file->sound_samples += soundLen;
...where soundLen is the number of samples written to the file and sound_samples is the total sample count. Since the sync gets progressively worse(falling behind the video), I'm guessing this line is causing the last sample in one update to be overwritten by the first sample in the next update. If so, it should be fixed by changing the code to:
avi_file->sound_samples += (soundLen + 1);
Think you could give this a try the next time you compile, nitsuja?
If so, it should be fixed by changing the code to:
avi_file->sound_samples += (soundLen + 1);
Think you could give this a try the next time you compile, nitsuja?
This sounds too simple to work, but I can try it. I think it's more likely something to do with the speed modulation code and the intervals of calling the sound and video writing functions, or some hacks in the sound code.
This sounds too simple to work, but I can try it. I think it's more likely something to do with the speed modulation code and the intervals of calling the sound and video writing functions, or some hacks in the sound code.
You're right. I looked at the AVI code for Gens and SNES9x and both use the same method, so the problem can't be in that area.
However, this time, I think I may actually have found the cause. The video frames are written to the AVI during FCEUI_Emulate(). Specifically, via an FCEU_PutImage() call in FCEUPPU_Loop(). Sound, on the other hand, is written later in FCEUD_Update(), after going through a bunch of crap that I couldn't even keep track of.
I think the proper solution would be to call FCEUI_AVISoundUpdate() at the end of FlushEmulateSound(), instead of in FCEUD_WriteSoundData(). That would cause the sound to be updated immediately after the video. Do you concur?
Phil wrote:
And for upside down screen problem when using AVIzlib and some other codec?
I just tried this out and it does seem rather odd. For me, it only appears upside down in WMP. In VDub it's fine. Further, if I recompress the same file again(using the same codec), it plays properly in WMP. This could also be caused by the RGBA formatting(AVIzlib doesn't have a 32-bit mode), but I can't confirm it.
I think the proper solution would be to call FCEUI_AVISoundUpdate() at the end of FlushEmulateSound(), instead of in FCEUD_WriteSoundData(). That would cause the sound to be updated immediately after the video. Do you concur?
Well, the problem is not only in the AVI; The sound you hear from the emulator also gets totally screwed up, either when making an AVI or when using a speed that's not 100%, so I think it can't be only the location of AVISoundUpdate(). But, it's possible that I'm talking about a completely unrelated problem.
(edit: hmm, I think that mess of a function called FCEUD_Update() is the main culprit, although FCEUD_WriteSoundData() seems to be a bit buggy too.)
(edit2: Moved FCEUI_AVISoundUpdate() into FCEU_WriteWaveData(), it stopped the sound from becoming garbled, but it still drifts a little. I'm guessing there's some accumulating rounding error that has to be corrected.)
Andy Olivera wrote:
This could also be caused by the RGBA formatting(AVIzlib doesn't have a 32-bit mode), but I can't confirm it.
I think you're right that this is the problem, it is probably a bug in those codecs (or the support of them) that makes it upside-down with 32-bit output. This shouldn't be too hard to fix by changing the AVI output to be 24-bit. (edit: Done.)
FCEU sometimes change a valid savestate to another savestate that reset the game. This bug rarely happens, but when it happens ... :@
Does this bug still happen? I have never seen it but it might be fixed.
Yes, it happens yesterday when testing some things and I don't know what's causing this. Thinking of that, I have kept savestates and movie file when it already happens when doing Battletoads in case you want them.
The random desync still exists in smb3.
Random desync at frame 145422 (at the end of stage 6-1, on the last plant)
http://genisto.servehttp.com/timeattacks/smb3_amazing_run_world6.zip
I included a save state (beginning of world 6) in the zip.
- - - - - - - - - -
I have a suggestion to include in Fceu:
Allow the user to put save states anywhere in the movie = It will allow people to show bugs or any suggestion to others and it can be an alternative way to prevent random desynchro. (When replaying the movie, it load every save at their frame)
I have a suggestion to include in Fceu:
Allow the user to put save states anywhere in the movie = It will allow people to show bugs or any suggestion to others and it can be an alternative way to prevent random desynchro. (When replaying the movie, it load every save at their frame)
This thing looks like chapters like in Zsnes though it won't prevent desync..
Hmm, I can't download this, I guess I'll try later... Is this something where it sometimes desyncs when it gets around frame 145422, or does it always desync when it gets there? If it always desyncs there, then it's not the random desync bug, it's something else. That save state might help catch what happened, though (the earlier it is in the movie, the better).
That's part of the new mapper code from fceu-mm, I guess they put in something that has trouble compiling. You should be able to fix it by commenting out the extern of CHRRAM on line 3 of mmc.h. I don't know why they were externing a static variable, but probably the only reason it compiled for me was because nothing uses that variable.
I created the save state 9 after I completed the stage 6-1 and the save state 0 before the completion.
The desynchro happen more frequently with the save state 9.
OK, I took a look at this and here is what I can tell so far:
- Save state 9 always leads to a desync there (at the plant)
- Save state 0 never has a desync there
- Playing back the current movie from the beginning, it always reaches the state of state 9 and desyncs. (Thus, it is not the random desync problem where it sometimes desyncs on playback but not always.)
- Save state 0 is inconsistent with the contents of the movie. There is no way for the input and initial state to lead to state 0... unless the game's memory is tampered with in-between, which is what seems to have happened for you, possibly (and this is a wild guess) from a bug with save states.
- A hex diff between state 0 (+ some playback frames so the frame counts match) and state 9 reveals that about 6 variables are different between the states, including a variable which I made sure always starts at exactly the same value. The result is that the game glitches out for 1 frame or so before the last plant in one of the states (9), but not the other.
So, I have some questions:
- Could you explain more about how you made (and got to) state 0? Specifically, did you load a previous save state and record from that when you were recording the level that now desyncs, or did you watch the movie from the start and resume recording to record that level? If it was from an existing save state, apparently something was wrong with that save state you recorded from, so more information about that could help. Was it made in a different version of FCEU or something? Did you at any point continue from a save state you made with another version (or record any part of the movie with another version) after switching to the newer version of FCEU?
- What changed between when you saved state 0 and when you completed 6-1? Did you run your movie through any external tools? I'm wondering if maybe something corrupted the initial state stored in this movie. (Actually, I doubt that is the problem because I couldn't find any differences in that between this version and your earlier WIP, but maybe it went through a transitional phase.)
BTW: This movie is looking amazing so far, especially all the tricks you do with shells.
I formated a few days ago = all my save states are new and I have only the last version of Fceu.
I will say you what I remember about my working in this level:
I have done 2 attempts on this plant
1st: I jumped over it by firing to him, but I missed the target, but I have already saved that work when I realizet that.
2nd: I loaded from a preview save near the plant or do replay from save state 0 to redo this part. (I don't remember)
I never loaded before the save state 0.
