I didn't think FCEU would get any overhaul like this, but it turns out I'm wrong! Love all new things, especially the cheat search and the help files.
But there's one thing: With previous versions I used to hold down frame advance to play the game in slow-mo, so that I could pause just by lifting my finger and not having to reach for anything. But now holding frame advance makes the game full speed instead of choppily slow. Is there some way for me to get that old "functionality" in this new version?
Basically, can I get chop-chop-chop slowmotion (the equivalent of tapping frame advance quickly) by holding frame advance down?
Also, please change the turbo sound to something a bit more serene. :)
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
You can lower the speed (default bind is the minus key, near the backspace) and then hold frame-advance...
I doubt the turbo will be "fixed", since this is just a byproduct of the program running a lot faster then you're used to. If you are turbo-ing and frameadvancing you'll want to turn off sound at some point anyways :p
Emulator Coder, Site Developer, Site Owner, Expert player
(3596)
Joined: 11/3/2004
Posts: 4738
Location: Tennessee
Swedishmartin wrote:
I didn't think FCEU would get any overhaul like this, but it turns out I'm wrong! Love all new things, especially the cheat search and the help files.
Thanks, a lot of hard work went into this new version :)
But there's one thing: With previous versions I used to hold down frame advance to play the game in slow-mo, so that I could pause just by lifting my finger and not having to reach for anything. But now holding frame advance makes the game full speed instead of choppily slow. Is there some way for me to get that old "functionality" in this new version?
Sorry, but no. Auto-frame advance moved painfully slow in the old version due to sloppy programming. It was intentionally fixed to be the speed it is now (60 fps). If you want the game to go slower, slow down emulation :P
You can lower the speed (default bind is the minus key, near the backspace) and then hold frame-advance...
oops
Graphics issue:
To the left is Mario from my ordinary setup: window at 3:4 so that nothing is stretched (which leads to a really big window), and to the right is Mario from the smallest possible window with 1:1 proportions, stretched out to normal with the power of Paint®. As you may have guessed, I'd rather have my ordinary window configuration like the one on the right. Can this be fixed by you, or is it a problem with Windows scaling the picture?
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Euhr. Oh, you mean that you can no longer scale the window to something else than 1:1? No, that was purposely fixed. Although I don't remember the reason, I know it was a valid one :)
You should also note that a 3:4 window skews the graphics anyways.... This is how they are shown on a real NES.
I think I found a small bug.
I opened the "directories" box, and all the default values were directories that hadn't been created yet (Since this was my first time running the program, maybe?). It proceeded to create the directories, except one of them was called (null).
Ok, damn it. After I finally found Bisqwit's Post, all I did was misremembering it. I didn't think of literal sound channels, but rather something like turning down the music so you could only hear jumping sounds and such.
My bad :/
Joined: 11/20/2004
Posts: 236
Location: United States
I have a sole complaint about this new version of FCE Ultra which has nothing to do with tool-assisted speedrunning. (More or less.) And that is save states made in FCE Ultra 0.98.12 are incompatable with FCEUX 2.0.1! D: Completely different core or something, I guess... Any way I can fix this? I have a buttload of save states I'd like to not end up losing due to their being outdated. >_<
Oh, and it opens ZIPs and lists the contents now. Including non-ROM files. But that can be fixed easily enough by re-ZIPping all my ROMs or unZIPping them and leaving 'em unZIPped.
Joined: 11/20/2004
Posts: 236
Location: United States
Damn it. Such is the whims of upgrading at times, I suppose! Oh well... Guess I'll be making some new Boss Rush save states later on. Glad I didn't submit any recently! XD
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
If it is part of a recorded movie, it should be possible to convert to fm2 format, playback and save at the appropriate times. Otherwise, there's nothing we can do about it.
Euhr. Oh, you mean that you can no longer scale the window to something else than 1:1? No, that was purposely fixed. Although I don't remember the reason, I know it was a valid one :)
No, I can scale it freely, it's just when I resize the window, the graphics get fuzzier. I want the graphics to stay blocky all the time.
qFox wrote:
You should also note that a 3:4 window skews the graphics anyways.... This is how they are shown on a real NES.
Yes, I know :) That's why I have those proportions.
I have a theory that the fuzziness is because of Windows handling the resizing of the picture. I've got other programs where resized images are "softened" in the same way.
For example:
Above: the fuzzy resizing of the standard Windows photo wiever
So, is this possible to fix?
Just so you know, I'm not talking about Windows' resizing algorithm, but rather the FCEU fuzziness. Is it impossible to make FCEU's graphics always be blocky?
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
The fix is easy, actually. To a certain degree.
In menu go to config, below go to video, then on the left bottom part, look for a dropdown called "special scaler". That does the trick for me in 2x anyways. (Nice, I didn't even know that myself :p)
FractalFusion> Mind sharing that fcm so we can test it?
It's not a particular FCM.
If I click on any file and click "Open", the dialog box closes but nothing happens. It does not say "Converted 1 files(s)..." and no FM2 is produced.
Though if I select 2 or more files and click "Open", then it works.
I have a theory that the fuzziness is because of Windows handling the resizing of the picture.
Partially right. Windows does crappy pixelated resizing by default, not the fuzzy one.
However, if the window is a hardware-accelerated context, such as is the case with most media players, then resizing it will bring in the graphic card's resizing algorithms, which usually means something like trilinear/quadratic scaling, which is indeed somewhat fuzzy, but very nice for e.g. watching movies.
Compare: http://bisqwit.iki.fi/kala/snap/monkeyboy-unfiltered.jpg , http://bisqwit.iki.fi/kala/snap/monkeyboy-filtered.jpg
Joined: 4/20/2005
Posts: 2160
Location: Norrköping, Sweden
Here are some bug reports:
*(Already mentioned by CtrlAltDestroy) The first time you load FCEUX, it doesn't create any folders. If you then go to "Config"->"Directories" and then immediately close the window, it will give an error message for each folder, asking if it should be created. ROMs don't have an initial folder (I personally feel that they should) and the folder for Lua-scripts is named (null), where "Lua-scripts" or something would be better.
*Cut (ctrl+x) does not work on text in memory watch, though copy and paste works.
*Shift+L does not reload the latest Lua-script, like it does in FCEU .28, maybe this is intentional.
The following two bugs happened to me, though it might not be related to FCEUX:
*When playing a zapper-game in Full-screen mode, I couldn't get the cursor to go under the middle section of the screen (I could only keep it at the upper section of the screen). This seems to be the case for all zapper-games
*In full screen mode, when I pressed alt+enter to go back to normal mode, The screen blackened for a second or two and then went back to full screen mode again. It seems that FCEUX exits full-screen mode after a minute or two of waiting though.
EDIT: I found a situation where Lag Counter does not detect a lag frame. On frame 502 in this Blues Brothers movie the game lags, but the lag counter does not increase. Besides this frame, the lag counter has worked well with this game.
Ok, so summing up my thoughts/findings for revision 761:
When running scons, it looks for "liblua5.1" in line 55 of SConstruct. That doesn't work for Gentoo Linux since only files named /usr/include/liblua.{a,la,so} exist. Thus, Gentoo people would have to remove "5.1" and possibly even fix the include and link parameters in line 65 (-> "-I/usr/include/ -llua"). I like the idea of having such a thing around, yet I think it should be optional because a lot of people will probably only use the emulator for regular playing and/or watching a run.
I know this point really is whiny, but: "src/cheat.cpp:928:2: warning: no newline at end of file"
fceultra/fceu/documentation/fceultra.html supposes only a single dash for command line parameters such as "-pal x" although calling fceux itself clearly shows two dashes (although both versions seem to work).
The input configuration documentations differ: ./fceux shows "--inputcfg, -i", but doesn't list gamepad{1,2} as need parameters. The html document instead lists "-input1 x and -input2 x". So if you start fceux with one of these, it asks for "GamePad #4", no matter whether you chose input1 or input2.
Although I haven't tested it yet (what with?) there's emulation for the Family Keyboard. I'm almost certain the standard binding of the `/~ key for the @ sign and other non alphanumerical keys such as the +, [ or \ key won't work on non-US keyboard layouts. This would make a SDL keycodes files even more worthy of having to rebind these.
There's a new config file syntax, which is nice. But is there a way of importing the old config file instead of having to setup it all over again? A little help file listing the keycodes would be nice so user's can edit their key bindings individually.
Regularly zipped ROMs are not accepted ("An error occurred while loading the file.") which imho is a huge regression from .98. In case you're trying to implement this again, bzip2 and 7z support would be highly anticipated, I guess, because they can decrease the ROM' size drastically.
.fcm files are not supported anymore (it exits with a segfault), which I can live with. I'm just afraid that people who are new to this site might have a hard time finding the option to convert these fcms of older runs on the site. So far I haven't found a way of converting "old" .fcm files to "new" fm2 natively under Linux. Until now, I'd have to start the Windows build with wine and have it converted.
Movie creation. So far there's the "--soundrecord" parameter to write the sound of a game to a file, but apparently there's no way of also grabbing the video. This is no regression (as I've only found Bisqwit's .98.12 version actually supporting this), but I'm sure there will be people creating runs with v2 and this leaves the avi creation up to Windows people.
If I activate OpenGL it runs on something like 10 to 15 fps or even lower, which is really a pain and I have no idea why. nVidia GeForce 7800GT, 173.14.12. I'm not willing to use a beta driver that is not officially supported (which would be 177.13 iirc).
The former "--special(fs)" parameter for setting a video filter is missing. When providing it nonetheless, fceux seems to forget about its former sound configuration and still wants to play sound.
When trying to get sound, it hangs itself with the following message: "Audio write: Input/output error". When this happens, the video windows pops up just like before, but stays gray. It seems that fceux can then only be shutdown by SIGKILL. I haven't been able to get any sound at all thus far. I'm using OSS 4.0.1016.
gfceux uses find_binary, but without modifications "only" looks in PATH (an environment variable). Although I also like the feature of having it automatically installed via "python setup.py", this in my opinion is bad for unexperienced users who then can't easily remove it again. In such a case they would have to delete the files by hand via a terminal. Try explaining such a thing to a purely desktop fixated and typing-unknown-commands-into-something-I-don't-like-because-it-ignores-my-mouse-scares-me user coming from Windows. Clearly a .deb/rpm/whatnot package would be the overkill; still one simple command to remove it again is easier for those people. Back to my initial point: personally I don't like scripts spreading files all over my filesystem (yeah, I'm exaggerating, I know it's just /usr/local) without being able to get them removed again in a matter of seconds. Although it wouldn't be a problem for me, it still would be some kind of annoying imho.
I hope my newly made comments sound at least a little better than my previous ranting.
To the left is Mario from my ordinary setup: window at 3:4 so that nothing is stretched (which leads to a really big window), and to the right is Mario from the smallest possible window with 1:1 proportions, stretched out to normal with the power of Paint®. As you may have guessed, I'd rather have my ordinary window configuration like the one on the right. Can this be fixed by you, or is it a problem with Windows scaling the picture?
Above: the fuzzy resizing of the standard Windows photo wiever
So, is this possible to fix?
