Encoders don't add anything else than the logo. And end of logo indicates the "movie start" by itself. Also, the "this movie is tool-assisted blah blah" subtitle also indicates the "movie start".
Edited 1st post. Added some people request and removed bugs that are now fixed.
adelikat wrote:
*Add an option to record "movie start" and "movie end" messages in AVI.
I put that one a while ago in the 1st post. However, I don't understand how "movie start" could be useful. Damn, movie start when it starts. And AVI starts when the movie starts. Movie starts at frame 1.
Only "movie end" is useful.
I am not sure. I can't edit my personal page, there's a fucking player at right-top that plays a stupid thing and submissions page don't show all submissions. I must click on a 2nd page link to see the remaining ones. And I guess there are extra things.
But I hope it's an april fool day joke and the original layout will come back...
Savestates didn't have author info, they only had recorded input and other related data; so I had to go with your second idea. It only compares 20 frames, but 5 should have been ok too, thanks to the strange way FCM files save recorded input.
Ok that's cool. It works fine if the number frames of the movie stored in the state is shorter than the playing movie .
However if the movie is shorter than the movie stored in the state even if the state come from the same movie(you are working on for ex.), I got the "Wrong movie" error.
So the solution would be:
Playing/recording movie longer than movie stored in the state. Use the existing method.
If playing movie shorter than movie stored in state do the opposite. So instead of taking random frames in stored movie, it takes random frames in playing movie and compare with stored movie.
mz wrote:
I finally didn't block anything (only a warning), as I still don't know how reliable this detection method really is; and also sometimes is useful to load states from other movies.
So far it's really reliable maybe too much ;) as the small probem I just mentioned above proves that.
Maximus wrote:
I did some more work last night and have got the latest boards and mappers in (from the fceumm subversion repository, so they're even newer than the 2006 release stuff), but once again, I'm having problems with them actually working.
I don't recommend the new ones in subversion. The recent releases of fceumm were beta and there might be problems. I recommend to ask CaH4e3 before using anything in svn repositroy. You should be safe with the 2006 release.
"Latest WIP build (uploaded: 17.02.2008) available here (Note: this strongly BUGGY version, this just for testing new mappers and stuff.)"
mmbossman wrote:
A suggestion: if it's possible, could the memory watch screen be customizable to the amount of addresses currently being watched? Or, if that's not possible, could the default mem watch screen be increased in size to handle some more addresses than 24? It'd be great to have it show up as a small box when only 4 addresses are loaded a big box when 30 addresses are loaded, but if that's not possible, having some screen real estate being eaten up by a larger mem watch screen would be a help.
Omg, I already put a similar request in 1st post but I guess I accidentally erase it.
Edited the 1st post. Removed some bugs readded what mmbossman said.
As for FCEUXD, I already asked nitsuja and he said that there are too much windowsisms and such. And we don't want that.
Edit: Ok, I've just reorganized the 1st post so that it starts, imo, for higher to lower priority things that need to be fixed.
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. ;)
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à.
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.
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.
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?
Yes, if the name changes something for the game like in Dragon Warrior and Monopoly and many many other games.
Yes if the author also improves other part(s) of the movie. :P
No, if it's just for the sake of saving 1-2 frames.
Last time I have tested that feature, it was working. I think it was FCEU 0.98.15 or maybe .13. I don't know for Luke's version. But yes it should work on one of these versions.
Otherwise, if there is a good FCM editor that supports that, you can manually add it at desired frame.
More details on FCM format: http://tasvideos.org/FCM.html
Oh and don't forget to eject the disk 1st then change disk side and insert disk. It might be your problem as it is a common problem to many people.
21 frames faster than the published movie due to the legendary flagpole-stuck glitch.
Can you be more precise as to where is the improvement? And why it has been improved?
Edit: Ok, I thought it was improved by 21 frames due to some minor error but 've just watched it after noticing that andrewg pointed out about a glitch in the SMB1 thread.
i said it a year ago i will say it again
bob charlie can be beaten in the 4:xx seconds bracket
i have done it on console
he has random factors can someone please spend hours on this i promise you it is possible
i said it a year ago but no one has done this yet
slackers!
I answer your question in the submission text. Also don't take it personal, if it looks like I am pointing you. You are not the first one nor the last to claim false records.
I thought the meaning of this topic was to replace all fmv by FCM. All FDS, including SMB2j suffers from that which I still have done. But it's not a good reason to remove eggerland and the other one from the list. Otherwise, that topic is almost 100% pointless.
Famtasia is indeed way too quick for FDS loading disk emulation. And FCEU is a little, not so much, too slow if IIRC from what _Q said some years ago. So FCEU is closer to emulation.
Nice. You prove me that I was right to think it was improvable. I started studying that game but abandonned for the sake of, imo, better projects.
Xipo wrote:
I image whether this run can be reduced some virtual time when speed up if you press some "start" to pause the game?
Well, if the value at 004c continues to change while paused, I think it may indeed help.
Edit: No, it doesn't work.
I don't understand why this SMS game obsoletes a NES game. Plus the NES run was faster.
I don't see anything in this discussion that suggests to do so.
That run should be published but as separate movie.
Since using PRG0 and PRG1 doesn't matter for the warp run since the run is working on both version, it's not the case for this run. Do you have a better reason than text in ending? We can already see the text in ending scene with the warp version. No need to use that ROM twice. Also "This run will desync on World 1's airship when using ROM version PRG1." How much else is also different.
It's in violation of the rules as the precedent version was done wih PRG1.
Me wonder if the run is not faster by using that version...
Edit: It seems not as there are extra lag with PRG0 as Deign told me.
The thing about, iirc, is that PRG1 versions does usually have some fix(es).
I wonder what are the fix(es) other than some texts.
Phil, I don't understand why you are against ROM changes from one run to the next, but are all for emulator changes from one run to the next, when the two ideas have potentially the same effects on the resulting TAS.
That's a good question that I was expecting. You are right about the effects. However, using a recent emulator which usually improves emulation accuracy to look closer to what can be done on the console is a wiser choice.
Switching ROM only affects the gameplay, the differences may lead that one might be faster by a few frames. Fortunately, it's not the case here as I would be against the publication.
I have a question, what's so interesting in ending scene text for PRG0?
Edit: It seems you have edited you post the time I was writing this post while talking with someone.
JXQ wrote:
I was also just reminded that Genisto changed the ROM when he did the previous version, from (J) to (U). How is our choice different?
I already answer this question in the Bionic Commando submission. Anyway, there was a consensus by many guys to switch version before Genisto has submitted his run. However, I never really agreed with that choice. If you want to switch version ask before even working on it. It's 2nd time you are doing that. Don't be surprised if I disagree with that. My opinion is clear on this. If we start switching version just because of some small details such as text, then where are we going?
Also, about emulators, I agree with upgrading an emulator but not downgrading. Ex. Someone would beat that SMB3 with FCEU 0.98.12 or using a completely different inferior emulator such as Famtasia when it is proved to have differences, I would disagree for its publication.