So it's still tricky. Oh well, FCEUX runs great on Wine.
I'm still interested in your work and I'm supporting this all the way. Linux TASing tools are not nearly as good as on Windows, unless you're a programmer of some sorts.
Agreed. If I need any of the features of fceuX that aren't ported to SDL yet, I run fceuX through wine. However I'm hoping to get all of the features in the win32 version in the sdl version
Yeah, hotkey config is still pain in the ass; and that was really the biggest complaint (along with --inputcfg sucking ass, which has been fixed). But it should be painless within the next couple days
I've mostly wrote the GUI from the ground up yesterday so features are being added at a rapid pace.
IIRC, fceu outputs fcm movies and fceuX outputs fm2 movies
Use whichever emulator you prefer. FceuX is more actively maintained/developed but some users on this forum prefer old-school fceu
As much as having the input of a developer helps, this thread was more than a year old.
Your timing sucks. :D
yeah; i didn't check the timestamp
didn't know i was resurrecting this thread from the dead
i didn't see that only like the first 6 threads or so were post-2008
This looks like a bug in sdl/input.cpp.
g_config->getOption("SDL.Hotkeys.Pause", &bindStateKey);
Should be:
g_config->getOption("SDL.Hotkeys.BindState", &bindStateKey);
----
Here's my script.
local a=savestate.create(1)
savestate.load(a)
And here's how I start it:
fceu/fcx2 --loadlua test.lua game.nes
And fceux crashes. What am I doing wrong? Shouldn't the ensureLoad() method of LuaSaveState in lua-engine.cpp be called at some point?
----
fceulua.h defines FCEU_LuaFrameskip() yet in lua-engine.cpp it is FCEU_LuaFrameSkip(). Neither of which have any meaning -- they're never used anywhere. And hence, choosing the speedmode "maximum" has no effect!
Could you post your test.lua script?
I'm working on fleshing out some issues with SDL and lua.
Does this feature allow changing hotkeys without editing the source and recompiling?
Yes and no.
I plan on implementing the hotkey config dialog later today (or this weekend).
Currently, you can do a sort of ugly hack to remap your hotkeys without editing the source. Edit your fceux.cfg . There should be some options ie:
SDL.Hotkeys.Screenshot = 143
or something along those lines. The number is a SDL keysym. You can find the list of keysyms here: http://www.koders.com/c/fid28C7AB7F38EF27D073CC5B3018444498374E3E1F.aspx
Expect hotkeys to be in the GUI by early next week (this weekend if I'm productive)
I you have a legitimate complaint about something, you're more than welcome to file it in the bug tracker.
In my experience I've found fceuX to be equally accurate as fceu. FceuX also includes some mappers that weren't in fceu
If a game isn't being emulated accurately file a bug in the tracker.
Hey TASvids!
First off, let me introduce myself. I'm Lukas Sabota, the main developer/maintainer of the SDL port of fceuX. I'd like to straighten out any issues relating to fceuX and linux/SDL so feel free to contact me if you're having issues.
I started work on a GTK GUI. Until now, options were changable via the command-line. The new GUI now supports Lua scripts, movie recording/playback, sound options, video options, and will soon most of the features of the win32 version. I'm working on making the SDL version on par with the windows version.
The GUI is not yet in a release yet, but it will be included in the next release. However, you can obtain the source code via subversion and compile it yourself if you would like to test. Testing is greatly appreciated! I'd like to get all the bugs out of the way before the release. I'd also like to include some of the features that are important to the TAS community.
If you would like to compile with the GUI, compile with
sudo scons GTK2=1 install
you could also change the GTK2 variable to 1 in the SConstruct.
Like I said, this really needs to be stress tested! All comments/feedback are greatly appreciated. I can provide .deb binaries if anyone is interested.
Looking forward to getting to know these boards better; it seems like an active community!
Cheers!
Lukas
edit - option is GTK2, not GTK
To ease the headaches of users who use distributions that incorrectly package lua5.1, the build scripts in the latest subversion have been modified to search in lua as well as lua5.1.
I got sound once with "--sound 1 --soundq 1 --soundrate 22000 --soundbufsize 96" but it crackles (like a really old record that has not been treated well over the years).
Try a soundrate of 11000, that's the new default in SDL.
I'd be happy to test. Just noticed something: the browser for ROMs neither shows .nes nor .zip files which I think it did some time ago.
What do you mean here? It shows *.nes files. It no longer has the *.zip filter because zipped roms are broken in sdl right now
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.
Gentoo's naming scheme here is different from most other distributions, and liblua itself. You should file a bug report with gentoo.
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).
As the file states, that is an extremely outdated file. The SDL build uses "--"s for all its options, like most command line linux programs.
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.
The usage information has been cleared up in the latest subversion, and again that file should be put to hell.
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.
I'm really can't understand what your talking about here. All I know is that I've never ever had the slightest desire to emulate a family keyboard.
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.
No, there's no way of importing old config files. The keybinding process will have a GUI in gfceux soon, so that will be made easier. Until then, you can you use the get_key.py script in /fceu/gfceu/ to figure out what the SDL keycode of a key is.
.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.
I have no intention of writing a fcm->fm2 converter for linux. However, fceux will no longer segfault on opening non-fm2 files, as of commit 811.
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.
I'm starting to work on AVI recording in the SDL build, but it's nowhere near ready yet.
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).
are you running any official nvidia drivers at all?
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.
fixed in latest subversion
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.
There isn't an easy way to do this. You don't need to install gfceu, just run it from its directory.[/quote]
ShinyDoofy wrote:
I get "An error occurred while loading the file" when I try and load a zipped ROM. Regular ROMs only work without sound ("Audio write: Input/output error" if I try and activate sound output). The best thing about it is that fceu is seemingly hanging due to the sound and can only be killed by putting it asleep with Ctrl-Z and extinguishing it with kill -9. I'm using OSS 4.0.1016 in case that's of any matter.
Hello all, I'm the main SDL dev on the fceux crew, so I'm going to try to respond to some of your issues. Please include what platform you are using when you leave feedback!
And also feel free to file bugs in the sourceforge tracker; us developers go through the bug list quite often.
Yay, an update. But without -videolog I assume (will try gfceu soon, gotta go right now) :(
First of all, I had to tell scons to check for liblua instead of liblua5.1 (which distribution has a version number for directories unter /usr/include? Never seen that before). However, this is the linking command:
g++ -o src/fceux [way too many files] -lz -llua -lGL -lSDL -lpthread -llua5.1
Why link lua twice? If I omit the last parameter, it compiles fine.
Another thing: The documentation lists the parameters with -, the console lists them with --. Are both methods feasible?
What videolog are you talking about?
Lua is particular about its version numbering; it breaks compatibility from minor release numbers. Lua is officially distributed as lua5.1 and even debian distributes it as lua5.1.
Lua isn't not being linked twice.