Joined: 8/15/2005
Posts: 1941
Location: Mullsjö, Sweden
May have been suggested already...
But I would like to see how many frames that are left of the movie you are watching. It really sucks ass that you can't with the current version in my opinion :/.
Then if you did notice it blends into the start of the movie, then you knew the movie has started...
Duh.
I'm saying that with such a logo it becomes difficult to pinpoint the exact moment of movie start without a corresponding subtitle.
You said you didn't understand how such a subtitle can be useful. I'm merely presenting you an example. As such, I see no reason to discontinue using this subtitle since it doesn't bring any inconvenience to the viewers, yet can still be useful.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
FCEU v0.98.24
http://popibot.googlepages.com/fceu-0.98.24.ziphttp://popibot.googlepages.com/fceu-0.98.24-src.zip
*New option to record "movie end" message in AVI.
*FCEU doesn't ignore the last input delivered when you switch to "Read+Write Mode" anymore.
*New option to pause emulation automatically after movie playback stops, so you don't have to keep reloading the movie every time you test something in real time, for example.
*Now it shows "current frame / total frames" when you're playing a movie.
This version has a lot of new hacks I had to use thanks to FCM format's limitations, so it's very probable it has some new bugs. Nothing major, I hope.
By the way, I think these two bugs in the first post are the same:
Fixing unresolved bugs, like the one where changing to read-only can result in the movie suddenly ending early unless you fast-forwarded for a while and stopped the movie once first.
Additionly, its Read-Only Toggle always ignores the last input delivered when you switch to Read+Write Mode, which is quite annoying when recording a movie.
Hopefully, that bug should be fixed in this version. It was the most annoying one, in my opinion.
I don't like to repeat myself, but: I won't be working on this anymore if there are no bugs introduced by me or someone else finds another major bug easy to fix; at least until I finish my current TAS. :P
@Dromiceius:
Sorry, I can't reproduce your bug. Maybe something with your card/drivers? Does anyone else have this problem?
And yeah, I wouldn't even know where to start with Lua support. I just started learning C a few days ago, so...
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.
By the way, I think these two bugs in the first post are the same:
Fixing unresolved bugs, like the one where changing to read-only can result in the movie suddenly ending early unless you fast-forwarded for a while and stopped the movie once first.
Additionly, its Read-Only Toggle always ignores the last input delivered when you switch to Read+Write Mode, which is quite annoying when recording a movie.
Hopefully, that bug should be fixed in this version. It was the most annoying one, in my opinion.
I don't know.
For me, "like the one where changing to read-only can result in the movie suddenly ending early unless you fast-forwarded for a while and stopped the movie once first." looks like, when you're playing a movie then you switch to read only , it causes the bug unless you fast forward or something. Well, it's not really clear. I don't remember who reported this bug but he should clarify. :P
I never use the "switch to read only mode" while playing or recording a movie. I always use the "replay movie" then check/unckeck the read only box as it is always safe imo.
Edit : ok, just found a way to replicate the bug
As for "Additionly, its Read-Only Toggle always ignores the last input delivered when you switch to Read+Write Mode, which is quite annoying when recording a movie.",
I think that one is clear.
Edit: I feel those bugs aren't the same.
I never use the "switch to read only mode" while playing or recording a movie. I always use the "replay movie" then check/unckeck the read only box as it is always safe imo.
Well, it should be just as safe now to use "Read-Only Mode" toggle. (I still think they're the same bug :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.
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
As a long time NES TASer, I'm very pleased to see some work being done on this. :) I haven't had time to test this new version of FCEU, but I downloaded it and gave it a try yesterday, and I'm very pleased with it.
The fact that it display how many frames the movie file is when you play, the "Pause after playback" feature, doesn't screw up input when switching between play-only and record... All these new things work great! :)
The only small bug (note: extremely small) I have found so far is that if you try to load a savestate that is not from the movie file you're playing, the message "Error(s) reading state x!" appears, as it should. If you then quickly (sometimes you need to wait ~1 second) load a savestate from the movie you're currently playing, the message "State y loaded (Wrong movie file!)" sometimes appears, even though the savestate is from the correct movie file. This bug doesn't seem to do anything to the emulator (it still loads the savestate correctly), but I thought I should report it. Perhaps there is an even more evil bug behind it... ;) Oh, and it does not seem to apparent in 0.98.16.
Thanks for all your work on this, mz! :D
Great job mz! Now I can toggle Read-Only as I wish! Thanks a lot.
Still, some savestates not from the movie can be loaded and interrupt the movie playback.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
*"Wrong movie!" message should be much more reliable now.
I don't know what you've done but I still get the same problem as I mentioned above. And even Randil still got the same problem. Put it in 1st post.
Randil wrote:
The only small bug (note: extremely small) I have found so far is that if you try to load a savestate that is not from the movie file you're playing, the message "Error(s) reading state x!" appears, as it should. If you then quickly (sometimes you need to wait ~1 second) load a savestate from the movie you're currently playing, the message "State y loaded (Wrong movie file!)" sometimes appears, even though the savestate is from the correct movie file. This bug doesn't seem to do anything to the emulator (it still loads the savestate correctly), but I thought I should report it. Perhaps there is an even more evil bug behind it... ;) Oh, and it does not seem to apparent in 0.98.16.
As you can see, it's same bug.
mz wrote:
-Memory Watch updates itself after loading a memory address list, even if emulation is paused.
Yes, it's indeed fixed. However, while testing it, I've found a very minor bug, I don't know if it's new to this version but I think it was there since .16.
*In Memory Watcher, when you use the "clear" button while the emulation is paused, it indeed clears Address(es) and Name(s) but the value(s) still remains.
mz wrote:
-Fixed bug introduced in v0.98.22, where "Author Info" wouldn't show more than one line in "Replay input" dialog.
Yes, it seems you fixed something.
I never wrote long text for author info until today, to test what you were talking about.
1st of all, how can you make more than one line? Is there a special way to break a line? Pressing enter makes it press the ok button which starts recording.
2nd, if I press and hold any character key, it doesn't break any line when it reaches the right side , instead, it continues putting infinitely new character to the right which creates a very long line.
And because of that, in the Replay movie, you can miss parts of the text.
So, imo, you might have fixed a bug that you have created but it stills doesn't show all the text as you can't even create more than one line. So, that bug is not really fixed. Note that I've tested .16 version and that bug is there too. It's probably there since author info feature was added in FCEU.
mz wrote:
*New option to record "movie end" message in AVI.
Nice.
mz wrote:
*New option to pause emulation automatically after movie playback stops, so you don't have to keep reloading the movie every time you test something in real time, for example.
Nice.
mz wrote:
*Now it shows "current frame / total frames" when you're playing a movie.
Indeed.
mz wrote:
This version has a lot of new hacks I had to use thanks to FCM format's limitations, so it's very probable it has some new bugs. Nothing major, I hope.
I've managed to playback my current project without any problems. So no problem so far.
klmz wrote:
Great job mz! Now I can toggle Read-Only as I wish! Thanks a lot.
So, does "FCEU doesn't ignore the last input delivered when you switch to "Read+Write Mode" anymore." fix your problem? I saw that you edited your page today but you didn't remove your problem.
klmz wrote:
Still, some savestates not from the movie can be loaded and interrupt the movie playback.
Can you explain furthermore?
As for Dromiceius bug, I try it. I don't have any problems with double buffering. However, when I select a custom video, like 1024x768 4x,3y. And switch to fullscreen mode, FCEU is crashing if a game is loaded or the "DirectDraw: Error creating secondary surface" error message if no game loaded.
Edited 1st post.
And sorry for adding extra bugs in the list. While testing your fixes, people, including me, had found extra bugs. Fortunately, they are usually minor bugs.
*"Wrong movie!" message should be much more reliable now.
I don't know what you've done but I still get the same problem as I mentioned above. And even Randil still got the same problem. Put it in 1st post.
Randil wrote:
The only small bug (note: extremely small) I have found so far is that if you try to load a savestate that is not from the movie file you're playing, the message "Error(s) reading state x!" appears, as it should. If you then quickly (sometimes you need to wait ~1 second) load a savestate from the movie you're currently playing, the message "State y loaded (Wrong movie file!)" sometimes appears, even though the savestate is from the correct movie file. This bug doesn't seem to do anything to the emulator (it still loads the savestate correctly), but I thought I should report it. Perhaps there is an even more evil bug behind it... ;) Oh, and it does not seem to apparent in 0.98.16.
As you can see, it's same bug.
I didn't know this bug was the same one as yours. I see I shouldn't have bothered making it more reliable.
Randil's problem is not a bug, it's the expected behaviour. This function compares input between the last loaded movie in memory and the new loaded movie from the savestate. If you load a state from another movie, FCEU will also load the movie within it; so if you then load a savestate from the movie you were really working before, it will give you a new warning.
From what I understand, klmz wants to prevent FCEU from loading states from other movies; but I as said before, this method is not 100% reliable due to FCM file format limitations.
I may release a new version with this function disabled, as it looks like people is only getting confused by it.
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.
No, I gave you a solution.
Maybe I wasn't clear.
I wrote:
"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."
I didn't check your code since I am not an expert at C programming for the moment but if I understand the mechanism correctly of that feature so how it is:
You load the state, it takes some random frames from movie within the savestate then compare them with the movie that is currently playing.
Usually, movie, that is currently playing does have more frames than the one stored in the savestate.
So, your code works fine when "Current playing movie frames" > "Movie stored in savestate". All 100% work under that condition.
However, sometimes, "Current playing movie frames" < "Movie stored in savestate".
With that condition, your code fail. Because a savestate during the process of movie making are sometimes called "Wrong" by FCEU when they are "Right".
So, in short, what I think is your code is that you take some random frames in savestate's movie and compare them with those in playing movie. Keep it.(or change it a little to fix that bug ;) ).
As an extra, add an extra condition when "Current playing movie frames" < "Movie stored in savestate".
For that one, take random frames in playing movie and compare them with frames in savestate's movie.
Ex. 1: Movie frames== 1000
Savestate's movie frames== 900
== Your code is working nice under that condition
Ex. 2: Movie frames == 500
Savestate's movie frames == 900
== Your code fail.
It's almost the same, just the variables that are reversed.
I hope you understand me.
Yeah, I understand you; and I understood you the first time too.
I did that change; even if it's not so simple as you may think.
What it seems to me, is that FCEU sometimes loads or saves or something savestates with some added frames at the beggining (ending?) of the movie file. This behaviour seems to be random, and I don't know what causes it. So I had to program my function to ignore the first (or last, I don't remember) 3 bytes in the new loaded movie from the savestate when comparing.
I tested a lot of cases with different games, movies and what not. They all seemed to work fine with this change. Maybe your example is an exception, and perhaps it has more extra empty/random frames or something.
So, if you want to, you can upload that movie file and savestate somewhere, and I will check it. But I will probably end up removing this function 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.
(I was editing my precedent post but got a visitor and notice that you post before I've finished my edit. So, created a new post.)
mz wrote:
Randil's problem is not a bug, it's the expected behaviour. This function compares input between the last loaded movie in memory and the new loaded movie from the savestate. If you load a state from another movie, FCEU will also load the movie within it; so if you then load a savestate from the movie you were really working before, it will give you a new warning.
Oh, I guess it was too early when I wrote that. No it's not the same. Well, you are right that's not even a bug. :P Since the movie has changed completely, it's normal that it wrote that message. Damn you Randil. :P I will remove it from the 1st post.
No, I suggest you to keep that feature. Just fix the bug I mention and maybe an option to activate/desactivate that feature since it's confusing some people.
But I found it useful as it fixes some annoying bugs. Maybe it's just the "Wrong" message that confuses people.
mz wrote:
What it seems to me, is that FCEU sometimes loads or saves or something savestates with some added frames at the beggining (ending?) of the movie file. This behaviour seems to be random, and I don't know what causes it. So I had to program my function to ignore the first (or last, I don't remember) 3 bytes in the new loaded movie from the savestate when comparing.
Ok, I think I understand your problem. I think it is caused by those dummy frames that aren't erased in FCM. They are at end of the movie.
As an example, a FCM can have like 1000 frames in it but the movie end at frame 900, I think it's address "00C 4-byte little-endian unsigned int" that determines when a movie must stop. So in that case, there are like 100 extra frames.
I know Bisqwit added in his Nesmock tool, an "auto-remove those frames" feature.
So, you may find a solution in Nesmock source or instead, use address 00C for your code.
While talking about that. Why not making FCEU auto-remove those extra frames. Because of that, movie takes a little more space than needed and makes confusion when someone implementing a new feature, like you. ;)
@mz:
Yes, I was talking about "preventing FCEU from loading states from other movies". If that is too hard to do without modifying the current FCM format, then it's OK. However, is it possible to prevent loading "states from other movies" from interrupting the movie being played?
Hmm...I think I've found a big bug which doesn't exist in FCEU 0.98.16. Just open Duck Tales 2 (U) [!].nes with the latest FCEU 0.98.24 and see graphical errors, then try to play the published movie on it to see twisted alternative world.
EDIT: Duck Tales 2 (J).nes and other games which work fine with FCEU 0.98.16 still work fine with FCEU 0.98.24.
EDIT2: I don't think that you have modified any mapper codes. So maybe this bug is related to the FCEU 0.98.16 compatibility issue or even has some deeper causes hidden in those oldest codes.
EDIT3: I don't think it was a bug now. See my post below.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
Hmm...I think I've found a big bug which doesn't exist in FCEU 0.98.16. Just open Duck Tales 2 (U) [!].nes with the latest FCEU 0.98.24 and see graphical errors, then try to play the published movie on it to see the twisted alternative world.
I never watched that movie. It was a good opportunity to watch it while studying the bug.
I don't have any problems with that game + FCEU 0.98.24.
The movie has played from start to end without any troubles. Maybe something else affected it. Can you upload your fceu98.cfg file somewhere? It might be one setting that affects the game. That's the only thing that comes in my mind now.
I think I've got the cause - there's a Duck Tales 2 (U) [!].cht in the cheats directory which will be automaticly loaded if I open Duck Tales 2 (U) [!].nes and it will set memory address 0x0000 to 0 to prevent the game from working normally.... What a stupid problem!
Now I am sure this is not a bug. But something like an option to disable all cheats from the menu and/or at least a piece of message to tell you if cheats have been loaded will be appreciated. Currently even the "Message Log" doesn't tell me that.
EDIT: I don't think my fceu98.cfg will be useful now. But if anyone wants it, I'll upload it somewhere. ;)
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
Yes, I was talking about "preventing FCEU from loading states from other movies". If that is too hard to do without modifying the current FCM format, then it's OK. However, is it possible to prevent loading "states from other movies" from interrupting the movie being played?
It's not hard to do at all, but the current method for detecting "other movies" is not very good; so, you may end up trying to load a valid state and you won't be able to do it, if FCEU has detected a false positive.
klmz wrote:
a message to tell you if cheats have been loaded will be appreciated.
Sounds reasonable to me. I may add something like that if/when I work again on all this.
By the way, yesterday I watched with v0.98.24 both Duck Tales movies too. :P Very entertaining movies.
@Phil:
Thanks for the information, I'll take a look into it next time I have some time and motivation.
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.
Yes, I was talking about "preventing FCEU from loading states from other movies".
No, no, this feature should remain. Loading savestates from other movie sometimes is very helpful. For example, this way you can compare checkpoints while improving old run.
Sure, loading improper savestates creates some possiblity to screw your own movie, but still for me it's more comfortable than running two FCEU windows with different movies/savestates.
EDIT: I don't think my fceu98.cfg will be useful now.
Maybe...
... But as I said, it was one of your setting.
Btw, you didn't answer my question. Does your Read only toggle problem been fixed since you didn't remove it from your homepage when you edited it yesterday?
One of the things that annoy me in Snes9x is that we can't load states from other movies.
A message that tells you one is not from the same movie is even better, imo.
The read-Only Toggle problem has been semi-fixed. After you toggle on Read-Only, the movie file is written correctly to the HDD, but the movie in the RAM is not correct - when you play it without reopening the movie file, the movie will never end. I guess this is caused by incorrect movie length stored in the RAM.
I think it over and I agree on that loading states from other movies can be useful. Additonally, I guess removing extra bytes in movies will make it impossible to repair movies truncated by mistakes with early backups.
@mz:
I think even with High setting, the update speed of Memory Watch is too slow. It should be at least 60Hz. Maybe you could add Realtime setting the fastest as well.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
The read-Only Toggle problem has been semi-fixed. After you toggle on Read-Only, the movie file is written correctly to the HDD, but the movie in the RAM is not correct - when you play it without reopening the movie file, the movie will never end. I guess this is caused by incorrect movie length stored in the RAM.
Ugh... I hate that bug. I thought I had fixed it. As far as I know, it happened in previous (0.98.16 for ex.) versions too. Can you give me a way to replicate it? Or maybe upload a savestate and movie file where this is happening. (forget this last sentence, I forgot it only happens when you don't reload the movie)
klmz wrote:
Additonally, I guess removing extra bytes in movies will make it impossible to repair movies truncated by mistakes with early backups.
My guess is that there isn't anything useful in those extra bytes. I think they are added because when you're recording, FCEU always adds 4 extra bytes to the movie in memory to work on.
klmz wrote:
I think even with High setting, the update speed of Memory Watch is too slow. It should be at least 60Hz. Maybe you could add Realtime setting the fastest as well.
Sure. I never used it after the last change, but I guess you're right. There's not much difference between speeds right 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.
Ugh... I hate that bug. I thought I had fixed it. As far as I know, it happened in previous (0.98.16 for ex.) versions too. Can you give me a way to replicate it?
I found the only(?) way to replicate it:
1) Start recording a new movie from Start or anywhere you like.
2) Save a state from the movie being recorded.
3) Toggle on Read-Only.
4) Load the very savestate from the movie.
5) Wait until "Playing frame x / y" where x > y to see the problem.
If you start rerecording a movie instead and then follow 2), 3), 4), you won't replicate the problem.
I also found a new crash bug which isn't in FCEU 0.98.16:
1) Start recording a movie from Now(snapshot).
2) Stop recording after a few frames.
3) Play the movie in Read-Only Mode.
4) Load any savestates either from or not from the movie during the playback and get FCEU 0.98.24 crashed immediately.
Although this site doesn't like movies recorded from embedded savestates, having one build-in feature crashing the emulator is not good.
mz wrote:
My guess is that there isn't anything useful in those extra bytes. I think they are added because when you're recording, FCEU always adds 4 extra bytes to the movie in memory to work on.
I mean, sometimes you may truncate your 15-min movie into a 5-sec movie by mistakenly loading an early savestate from the movie. However, according to Bisqwit's article(link required), input bytes after the new end point(in this case, 5 second after the beginning) will remain in the movie. Those bytes become extra from the view of the new movie. Bisqwit made an FCM Repair/Fix(link required) using those extra bytes to recover your 15-min work. If future FCEUs remove all extra bytes from the movie, it'll be impossible to recover your work.
To be honest, I've never repaired a movie using it. I usually take it as an opportunity to optimize my movie. But not everyone likes to be forced to optimize thier brandnew movie.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
1) Start recording a new movie from Start or anywhere you like.
2) Save a state from the movie being recorded.
3) Toggle on Read-Only.
4) Load the very savestate from the movie.
5) Wait until "Playing frame x / y" where x > y to see the problem.
If you start rerecording a movie instead and then follow 2), 3), 4), you won't replicate the problem.
Thank you. Hopefully I can track down all the possible cases now.
klmz wrote:
I also found a new crash bug which isn't in FCEU 0.98.16
I'll test this later. Thanks for the report.
klmz wrote:
I mean, sometimes you may truncate your 15-min movie into a 5-sec movie by mistakenly loading an early savestate from the movie. However, according to Bisqwit's article(link required), input bytes after the new end point(in this case, 5 second after the beginning) will remain in the movie. Those bytes become extra from the view of the new movie. Bisqwit made an FCM Repair/Fix(link required) using those extra bytes to recover your 15-min work. If future FCEUs remove all extra bytes from the movie, it'll be impossible to recover your work.
If I recall correctly, Bisqwit's tool was only useful for movies broken by the bug I fixed in v0.98.18 (load a state made outside movie playing/recording while playing a movie in read-only mode), so it has no use now. When you load an early savestate from the movie you erase everything after that point (not very sure about this), and in most cases you have a savestate at the point where you were before; so it's not really an issue.
Either way, I don't plan to remove extra bytes in movie files; only to ignore them when checking for wrong movies.
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.
