I was expecting this run for some time by mushadv. However, happylee just did it. Before watching this run, I did watch the SMB FDS run and notice all those annoying backward and unnecessary jumps all the way to Bowser. I was hoping it wasn't the case for this run. But NO, HE JUST JUMPS BACKWARD ALL THE LEVELS. Also, wtf with those random wobblings in water stages...
There is no style in this movie. No playing with music, didn't show many bugs that didn't slow down the run etc... etc...
I am 100% disappointed. That run is inferior, for entertainment value, to preceding SMB1 warpless movies. Yes, movie in plural that includes old speedruns on console.
So, let's go mushadv, you can do better.
The thing is that record from reset is NOT related to record from power but is much closer to record from a savestate. So, if someone wants to do that, he just needs to start recording from a save.
Except to cheat some people, I don't see how it is useful.
I can't think of any games that this feature is useful, except those that will help someone to fool some people.
That's why I think the unuseful and confusing Record from reset is no more needed and must be removed. And movies done with Record from reset are generally not accepted at this site.
I have 2 problems with that.
1. The numbers for frame display are shaking like hell.
2. Small font + white in games that does use white alot == bad.
Edit: I've never received email for people posting in that topic :S. Today, I just saw many posts in this thread. Anyway, edited the 1st post, if there are some bugs that are fixed and still in the list, just tell me.
I am kinda busy these days to test things.
Warp: No, they aren't. In 2004, before P.JBoy had joined, there weren't AVI recording in Famtasia. So, uses of screen capture was needed. Then later, blip added it but it wasn't used so much as he addded rerecording in FCEU not so much time after.
3D games? Only 3D game what I have on my co,puter are doom 1&2, oh wait, its mare 2.5D.. Nevermind, I have DOom 3 demo on my computer, and it lags like hell somtimes, but still now crash my computer :\
Don't search furthermore, I am 90% sure it's one memory stick that is disfunctional. With my own personal experience at computer repairing, when a computer is unstable, especially during 3d calcultions, it's not the video card nor the processor the problem or any other software, it is a memory stick. You probably bought some generic one and they do suck. It really worths buying a little more expensive one. I am using Corsair and I'm satisfied but there are Samsung known to be good, Kingston, OCZ etc... too.
But it could be some other hardware too.
And you think you're better? You think you're insulting me for good reasons? You think TSA deserves to be insulted such like that when he is gone for 1 year or so?
If you answer yes to one of those questions then you're acting like if you were superior.*
It's funny** that some guys, including you, are calling Phil, Saturn, TSA, PSXauthor, Warp and many others guys, they are acting like they are "superior or some sort of god" when themselves, they are acting like that.
Just the way you're making someone looking he is inferior by saying he is not superior and using other insults also makes you acting like you are superior.
*I'm using the same argument as you.
**Not really.
I don't know who is your TSA but the TSA I know did help me making both Zelda runs I've made.
In fact, he even posted several videos of bugs, which he has discovered, in the Zelda thread. And he even discovers the "enter through object" bug before Baxter. Though we didn't believe it and told him it might be caused by some dust in his cartridge.
So, stop that.
And he isn't even there to defend himself. Imo, you are lame.
Common, do you share all your secrets? I doubt so. Also, there are even better emulators for Playstation.
Like I said EPSXE team has revived. And who cares about the plugin system if there is rerecording and people could do movies. It's not because Mupen sucks that epsxe is too. PLus plugins for PS were superior, and probably still today, than those on N64. Especially those made by some Pete. Today, I think they are Peops or something.
Off-topic: And I don't feel some people "babycrying" attitude superior than Saturn.
Maybe...
It's not because he didn't answer or refuse to add requested features that gives you the right to attack him in his back.
Even Bisqwit, in his 3rd email, was really offensive.
Unlike you, he created a PSX emulator. Not just basic tools or small fixes in other softwares. It's freeware. Lucky for us that we mustn't pay for it like Bleem! for example. It's his rights to share his source or not. And also his rights to implement a feature or not.
If you feel that he owes you something and feel deceived because he didn't do something that you have hoped he'll do even though he didn't promise you a single thing, then there's something wrong with you.
Also, there are many guys that don't like the idea of TASes. For ex., many of the dev in MAME project dislike the idea. And even Xodnizel, the author of FCEU didn't like the idea that we use it as a TAS tool. It's probably one of the reasons he abandonned that project.
You don't like my opinion. That's good. But it's not a reason to be so aggressive.
mmbossman wrote:
And unlike one of the two movies above, I didn't submit this, then accept and publish it within 1.5 minutes for my personal gain.
I already made excuses for that (Even though I feel I shouldn't).
But anyway, when I've published that movie, Bisqwit was in vacancy and he has just finished writing it's wiki before. There was no voting system and I was the 1st judge/publisher/editor. So, alone to manage the site.
Yes, there was no one else.
So, I felt there was nothing wrong to publish the movie. Also, as taking my free time to manage his site, I fell it was my reward for that.
So, I don't owe you or anyone else a single thing for that incident.
And you weren't even there in 2004. So, you don't know what you are talking about.
How can it your computer?
Seriously, I doubt it's FCEU's fault. It might be some hardware or software problem. Did you try some 3d games and they happen to crash? 3d games, modern preferred, are really good to test if a computer is stable or not. Is there any other software that occasionally crash?
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.
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 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. ;)
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.
*"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.
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.
your computer?
Seriously, I doubt it's FCEU's fault. It might be some hardware or software problem. Did you try some 3d games and they happen to crash? 3d games, modern preferred, are really good to test if a computer is stable or not. Is there any other software that occasionally crash?