I've got a question: how did you build the source while preventing the excutable from being CPU-hogging? I tried to build all the 0.98.1Xes using their Makefiles with MinGW but everytime it resulted in a much slower excutable. Maybe some CFLAGS and/or LDFLAGS for optimization?
<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
Emulator Coder, Site Developer, Site Owner, Expert player
(3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Well, I messed with FCEU .21. It works great. I had 2 FCEU's + two heavily loaded memory watches open and both could run at 100% (and no computer crash)! The avi encoding worked out just fine too.
Thank you sooo much. These were much needed fixes.
I have another idea (that I hope isn't too much trouble). FCEU can have a really hard time finding disksys.rom (for fds games). Could it be set up so that there is a directory override in the directories menu for disksys?
That way I have some way of telling fceu "Look here" for the dang file.[/i]
Ok, after farting around for a few hours, I've managed to merge the fceu-mm mappers with the source of 0.98.20 (not 21, but I didn't check the forums until this morning :P).
My test rom was PowerBlade 2, which works for the compiled version of fceumm, but for some reason it doesn't work with mine :( I was wondering if I can get a list of games that are known not to work with the current version of FCEU that I can run some tests on.
You can try to merge the fceu-mm mappers with the source of 0.98.15 in order to see what is the root of the problem.
Games that I know that don't work since 0.98.16:
Banana Prince - gray
Gun-Nac - cannot start
Mitsume ga Tooru - ?
Power Blade 2 - gray
some smb1 hacks - cannot start
<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
@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.
I guess that would be the best course of action, but that would involve first merging the mappers with 98.15, then merging luke's changes for basicbot/shared-memory, then adding mz's changes.
I'll take a look later though (wife's working tonight so I've got some time :P). One thing I did find interesting though is how many files were virtually identical between fceumm and fceu9817 (there are only 43 files in the source tree that have some luke or tas-specific changes after doing a merge of the original files).
What I ideally want to accomplish though is the following:
* merge mappers/boards and make sure they work
* merge luke's and mz's changes into the working copy
* incorporate the enhanced features of fceuxd into 98.*
The last is a "nice idea, but unlikely", but I figure if I say it out loud, I'm more likely to actually work on it ;)
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.
Fair enough. On the bright side though .....
I tried a different approach, and have REVERTED the mappers and boards to the state they were in with 98.15. This may be detrimental to some games, but Startropics, Startropics 2 and PowerBlade 2 work now. I tagged this release as a beta (in the fceu main window) so that it's easy to differentiate, but if everything works, I'm going to try to start adding the new mappers and boards from fceu-mm.
There weren't all that many changes from 98.15 to 98.16, so i'm not sure what messed up those games, but i'll see what I can find as I update them. This build is based on the mappers/boards of 98.15 and some modification to the unif.c and ines.c files, but the rest is from 98.21, so all mz's fixes are in place.
Please let me know if something that was working fine is now broken (namely games not loading).
You can download the updated fceu here.
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.
mz: This was a proof of concept release only. I still plan to keep merging the mappers, but now I know I have something that compiles successfully, and fixes some of the known issues that were introduced with 98.16 :D
@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
@mz:
I solved the problem. I noticed that I could see no "fceu98.cfg" in the compiled excutable directory after I ran it. Then I found it was there but its attribute was "hidden"! Simply deleted it and everything went fine. O_o
<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
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.
Good work mz, nice list of fixes :)
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.
This could take a while as I try to pinpoint what's causing the weirdness, but once it's good to go, I'll merge my changes with your latest source tree.
Keep up the good work.
Joined: 11/18/2006
Posts: 2426
Location: Back where I belong
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.
Nice release.
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.
So far it's really reliable maybe too much ;) as the small probem I just mentioned above proves that.
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.
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.
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.
I don't know if it's been mentioned, but I think there's a bug in the double buffering code for the windows version.
It happens when switching to fullscreen with a custom video mode, where the resolution set to the desktop resolution, and with double buffering the sync method. FCEU leaves a flickering ghost image of the desktop around the drawing area. Of course, it won't be visible if the image is scaled to fit the screen.
I've tried fixing it myself, but I can't make ends or tails of that DirectX code. Maybe you can do something about it?
As an aside, it'd be cool if you could add Lua support, like DeHackEd did with Snes9x. I'm not holding my breath for that one, though. ;)
Emulator Coder, Site Developer, Site Owner, Expert player
(3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Well, if you could be so kind as to add this one before moving on:
*Add an option to record "movie start" and "movie end" messages in AVI.
as those really should be in publications and haven't been due to this bug.
Thanks much!
Edited 1st post. Added some people request and removed bugs that are now fixed.
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.
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".