Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
Cool, thanks for that info, Maximus. :D
I compiled a test version with that change here:
http://popibot.googlepages.com/fceu-cheat-search-test.zip
Someone better than me should try and see if it still can find any address now. I couldn't find any, but I normally suck at this.
EDIT: Actually, I'm stupid. It does work fine. :D
Well, there's that build with that change if anyone needs it now and can't wait for the next version. Thanks again, Maximus.
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
FCEU v0.98.25
http://popibot.googlepages.com/fceu-0.98.25.ziphttp://popibot.googlepages.com/fceu-0.98.25-src.zip
*As requested, Memory Tools->Update Speed->High works at highest possible speed as in 0.98.16. Normal speed now works as High speed in 0.98.24. Low is still the same.
*Fixed bug introduced by me in 0.98.23, where loading a memory address list in Memory Watch, before loading a game, would crash FCEU.
*Clear button in Memory Watch now clears everything correctly, even if emulation is paused.
*Movies should not loop endlessly anymore when loading a state after using Read-Only Toggle to turn it on.
*FCEU doesn't crash anymore when you try to load a savestate from a very small movie. This was caused by some bug introduced by me.
*FCEU now sends a message when it loads a .cht file. This message can be found in the Message Log window.
*Wrong movie message should be more reliable now... Here's how it works:
-It compares 50 random bytes, ignoring the last 4 bytes from each movie.
-Only movies larger than 4 bytes are compared now.
If it's still not working correctly for someone, upload the savestate and the movie file and I'll take at look at it.
So, this version hopefully fixes everything reported by klmz.
By the way, adelikat found a "new" bug:
*Use external input is now greyed out under the tools menu.
(It's been like this since the first version I ever compiled. May be related to this. If you need to use BasicBot, stick with v0.98.16, as it doesn't work in newer versions. I'll investigate about this when I have more time, as it's a whole new subject for me.)
And I found another bug, which is also present in v0.98.16:
*Trying to record a movie from a savestate won't work, unless your Movies and Save States folder are the same.
(I'm going to fix this one for the next version.)
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
klmz wrote:
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
klmz wrote:
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
klmz wrote:
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
Phil wrote:
mz wrote:
*"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.
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
Those glitches were really insane. :D Amazing improvement for this great game. Big yes from me too.
By the way, you should say somewhere in the submission text that this movie colors a dinosaur... twice.
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
FCEU v0.98.23
http://popibot.com.ar/fceu-0.98.23.ziphttp://popibot.com.ar/fceu-0.98.23-src.zip
*FCEU no longer crashes after trying to open a ROM, getting an error message and then retrying to load any rom.
*Memory Watch and Memory Viewer are minimizable now.
*"Wrong movie!" message should be much more reliable now.
*Other minor stuff:
-Memory Watch updates itself after loading a memory address list, even if emulation is paused.
-Fixed bug introduced in v0.98.22, where "Author Info" wouldn't show more than one line in "Replay input" dialog.
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. Then I will probably work in mmbossman's suggestion if I still have some time. Hopefully this version is stable enough for people to start using it for their TASes.
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
Great movie! I hope you can make something like this for Kunio Kun no Nekketsu Soccer League, which is a lot better, in my opinion.
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
FCEU v0.98.22
http://popibot.com.ar/fceu-0.98.22.ziphttp://popibot.com.ar/fceu-0.98.22-src.zip
*Now it's possible to select/copy text in replay window.
*Memory viewer doesn't blink a lot, doesn't use 100% CPU power and its update speed is configurable.
*"High" update speed setting for Memory tools doesn't use 100% CPU power anymore. "Turbo is unstable" and related problems should be really gone now.
*New directory override for "FDS BIOS ROM Image" (disksys.rom), as requested by adelikat.
*FCEU now detects when a loaded state is not from the same movie. It will give a warning about this, but won't block anything.
*Movies don't play endlessly with always same input when loading states from other movies.
*When loading a movie with an FDS image, it will ignore the shadow disk image now. It will also ignore it when starting to record a new movie (fixes a non reported bug?).
*Minor cosmetic changes:
-"Replay input" dialog now shows "Current ROM Sum" instead of "Current ROM".
-"Update Speed" menu doesn't look like crap anymore.
@Phil:
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.
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.
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
@Phil
Sounds like a great idea, at least comparing author info shouldn't be too hard to do. I'll see what can I do about it later this night.
@Maximus
I see. Then, great! Keep up the good work. :D
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
One thing I didn't like about 0.98.15 was that Mickey Mouse 3/Kid Klown had some graphics bugs. Your version have this problem too, and also my submission desyncs again. :(
I hope you can find a way to use fceu-mm mappers without having to use anything from 0.98.15. If that's not possible, I guess it's ok... Mickey Mouse 3 seems to be the only game that 0.98.16 movies won't sync in 0.98.15.
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
@Maximus
Other games that don't work since 0.98.16:
-Power Blade 1
-Startropics 1
-Startropics 2
@klmz:
I only followed these steps. I don't know what could be causing your problem, sorry; this was my first time I compiled something.
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
I see. Actually, that's a different bug. It may be related to this one:
If you're playing in read only mode 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.
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.
The bug I fixed was this one:
1. Save a state without recording or playing a movie.
2. Start playing a movie in read+write mode and load the state.
3. FCEU would give an error but still start recording over the movie, overwriting everything from that point (as if it would have loaded a valid state from the movie).
This one was possible to fix because FCEU can detect if the state was saved while playing or recording a movie; but, as I said, it can't detect if the state is from the same movie, so your bug will always be there until someone changes the movie file format.
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
Phil wrote:
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.
Uhm... It looks like we're not talking about the same bug, as I've never experienced that. Can you give me some precise steps to reproduce this bug?
Phil wrote:
Memory watch is indeed ok but not Memory Viewer.
Yeah, you're right. I've never used Memory Viewer, so I didn't want to mess with it. I'll see if I can make it update at the same speed as Memory Watch, if that's ok.
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
FCEU v0.98.21
http://popibot.com.ar/fceu-0.98.21.ziphttp://popibot.com.ar/fceu-0.98.21-src.zip
*Memory Watch update speed is configurable now:
Explanation of settings:
*Low works exactly the same as v0.98.20. It's the default and recommended setting.
*High should work like v0.98.16 (very high CPU usage and lot of problems, but very smooth refresh rate).
*Normal is something between these two.
So... Everyone should configure it according to their needs and computer specs. Most people should be ok with low update speed, I've been TASing a couple of games with this setting without any issues.
(This will be my last release if no one comes up with bugs introduced with my changes. I'm sorry for the version numbers mess. And yes, I know that menu looks like crap. :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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
FCEU v0.98.20
http://popibot.com.ar/fceu-0.98.20.ziphttp://popibot.com.ar/fceu-0.98.20-src.zip
*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.
Specifically, Memory Watch updates like this now:
*When emulation isn't paused it updates ~2 times per second.
*When emulation is paused it updates when you manually frame advance or load a savestate.
I'd like to hear some feedback on this, specially if someone thinks it doesn't update fast enough when playing in real time or if it should also update with some other action when it's paused.
@Maximus
It's great to read that. :D
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
I did a minor improvement to Memory Watch in v0.98.18, but you'll only notice it if you're working with frame advance only. I'd love to see it not being such resource hog too, but sadly my knowledge in C and maths is really poor. Actually, I don't know C at all; this was the first time I saw some code. :P
Anyway, someone better than me should try to see if he can improve the UpdateMemWatch() function in memwatch.c; it's a really short function, but it's the one that takes all of the CPU power. I can't understand anything in it.
And I tried to fix other bugs too, but as I said, my C skills are really poor. I'll try to read some books about C now it got me interested in it, so maybe someday I will make a proper new version, with updated mappers and boards from fceu-mm too (I'd really like to have Startropics 1/2 and Power Blade 1/2 fixed someday).
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.
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
It's most likely a problem with FCEU. Emulator Movie Front only seems to work with a special FCEU version.
As far as I understand, it passes this command line argument: -playmovie "moviefile.fcm" "romfile.nes"; but FCEU was never coded to read the "-playmovie" argument.
I can't find the source with that nitsuja's modification, so I'll try to make my own and re-release v0.98.18 with this.
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.
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.
When FCEU does have 2 windows opened such as "Memory Watcher", FCEU becomes CPU hungry and it causes many problems like "Turbo is unstable".
The only change I made related to this is that now "Memory Watch" window will only update when emulation is not paused, so CPU usage should be much lower when you're only using frame advance. CPU usage should still be high if you're playing at normal speed, so "Turbo is unstable" and related bugs are still around.
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.
Experienced Forum User, Published Author, Player
(79)
Joined: 10/26/2007
Posts: 693
Ok, thanks for testing Phil. And yes, you understood well. :P Sorry for my english...
I uploaded the new version and its source here:
http://popibot.com.ar/fceu-0.98.17.ziphttp://popibot.com.ar/fceu-0.98.17-src.zip
The source has the missing file ("Makefile.in") and a few fixes in "file.c" and "video.c" so it doesn't throw errors during compilation. I also changed the link in FCEU about window to this thread.
I plan to release a .18 version soon, with some bug fixes (if I can fix them :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.
Explanation of settings:
*Low works exactly the same as v0.98.20. It's the default and recommended setting.
*High should work like v0.98.16 (very high CPU usage and lot of problems, but very smooth refresh rate).
*Normal is something between these two.
So... Everyone should configure it according to their needs and computer specs. Most people should be ok with low update speed, I've been TASing a couple of games with this setting without any issues.
(This will be my last release if no one comes up with bugs introduced with my changes. I'm sorry for the version numbers mess. And yes, I know that menu looks like crap. :P)