Topic by nitsujrehtona

Posted: 6/1/2008 8:06 AM

Quote

nitsujrehtona

Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA

Hmm, it also fails to identify as 0.98.28 when you open the about box... Because I shipped the wrong damn binary. Sorry for the inconvenience; please re-download. (The source code was current.)

IRC nick: UncombedCoconut

Posted: 6/1/2008 1:29 PM

Quote

ShinyDoofy

Former player

Joined: 12/5/2007
Posts: 716

nitsujrehtona wrote:

If you worry about annoying me, Shiny, you needn't. I hope you'll also be reporting issues with FCEUX/Linux; it'll need testers. If you worry about annoying anyone else, feel free to PM me or submit bug reports to the sourceforge tracker.

Will do so, as soon as I run into one. About the sourceforge page: fceultra.sourceforge.net seems to be the page of the original FCEU, not the one discussed here. Do they use the same bug tracker?

nitsujrehtona wrote:

Anyway, the usual way to get out of frame-advance is to hit the pause button (probably the backslash key for you). Eventually I will want to make those keys configurable and make the frame-advance key autorepeat!

Here's the problem: I've got a german keyboard layout. I noticed that pressing my "-" key slows gameplay down (should be the slash key on a US keyboard), but I can't seem to speed it up again. Currently the hardcoded keybindings are my biggest problem. If these key bindings are gone, it would be just great.

Posted: 6/1/2008 3:05 PM

Quote

nitsujrehtona

Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA

ShinyDoofy wrote:

Will do so, as soon as I run into one. About the sourceforge page: fceultra.sourceforge.net seems to be the page of the original FCEU, not the one discussed here. Do they use the same bug tracker?

The history and nomenclature of all this project's forks can make me dizzy... but the "official" FCEU on that page is ours now! :)

ShinyDoofy wrote:

Here's the problem: I've got a german keyboard layout. I noticed that pressing my "-" key slows gameplay down (should be the slash key on a US keyboard), but I can't seem to speed it up again. Currently the hardcoded keybindings are my biggest problem. If these key bindings are gone, it would be just great.

Configurable hotkeys won't happen right away. The minus key is supposed to slow down the game (and + speeds it back up, as does = (+ without the shift)). If you don't have a backslash key, or the keybindings just make you mad, edit drivers/pc/input.c. Look for the phrase keyonly(BACKSLASH), and change it to something else. If you need a list of legal replacements for the "BACKSLASH", your system should have the file /usr/include/SDL/SDL_keysym.h -- open it up and look for words starting with "SDLK_".

IRC nick: UncombedCoconut

Posted: 6/2/2008 8:22 AM

Quote

klmz

Editor, Emulator Coder, Expert player (2105)

Joined: 5/22/2007
Posts: 1134
Location: Glitchvania

nitsujrehtona wrote:

Hmm, it also fails to identify as 0.98.28 when you open the about box... Because I shipped the wrong damn binary. Sorry for the inconvenience; please re-download. (The source code was current.)

I've redownloaded it and the crash has gone, but the "Base Directory Override" fails to work now.

<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

Posted: 6/5/2008 1:28 AM

Quote

adelikat

He/Him

Emulator Coder, Site Developer, Site Owner, Expert player (3598)

Joined: 11/3/2004
Posts: 4738
Location: Tennessee

1) What do you expect base directory override to do? 2) What is it currently doing? 3) How does that differ from prior versons?

It's hard to look this good. My TAS projects

Posted: 6/5/2008 8:21 AM

Quote

klmz

Editor, Emulator Coder, Expert player (2105)

Joined: 5/22/2007
Posts: 1134
Location: Glitchvania

adelikat wrote:

1) What do you expect base directory override to do? 2) What is it currently doing? 3) How does that differ from prior versons?

1) It should work as in the prior versions (see below). 2) It does nothing whatever directory is set. Nothing else changes if you change it. 3) In prior versions, when you set Base Directory Override to a specified directory, FCEU will use the subdirectories (eg. movie and fcs) under it instead of the subdirectories under the directory where fceu.exe is. The current version fails to do that. EDIT: There is one more bug that might exist since early versions. Sometimes you load a savesate, the emulator gets bugged and the game crashes. Graphics become garbage. Savestates can be loaded, but the game still crashes. You can reset the game to get it back to work. This has only happened to me occasionally with certain games like Treasure Master and I can't tell a certain way to reproduce it.

<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

Posted: 6/6/2008 8:39 AM

Quote

nitsujrehtona

Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA

Thank you for these bug reports, klmz. Is it reasonably easy for you to check whether these "certain games" used the same mapper (or mmc)?

IRC nick: UncombedCoconut

Posted: 6/7/2008 1:08 AM

Quote

adelikat

He/Him

Emulator Coder, Site Developer, Site Owner, Expert player (3598)

Joined: 11/3/2004
Posts: 4738
Location: Tennessee

EDIT: There is one more bug that might exist since early versions. Sometimes you load a savesate, the emulator gets bugged and the game crashes. Graphics become garbage. Savestates can be loaded, but the game still crashes. You can reset the game to get it back to work. This has only happened to me occasionally with certain games like Treasure Master and I can't tell a certain way to reproduce it.

Yes, this is also very common in guerilla war, dw4, legend of zelda and some others that I forget. It has been brought up before and I think might be on Phil's list.

It's hard to look this good. My TAS projects

Posted: 6/10/2008 5:34 AM

Quote

nitsujrehtona

Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA

We've identified a bug causing this behavior in any game which uses an MMC1 board and tends to VBlank in the middle of a write to the controller. The only released version I know of which fixes the issue is .98.15.

IRC nick: UncombedCoconut

Posted: 6/10/2008 3:18 PM

Quote

klmz

Editor, Emulator Coder, Expert player (2105)

Joined: 5/22/2007
Posts: 1134
Location: Glitchvania

Sorry for the delay. Yes, it is those games reported by Adelikat that have the bug.

nitsujrehtona wrote:

We've identified a bug causing this behavior in any game which uses an MMC1 board and tends to VBlank in the middle of a write to the controller. The only released version I know of which fixes the issue is .98.15.

I think you've got it.

<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

Posted: 6/12/2008 11:17 AM

Quote

Phil

Active player (410)

Joined: 3/16/2004
Posts: 2623
Location: America, Québec

So, since it was fixed in .15, like I said, can you use the same fix and apply it for the current version? Edit: One other thing that annoys me is the fceu.cfg file. Normally, such file should be easily editable. But NO. It's like if you need an hex-editor to edit it. :S

Posted: 6/12/2008 9:03 PM

Quote

Randil

Skilled player (1885)

Joined: 4/20/2005
Posts: 2160
Location: Norrköping, Sweden

I've used FCEU 0.98.28 for some time now, and overall I'm very pleased with it, but one thing has been bugging me: When running a Lua-script, if the script tries to perform an arithmetic operation on a nil value, it will return the same error message on each and every frame. As soon as you click on "OK" to close down the error message, a new one appears. This makes it very hard to stop the Lua script because the error messages block you from doing anything else from the menu bar. An example of a Lua script that will give such an error message is:

while true do

local function displayer()

gui.text(128,128,c)  

end

gui.register(displayer)
   FCEU.frameadvance()
end

It would be nice if this error message included a button that instantly stops the Lua script. Oh, and it would be nice if FCEU had a folder for Lua scripts, just like it ha for .txt-files for memory watch. Keep up the awesome job! :)

My own page on this site.

Posted: 6/13/2008 12:09 AM

Quote

nitsujrehtona

Joined: 3/17/2007
Posts: 97
Location: Berkeley, CA

Phil: fceux addresses both. As time allows, I'll update the .98.xx series. Randil: That sucks; I'll change the way it handles those situations. What's actually happening is that the Lua engine is killing your displayer function, unregistering it, and letting the rest of the script continue. If you register it just once, rather than re-registering it every frame, you won't be paralyzed by an army of message boxes.

IRC nick: UncombedCoconut

Posted: 6/15/2008 9:13 PM

Quote

Andypro

Joined: 5/24/2004
Posts: 262

I wanted to do some testing on the different fceu windows versions to figure out where the directdraw error in fullscreen mode bug started. To my surprise, none of the fceu versions exhibit this bug anymore. I haven't updated my video card drivers, so I'm not sure what caused the fix. Perhaps it was XP service pack 3 that had something that fixed it. The secondary bug that went along with this still exists, and I've provided the details below: FCEU video sync setting / sound distortion and echo bug Versions affected: 0.98.12 official -> current rerecording build Cause: Setting the video sync mode in either windowed or fullscreen mode to anything other than <none>. Description: As soon as a video sync mode other than <none> is chosen, the game sound/music starts distorting. The distortion ends up coming in "waves" which are delayed playbacks of portions of the music mixed in with the currently distorting sound. Every few seconds, the process "rights" itself and eliminates the echo(s), but then it instantly starts distorting again ad infinitum. Checking "disable hardware acceleration" on the video screen *does* seem to eliminate this bug, although it's not a great fix since doing that apparently forces either 8bpp or some scaler to be disabled which makes everything look blocky and ugly. As suggested on the video screen, I tried playing with the timing settings to no effect. I don't know if a repository was maintained for the original source, but I would like to have a look at the code for versions 0.98.10 (no problems) and 0.98.12 (problems begin). I might be able to find the change that caused the issue and one of the current devs could patch it.

Posted: 6/29/2008 4:56 AM

Quote

Dammit

Experienced player (574)

Joined: 1/11/2007
Posts: 103

Recent releases do not write SRAM files. (.sav files) It seems this happened between version 22 and 23.

Posted: 6/29/2008 8:46 PM

Quote

adelikat

He/Him

Emulator Coder, Site Developer, Site Owner, Expert player (3598)

Joined: 11/3/2004
Posts: 4738
Location: Tennessee

Dammit wrote:

Recent releases do not write SRAM files. (.sav files) It seems this happened between version 22 and 23.

Oh, crap. You are correct. It apparently will load a .sav file. But it will not create one.

It's hard to look this good. My TAS projects

Posted: 6/29/2008 11:07 PM

Quote

mz

Player (79)

Joined: 10/26/2007
Posts: 693

God, I'm really really sorry about that. I knew my ugly hacks were going to break a lot of other stuff. :P If anyone else wants to fix it and release even another version, you only have to revert my stupid change to line 222 in "fceu.c", just below the line that says "// What in the name of fucking.... vvv". :$

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.

Posted: 8/16/2008 2:33 AM

Quote

Pasky13

Former player

Joined: 5/4/2005
Posts: 502
Location: Onett, Eagleland

Just FYI, tried to compile this under Linux for a PPC architecture and it ran into what seems to be some Endian trouble when compiling. Not on my PS3 at the moment but I'll post the file and lines later. Sorry if this was the wrong place to post it.

I think.....therefore I am not Barry Burton

Posted: 8/16/2008 8:54 PM

Quote

adelikat

He/Him

Emulator Coder, Site Developer, Site Owner, Expert player (3598)

Joined: 11/3/2004
Posts: 4738
Location: Tennessee

I don't think this topic should have changed to FCEUX. It should remain a FCEU.28 branch topic. Perhaps a spearate one for bugs in FCEUX? But the Sourceforge bugs page serves more adequately and is current and maintained. EDIT: it is also confusing to have 2 discussions about the most current emulator.

It's hard to look this good. My TAS projects

Posted: 8/17/2008 5:58 AM

Quote

Phil

Active player (410)

Joined: 3/16/2004
Posts: 2623
Location: America, Québec

No, when I have created that topic, it was to report bugs in first post, the subject was Something like "Things to be improved/fixed in FCEU" then the topic was changed for "FCEU development". But yes, maybe a new topic should be created since this one does have 35 pages now.. I don't agree with the "Sourceforge bugs page serves more adequately" as I don't trust that anymore. I've noticed that developers tend to ignore people there or just give some stupid replies. And in the end, the bugs aren't fixed.

Posted: 8/17/2008 8:50 AM

Quote

qFox

Joined: 4/25/2004
Posts: 615
Location: The Netherlands

Well, at least for now, that isn't true for FCEUX. Unless you persist in asking questions answered in the help files of course. We're maintaining the tracker very actively and try to fix bugs found asap.

qfox.nl

Posted: 8/24/2008 6:34 PM

Quote

klmz

Editor, Emulator Coder, Expert player (2105)

Joined: 5/22/2007
Posts: 1134
Location: Glitchvania

If "Enable Run in Background" is unchecked, FCEU 0.xx.xx and FCEUX 2.0.2/2.0.3 WIP will fail to pause running when you directly click on the taskbar-minimize button to hide their main windows and then switch to other programs. I guess it is a bug since it isn't supposed to be and Nestopia & VBA doen't have such a problem.

<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

Posted: 9/12/2008 10:40 PM

Post subject: Crash on full-screen

Quote

Truncated

Editor, Reviewer, Experienced player (968)

Joined: 4/17/2004
Posts: 3107
Location: Sweden

When switching to full-sceen, FCEUx crashes. This is on Vista. Specifically what I did was: 1. Start FCEUx 2. Open Legend of Zelda PRG0 3. Start play-back of Baxter's and Morrison's new movie 4. Press Alt-Enter to go into fullscreen This is the error report (in Swedish. sorry.): Problemsignatur: Problemhändelsens namn: APPCRASH Programnamn: fceux.exe Programversion: 0.0.0.0 Programtidsstämpel: 48aa4e53 Namn på felmodul: fceux.exe Modulens version: 0.0.0.0 Tidsstämpel för felmodul: 48aa4e53 Undantagskod: c0000005 Undantagsförskjutning: 00088bbb OS-version: 6.0.6001.2.1.0.768.3 Språkvariant-ID: 1053 Ytterligare information 1: fd00 Ytterligare information 2: ea6f5fe8924aaa756324d57f87834160 Ytterligare information 3: fd00 Ytterligare information 4: ea6f5fe8924aaa756324d57f87834160 Any other info you need I will be happy to give you.

Posted: 9/15/2008 8:37 PM

Quote

Dwedit

He/Him

Joined: 3/24/2006
Posts: 692
Location: Chicago

So I go to watch the new Zelda TAS, then FCEUX takes about 5 minutes of disk access time to parse all FCM and FC2 files before letting me pick one! What happened?!

Posted: 9/22/2008 6:35 AM

Quote

Xkeeper

Banned User, Former player

Joined: 12/23/2004
Posts: 1850

FCEUX doesn't adjust well to small windows. Also, for some reason, playing back a movie using an Lua script (that it was recorded with, using "Load ROM > Load Lua > Start/Play Movie" desynced. This seems pretty bad.

Perma-banned

Locked