That would be nice, but I just had thought that it might won't help / hard to implement. For example, you want a grid of 5x5 pixel on Super Mario Bros. 3, now: You want grid to follow background? (hard to implement) OR You want grid to stay in pixel? (might won't help tell you if you make frame improvement)
I just usually find something as a guide to show me if I make any frame improvement, I'm sure many other do that too.
Hi. This might have already been requested, but I'll ask now just in case. Could you make it so that hot keys can be assigned buttons from a gamepad? I've been using a JoyToKey mapper as a workaround, but it would be more convenient if this was supported directly in FCEU.
Some years ago even the power pad settings only worked with the keyboard, so I asked the FCEU developers to fix it. At the time they said that wasn't worth fixing, but now the power pad part seems to work with gamepad buttons, and it looks to me that input.c is written such that this modification shouldn't be too difficult to implement.
Apparently, FCEU doesn't save configuration here or maybe it resets it when opening FCEU.... When I restart FCEU, I must reconfigure my hotkeys.
Actually it is saving but maybe there's something after hours of play that resets it before closing FCEU. I was sure it was saved before.
And I didn't opened other version of FCEU since you would have asked that question :P
Major bug that need to be fixed soon.
Anyway, as temporary solution I made a backup of my config.
Well, some idea of when it happens or how to make it happen would help, or a copy of a config file after it saves that the hotkeys are reset. Right now I'm not sure I believe this bug really exists (although if history is any indication, it probably does).
It happens 3 times. I am 100% sure it's a bug.
P.S. It's you who supposed to explain me why it's doing that :P when it wasn't there before. Anyway, it's hard to find the real reason since my FCEU is usually opened for several hours, sometimes days.
Well, both the old and new versions of FCEU seem to save the configuration only when the program is exited normally. Users who have the habit of leaving one instance of a program open for days on end are more likely to finish those sessions with FCEU crashing some way or another, in which case any hotkey settings made long ago can still be lost.
I'd prefer if settings were always saved immediately after making changes to any of the things in the Config menu.
Back when it was just Blip's/Phil's patches, I noticed that FCEU would lose its hotkey settings if I loaded one of the older, "official" versions of FCEU. Though sometimes it would lose some of its hotkeys anyway... Is that related to this?
put yourself in my rocketpack if that poochie is one outrageous dude
Back when it was just Blip's/Phil's patches, I noticed that FCEU would lose its hotkey settings if I loaded one of the older, "official" versions of FCEU. Though sometimes it would lose some of its hotkeys anyway... Is that related to this?
Hint: I already answered that question before anyone asked it.
Hi. One thing I'd like would be the option to make the Cheats window a modeless dialog so that I don't need to open and close it repeatedly when searching for cheats. This might require more GUI recoding than such a nuance is worth though.
edit: Okay, after using the cheat function for a day I realize its interface is plenty lacking. I can't select multiple codes at a time for deletion/toggling, and it would be nice if I could quickly transfer a set of codes from the cheat search to the installed cheats. Some button shortcut keys would be nice, explicit save/load, etc. Weighing in all this, I guess it would be too much coding to do on a feature utilized by so few users. Oh well.
I've got a savestate that became corrupted for unknown reason. I am sure it is related to "FCEU sometimes change a valid savestate to another savestate that reset the game." problem.
Here is the state and pictures that show what it should be and what it shouldn't. http://hiddendragon.sytes.net/corrupted%20save%20+%20pictures.rar
Hope it will help fixing the problem.
Also, I've just noticed there some blinkings in memory viewer. Is it fixable?
Do you have the uncorrupted save state also? (If not, you could make a new savestate at the same place that you got the uncorrupted picture from, and that would be better than not having it.)
No, it doesn't help doing that. While you wrote your post, I found something interesting.
Download this: http://hiddendragon.sytes.net/Double%20Dragon.rar
Now, open the savestate in the game, all looks ok. Now, load the state again, skip 1 frame then save then let the game play and load the state. Voilà, emulation is crashed. If you do those steps again except that you skip 2 frames, all is ok. Something is messy and MUST be fixed.
Edit: Btw, while doing those testings, one time my savestate become a savestate that reset the game. So I am 90% sure it is really related.
OK. I asked for an uncorrupted and corrupted version of the same frame because then it would be easy to compare the files to find out what exactly became corrupted in the save. But this is better, a way to actually reproduce the bug.
I said it's impossible. Even if I send you the movie, create and load a state at frame 6939 makes that happen. It's the savestate feature that isn't 100% reliable. There's probably something that doesn't save or save correctly and that would explain why it is doing that.
If you load that state you gave, then step 1 frame, then load it again, then unpause, it always resets the game. So maybe it's not the save state that's being transformed to reset the game, but it's actually certain times in the game when you can't load other states without messing things up. Anyway, this proves they're related.
One question: Why is the status info at the bottom of the screen shaking like that after loading the state? Does that normally happen, or is it something weird with the savestate that's making it happen?
This is weird - after I load that state, both the memory and the registers are completely identical no matter whether it's going to reset or play normally afterward. And nothing seems to be wrong with the savestate loading or saving, even when it makes the game crash. I think the problem is some variable that isn't part of the savestate (format) but should be.
Do you know of any games besides Double Dragon that may have had this problem before? I'm wondering if it's specific to this mapper (MMC1).
I know it happens in Battletoads which is made by Tradewest like Double Dragon but battletoads is AOROM not MMC1. I know it happens in other games but don't remember which ones. Thinking of that it also happens in Legend of Zelda( MMC1), when I was doing my version.
Joined: 8/3/2004
Posts: 100
Location: Michigan, United States
When using the latest version (v6 - Dec 4, 2005) the sound skips/studders terribly. I know it is this specific version because I reverted back to the previous one and the issue went away. Did something change in the sound code with v6?
the sound skips/studders terribly. I know it is this specific version because I reverted back to the previous one and the issue went away. Did something change in the sound code with v6?
(At what speed is this happening, btw?) I have this problem in older versions too sometimes, it depends a lot on the sound settings, like what you set the sound buffer length to and what the quality/rate/force 8-bit options are set to. But the code did change somewhat, notice the option called "Use old update code" in the Sound Configuration, that puts it back the way it used to be in case the old code worked better for you. (If that doesn't fix it to put the code back the way it was, then it's probably a problem with the settings.)
Phil wrote:
know it happens in Battletoads which is made by Tradewest like Double Dragon but battletoads is AOROM not MMC1. I know it happens in other games but don't remember which ones. Thinking of that it also happens in Legend of Zelda( MMC1), when I was doing my version.
I'm a little closer to tracking down the problem now... A memory read instruction (at 0x8003) is giving a different value than it should when this happens. I think it's somehow related to memory bank switching not being fully loaded, because the memory bank information isn't stored in the save state and it is instead the responsibility of each mapper to restore it properly, and both MMC1 and AOROM have some bank switching (affecting the range after 0x8000) that can happen when the game's running, or at least that's happening when it shouldn't be to make it crash/reset like this.
