It's one of the first thing that I've tested. Do not take to me for an idiot. Btw, I am using latest 2.0.3-interim build which might not be your case.
Anyway I found a solution to desactivate it:
Uncheck "Enable run in background".
It also desactivates the input feature. But I really want it to run in background while not accepting input like the feature suggests it should do.
So, maybe run in background wasn't activated at all in your FCEU. Obviously and logically, if it is desactivated, FCEU doesn't accept input from background.
Also, FCEU doesn't record Reset. I'Ve tried with hotkey, with "Reset" in "NES" menu. It resets and movie frames doesn't reset but reset is not recorded. Noticeable when playing the movie file as it doesn't reset at all.
So, it seems the "TASedit" feature is incomplete and not fully functioning. Why not remove it in from binary until then? Kinda annoying to think a feature is in a software to just know that later, when you need it, it doesn't work.
Is there any chance of having the display bumped up in bitdepth? While I'm sure it would probably cut down on speed somewhat, rounding off to the nearest color tends to make things confusing and/or icky.
Other requested features from me:
- make Lua's gui.text not have a huge, ugly, strange border around it; placing it over the normal display generates a huge gray background, while putting it over Lua's own drawing makes it change colors. Not good.
Also, make spaces the same size as digits. =P Otherwise using space-based padding looks funny and the 0s are rather ugly for that purpose.
(I submitted a bug to the tracker regarding memory freezing and Lua weirdness)
--
Another oddity that I'd really like to have explained/fixed: Lua oddity with joypad.set
The SourceForge page still works... It's 2.0.2, and that page doesn't have the latest test build. I don't either, so I can't help you there.
Lua package, extracted in the same directory.
Small feature requests...
1: If at all possible, increase the number of colors Lua can draw in. It might slow down things, but itwould make using a color-coded overlay a lot easier.
2: Allow gui.text to draw with either no background color, or a set background color, and fix the outline (it's too big)
And the main one that I would really, really like:
3: Make a gui.filledbox function, that makes a filled-in rectangle like gui.box. This should really help, since the only alternative right now is using gui.line or gui.box repeatedly to fill spaces in.
Literally two posts above yours, somebody asked the same question and got a response:
(This also contains the Lua pack, if you're going to be using that.)
Joined: 7/30/2006
Posts: 208
Location: Alefgard, USA
I'm not sure if this has been addressed before, but is there a way to get FCEUX to record and replay a soft reset into a movie?
I've tested it with a couple of games, and I can always record a soft reset, but when I play the movie back, it seemingly reads it in as pressing start (it pauses the game instead of resetting it).
Edit: gah, wrong forum.
But cheers again for this great emulator -- I just keep finding new cool stuff like the lag counter, and it ASKING ME TO SAVE MY MEMORY WATCHES which I stupidly lost so many times before :)
Emulator Coder, Site Developer, Site Owner, Expert player
(3574)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
FCEUX2.0.3 released. You can downloaded here: http://fceux.com
This release fixes most problems mention in this thread.
Significant changes from 2.0.2:
Windows
-reset and power cycle recording now possible
-doesn't read every archive file when scanning for replay dialog. scan them, and only look for *.fm2
-autoload the only useful rom or movie from an archive, in cases where there is only one
-fix problem where replay dialog couldnt work when the process current directory had changed to something other than emulator base directory
-fix fcm conversion, recording, and playback of reset and power commands
-added a toggle for binding savestates to movies (instead of forcing them to be bound like .2)
-permit user optionally to proceed through the movie savestate mismatch error condition, in case he knows what he is doing.
-added a -cfg (config file) command line argument. Now you can load multiple configurations without the need to have different FCEUX's in different folders.
-Load state as... uses the savestate override dir
-gracefully handle non-convertible broken utf-8 text without crashing
- fix a bug in the savestate recovery code which prevent aborted savestate loads from recovering emulator state correctly.
-Child windows inside debugging window no longer get invalid sizes
-menu option for display framecounter
- debugger - fix issue where keyboard keys get stuck when switching between debugger window and main window
-Sound config dialog will now look to see if Mute Turbo should be checked
-Menu option for lag counter now works
SDL
-added support for AVI creation for SDL, see documention/Videolog.txt for more
-toggle lag frame counter for SDL, default hotkey F8
-toggle skipping of lag frames for SDL, default hotkey F6
-user ability to toggle "bind savestates to movie" added for SDL, default hotkey F2
-made the input config window more usable
--inputcfg can now be used without a filename
-fixed issues with missing author field crashing fceux
-added uninstall script for gfceux
-fixed ppc build errors and added LSB_FIRST option to build scripts
--newppu option added to sdl, disabled by default
-lua is now optionala patch. also fixed some build issues.
-fixed an issue where flawed movie would crash fceux on every startup
-fixed issue where windowed mode would always be set to 32 bpp
Lua:
- Lua no longer ignores second joypad.set()
FCEUX 2.0.3 Windows XP (not SDL)
Scale 3x Windowed - Drag the right side of the screen to the right to increase the height of the emulator, drag to the left to cause constant flicker between 2 window sizes.
force integral scaling factors - on
force aspect ratio correction - on
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Note: 2.0.4i (interim build) also contains a lua update that allows you to read from the ROM by means of rom.readbyte() and rom.readbytesigned()
This returns you the same byte as you would get when you go to the given address in your hex editor.
The interim build file (http://fceux.com/zip) currently doesn't have it yet but probably will have it tomorrow.
I haven't checked the rest of the thread, so if this has been asked (and answered) already, my bad.
In fceux 2.0.2 (and 2.0.3), I can't get the turbo hotkey (and possibly others, I didn't bother checking because I don't really tas nes games so I had no reason to check more than that) to actually function.
I tried mapping it to a few different keys, but all had the same result (of nothing happening).
I use xp64, would this be a possible reason why this occurs?
So it doesn't automatically add 16 to the address?
This should be fixed before 2.0.4i becomes widely used.
(If you don't understand what I mean, NES ROMs have headers. I am saying that rom.readbyte should not include the headers in looking up, e.g. rom.readbyte(0x10) should read address 0x20 in the ROM file.
i.e., stripping out the header for the purpose of reading data.)
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
I'm not familiar with it but yes, I was told this included the 16 byte header (eg: rom.readbyte(1) returns the first byte of the header). Imo it's not a bad thing, although it may be a little misleading. Maybe the function can be renamed and the user can do the +16 for himself?
Unless these headers can be of variable length? In which case some mapping function could be added or something.