Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Randil wrote:
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.
This isn't a bug. This was changed because the old fceu creates a bunch of folders before you even have a chance to tell it not to. If you operate fceu from a fresh .cfg it will have no default folders (and none created). You go to directory overrides to assign them. It will prompt you before creating any new directory (which I think is nice).
ROMs don't have an initial folder (I personally feel that they should)
Are you saying you think the "ROMs" directory override should be /ROMs? That could possibly be arranged.
and the folder for Lua-scripts is named (null), where "Lua-scripts" or something would be better.
Memory watch: nice catch! I missed that one. Fixed in the new FCEUX.
Reload Lua script: added default as shift+L
blah blah full screen
Full screen is broken. Actually prior to release it couldn't even go to full screen (some recent bug fix must have enabled it somehow).
Anyway, obviously it should be fixed, but all of us are concerned about TAS tools, rom-hacking, etc. It just hasn't been on the priority list (especially when all current developers don't even use/like full screen).
Please no more reports releated to fullscreen. We know/
EDIT: I found a situation where Lag Counter does not detect a lag frame.
Lag counter looks for frames where the game is not responding to user input. On these frames it displays red and increments by 1. Obviously this isn't 100% indicitive of "lag". On the lag frame you speak of, apparently the game still responds to your input, even though it freezes teh screen for 1 frame (which for your fastest time goals, is bad).
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
adelikat wrote:
This isn't a bug. This was changed because the old fceu creates a bunch of folders before you even have a chance to tell it not to. If you operate fceu from a fresh .cfg it will have no default folders (and none created). You go to directory overrides to assign them. It will prompt you before creating any new directory (which I think is nice).
Ah, ok, that makes sense.
adelikat wrote:
Are you saying you think the "ROMs" directory override should be /ROMs? That could possibly be arranged.
Yeah, this is just how I personally keep my ROMs, but maybe it's not the most common way. :) It's just a personal preference.
And I understand that full screen problems aren't a big priority, I don't really mind the problems either, I rarely play games in full screen mode. So continue focusing on other stuff first. :)
I guess I'll need to write a Lua-script to detect lag 100% accurately in Blues Brothers, perhaps by checking if my x and/or y position changes between 2 frames. Well, it's no biggy. Keep up the good job!
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Randil wrote:
Yeah, this is just how I personally keep my ROMs, but maybe it's not the most common way. :) It's just a personal preference.
Well, I don't think I am going to change the default in this case. If anything, because that is why the directory overrides are there in the first place, to set up your own personal preferences :) There are at least as many people who would prefer it the way it is now.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Randil wrote:
I guess I'll need to write a Lua-script to detect lag 100% accurately in Blues Brothers, perhaps by checking if my x and/or y position changes between 2 frames. Well, it's no biggy. Keep up the good job!
Here!
local adrx = <enter address of x coord in ram>;
local adry = <enter address of y coord in ram>;
local lastx = -1;
local lasty = -1;
local didnotmove = 0;
while (true) do
local x = memory.readbyte(adrx);
local y = memory.readbyte(adry);
if (x == lastx and y == lasty) then
didnotmove = didnotmove + 1;
end;
lastx = x;
lasty = y;
gui.text(10,10,"Unmoved frame counter: "..didnotmove);
FCEU.frameadvance();
end;
Now all you have to do is act like you're in the movie Speed and this counter will work fine... ;)
... In menu go to config, below go to video, then on the left bottom part, look for a dropdown called "special scaler". ...
No, actually those are scaling algorithms for people who hate rough edges. Wasn't exactly what I was looking for...
Bisqwit wrote:
... 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. ...
This did the trick. Now Mario is properly blocky. :) Thanks!
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Joseph Collins wrote:
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. >_<
My previous reply has been absoleted. The current interim build supports old savestates (.12 ~ .28) that DON'T have a movie embedded (we don't give any guarantuees for savestates that do). You can download the current build from SF SVN or wait for a 2.0.2 release :)
According to SF bug 2037733, zipped .fm2 files may be used to watch a run. Trying to use such a zipped run results in a segfault for me.
I tried submission #2042 for this and built the .fm2 using the Windows build of FCEUX 2.0.0.
/Any progress for the things I mentioned on page 3 so far? :)
//Also, why are zipped runs supported, but not zipped ROMs?
///I know I'm getting annoying, just wanted to add something about the Lua thing: when installing it by hand the filenames do not contain "5.1", they're called "lua.h luaconf.h lualib.h lauxlib.h" and "liblua.a".
Using turbo at the 1% speed crashes FCEU in a few seconds. And generally using turbo under slow speeds (up to about 25%) seems unstable. The sound changes pitch randomly, sounding like a broken tape recorder.
Speculation: Since the sound pitch is dependent on emulation speed, when the pitch drops, does the emulation speed too? Is the turbo badly implemented, does it make unnecessary calculations?
(Considering that the "slow turbo" is slower than the regular one [and should therefore require less calculation], shouldn't the slow one be more stable?)
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Swedishmartin: Thanks for reporting. We'll look into it. What OS are you using?
ShineyDoofy: About the zip files. I can play zipped fm2 files. Can you try to create a new fm2 file, zip it and play it back, see if that crashes? Also, what OS are you using FCEUX on? By the way, under Windows, make sure 7z.dll is in the same dir as FCEUX, it needs that.
Opening roms is supported but bugged for the moment. It's been added to the bugtracker.
I'll report the Lua filename thing.
As for the page three thing, if you're refering to the soundchannels, I don't think that's gonna happen any time soon but I've added it as a feature request.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Ok yeah so it's page 4 :p Anyways
I've been able to reproduce the crash on loading a zipped rom once, but no more after that. Kind of odd. Can you try to reproduce the crash and tell me exactly what steps you've taken?
As for the rest:
Lua docs: I think that's part of the SDL build? That's being worked on (and also, I haven't got a clue about the SDL build) so maybe it'll be fixed when that's done. If not please say so.
cheat.cpp now has an ending newline
The .html doc now contains proper switches. It also contains a nice red warning that it's an ancient doc. Please keep this in mind. Feel free to update it to the current FCEUX if you want to, for Windows users there is the fceu.chm. The other documentation comments fall under the same category; that doc is ancient.
Family keyboard: yeah I don't know about the SDL build :p
Config file: There's no backwards support for older versions simply because there are so many versions (not just in the FCEUltra branch). Doesn't google give you enough info on keycodes?
Zipped roms are supported. There appears to be some kind of crash but I couldn't reproduce it once it happened. If anyone can give me some steps to reproduce the crash (when loading a zipped rom) we'd appreciate it.
About .fcm: yeah, I think we're planning on putting that somewhere more obvious for the Windows build. SDL: no idea.
I'm adding the movie support as a feature request but I'm making no promises here :)
OpenGL: I'm not quite sure how to handle that issue. Are more people experiencing the same problems?
--special: I've reported it
Sound: I think this is still an issue with the SDL build and I'll wait with reporting it untill we're satisfied with the SDL build. When we are and if the problem persists, please report it again :)
gfceux: although I'm not sure what state gfceux is in, I've added your comment to the bugtracker. I think we are still looking for somebody to help us get that project straight. If you'd like to help please let us know :)
Thanks for the feedback. Keep it coming!
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
At this point we are discussing bugs in a interum release. I think for the sake of avoiding confusion, this needs to be taken elsewhere (like the sf bugs list), and leave this thread for 2.0.1 bug reports (and compliments :P)
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.
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.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Ok. The following issues have been fixed, in no particular order (expect a 2.0.2 release soon, you can download the interim build from SF SVN to build it yourself).
- Moviefilenames now get .fm2 attached when no extension was given
- The --special(fs) parameter has been fixed
- When recording input, player three no longer holds a few buttons when he was not supposed to
- Lua painted stuff no longer remembered by savestates (on load)
- Config filename changed (fceu98.cfg -> fceux.cfg)
- Added author textfield when recording a new movie which is added to the fm2 header
- Mute sound while turbo option added
- UTF-8 support for converting old movies
- Frame advance can now (optionally!) skip lagframes
- Playback of zipped moviefiles (like roms) now possible
- Minor issue with sound when recording an avi fixed (recorded movies without sound are now accepted by Youtube).
- Lagcounter added to savestates
- When recording/replaying a movie, the SRAM is wiped.
I think the rest was fixed in 2.0.1 or earlier. Anyways, this should give you an idea of what's currently going on. We're still working on several bugs but like I said, expect a 2.0.2 soon :)
--
Forgot about player three.
--
And SRAM :p
First things first, I'm on Gentoo Linux. I'm running kernel 2.6.26 on an 3800+ AMD dualcore (x86, not amd64). gcc 4.12, glibc 2.6.1. Thus, I'm using the SDL version.
qFox wrote:
I've been able to reproduce the crash on loading a zipped rom once, but no more after that. Kind of odd. Can you try to reproduce the crash and tell me exactly what steps you've taken?
Sure. I just checked out revision 809 and compiled it using "$ scons". I take any random ROM and zip it with "$ zip -9 romname.zip romname.nes" to create a file called romname.zip, In this case, I created fullmoon.nes with this IPS file.
$ crc32 fullmoon.nes
63a94c78
$ zip -9 fullmoon.zip fullmoon.nes
adding: fullmoon.nes (deflated 29%)
$ ./fceux fullmoon.zip
Starting FCEUX 2.0.2-interim...
Loading fullmoon.zip...
An error occurred while loading the file.
qFox wrote:
The .html doc now contains proper switches. It also contains a nice red warning that it's an ancient doc. Please keep this in mind. Feel free to update it to the current FCEUX if you want to, for Windows users there is the fceu.chm. The other documentation comments fall under the same category; that doc is ancient.
Great, thanks! :)
qFox wrote:
Config file: There's no backwards support for older versions simply because there are so many versions (not just in the FCEUltra branch).
Ok, makes sense.
qFox wrote:
Doesn't google give you enough info on keycodes?
The only thing I could find so far is this listing. It only features the names for the specific keys, not the numbers you guys use.
qFox wrote:
I'm adding the movie support as a feature request but I'm making no promises here :)
[...]
--special: I've reported it
That's great to hear. Looking forward to it!
qFox wrote:
Sound: I think this is still an issue with the SDL build and I'll wait with reporting it untill we're satisfied with the SDL build. When we are and if the problem persists, please report it again :)
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).
qFox wrote:
gfceux: although I'm not sure what state gfceux is in, I've added your comment to the bugtracker. I think we are still looking for somebody to help us get that project straight. If you'd like to help please let us know :)
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.
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]
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
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.
Welcome to TASvideos :)
punkrockguy318 wrote:
What videolog are you talking about?
--videolog is a parameter that Bisqwit (this site's owner) added to .98.12 in order to be able to play a .fcm file and encode the video at the same time. The game's speed was determined by the speed your computer could encode the raw video and audio streams with mencoder so that no frame was lost or anything. This way avi files were made to publish tool-assisted speedruns on this site.
punkrockguy318 wrote:
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.
I didn't know about the version breakage, but lua is definately not officially distributed as "lua5.1". Check the official Makefile for 5.1.3.
However the case may be, let's not fight over it. I'll just keep on patching SConstruct and the problem's solved for me.
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.
That sounds even worse for me.
punkrockguy318 wrote:
It shows *.nes files. It no longer has the *.zip filter because zipped roms are broken in sdl right now
Ironically, it does now. Strangely though, the key binding for my NES pad didn't work anymore and even configuring them again didn't do a thing.
At this point we are discussing bugs in a interum release. I think for the sake of avoiding confusion, this needs to be taken elsewhere (like the sf bugs list), and leave this thread for 2.0.1 bug reports (and compliments :P)
I didn't know about the version breakage, but lua is definately not officially distributed as "lua5.1". Check the official Makefile for 5.1.3.
We chose to use the policies instituted by luabinaries because the emulua system is supposed to be easily extensible by means of dropping in shared libraries compiled by third parties, and generally organized at luaforge.net, and they SHOULD be linked against the official luabinaries. For example, do you feel like compiling iuplua? If you do, then you would be able to play with some of the gui scripts that qfox is working on and that everyone is in the process of figuring out how to support better in the emulator. If you manage to figure out how, let me know. But you should probably use the binaries at luaforge.
Joined: 12/25/2007
Posts: 86
Location: Muhos, Finland
Finally Startropics 1&2 works with FCE ultra :)
<small>Big signature cleared by admin; read <A>forum rules</a>.</small>
<small>-Me:..and big sig. was just small picure(two row's), It dont even lag my 3660's web browser >_></small>
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.
