I found a significant bug in FCEU regarding PAL/NTSC settings. Right now FCEU screws up the PAL settings when you start recording a movie. (All is fine if you record in the default mode, which is determined by whether the ROM name has "(E)" in it or not.) I'm not exactly sure what happens if you try to play a movie in the non-default mode.
You can tell if this bug is happening the text at the bottom of the screen (e.g. "Playing frame 11034") will be in the wrong position, either too high or too low.
In any case, you can hack around this right now by changing the ROM name include an (E) if and only if you want PAL mode.
Also sort of dumb, but not a bug, is that FCEU saves whether the movie is PAL or not, but doesn't check this when you open it.
I'll put fixes to these problems in the next update. However it appears that changing PAL/NTSC mode is driver-dependent, so I don't know if I can give a whole Linux fix.
You can tell if this bug is happening: the text at the bottom of the screen (e.g. "Playing frame 11034") will be in the wrong position, either too high or too low.
Huh? Well that's hardly a problem. Besides, I'm using a different text rendering engine, as indicated in my patch changelog.
Ah, yeah the description I give is just a symtom in Windows. The text rendering wrong isn't the actual problem; what happens is FCEU is in (for example) PAL mode internally, but the graphics are showing NTSC. Since PAL has more scanlines this makes the text cut off.
It's possible on Linux it would display correctly, i.e. it'd show PAL if you're in PAL. But the movie-loading does have a bug (98.15 does, 98.12 doesn't so maybe you don't even have it actually), such that the PAL/NTSC mode resets to the default when it loads the movie.[/code]
I always use -slbegin and -slend to adjust the scanlines according to my whim anyway. :P
For example, with Rockman it's sometimes helpful to have full 240 scanlines even with NTSC, to be able to see Rockman even when he's outside "normal" screen boundaries.
If you press reset while watching a movie the game resets but the input continues. Is it supposed to be like that?
Yes, it's supposed to work like that, because you can include reset(s) in a movie. This is used in a few of the Nesvideos movies already.
but if he's watching the movie, then this reset should work as a different command that resets the movie as well
Exactly.
Right now, if you're in read only, a reset or power will reset the movie. I realize this is a confusing feature...
Highness wrote:
So how about adding *.7z so one doesn't need to extract roms? =D
That might be a lot of work... someone else wanna give this a shot? 7z code is easily available, it's just a rather big thing to add to a program.
adelikat wrote:
yeah, someone compile all this stuff together and make a kickass fceu with it. Call it 98.16 while you are at it.
I will be upping the version number, since there are new/revised mappers which change the emulation. I'll include as many features as I can get working :)
So how about adding *.7z so one doesn't need to extract roms? =D
Just for the sake of curiosity: you are using zlib.dll with zipped roms, aren't you? I do so, and I don't need to extract them as well (though I admit it'll be much better if a compression ratio was that of 7zip).
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
It will be a challenge to anyone who dares to try it, to attempt to create a windows GUI for the features I've added. Not the least because some of them are configured by editing the source code...
Yeah I looked at Bisqwit's source and I don't think I'll put the things in the Windows version for various reasons. Too bad, because the tile-tracker thing seems pretty useful (making maps or animations). But I think you will be pretty happy with the features in the next FCEU. I should have it ready in a day or two, depending on how busy I am.
I think viewing 4-player input is a little tricky because there isn't enough room to display it properly. I guess if you don't mind it not being nicely aligned, I could make a quick change to show 4 controllers. I suppose for makeing 4-player movies this would be important so you can actually see if you have all the keys down...
Emulator Coder, Site Developer, Site Owner, Expert player
(3598)
Joined: 11/3/2004
Posts: 4738
Location: Tennessee
Luke wrote:
Yeah I looked at Bisqwit's source and I don't think I'll put the things in the Windows version for various reasons. Too bad, because the tile-tracker thing seems pretty useful (making maps or animations). But I think you will be pretty happy with the features in the next FCEU. I should have it ready in a day or two, depending on how busy I am.
I think viewing 4-player input is a little tricky because there isn't enough room to display it properly. I guess if you don't mind it not being nicely aligned, I could make a quick change to show 4 controllers. I suppose for makeing 4-player movies this would be important so you can actually see if you have all the keys down...
can't wait! when do you think we will see it? (not hurry though, I'd rather it be good than soon)
As far as Bisqwit's stuff is concerned, is there anything that can be more easily compiled? I'd like to have a windows version with as many of the features as possible.
Also, don't forget about being able to set the memory viewer profiles directory under the directory config ;)
Right now I'm working on a rewind feature. Once I am done testing this I will post a new version.
I like the idea of displaying a controller to show the input. If it's not difficult I'll try to add that later, but don't expect it in the next release.
Here's why I'm not planning on including bisqwit's stuff, if you're curious.
- Bisqwit's custom input defaults
- Bisqwit's compose mode for making 2p movies easier to create
These are redundant with the Windows input configuration. I don't really want to maintain the linux code, especially since I don't have a Linux box at the moment.
- BisqBot (with settings last configured for Rockman 2 scrolling substitution)
BisqBot options are all in the source code, so it's really tough to integrate it with the GUI. Also BisqBot is very game-specific.
- Warp's font for smaller HUD texts (fits more text on screen)
Could do this, but not a high priority since FCEU can open separate windows when it needs to show extra stuff (for example, the debugger or memory watcher)
- Bisqwit's tile tracker -- the engine used to make GIF animations. (A #define from source code needs to be changed to activate).
I don't fully understand what's going on with the code, it's somewhat involved. Also would be tricky to integrate it into the GUI. I would love to see this, but it's not a high priority and would be a lot of work.
- Bisqwit's dual game daemon support (Needs a separate program to work, and to be enabled from drivers/pc/sdl.c.)
I've already added this :) Background input can be enabled. You will be able to compose multi-game movies in the next version. Start planning your SMB1/2j/2/3 and Megaman 1/2/3/4/5/6 runs. :D
(actually I've already found this feature to be useful so you can frame-advance through 2 movies at the same time, making comparisions very easy)
- Disables debugger (not implemented for Linux anyway, makes emulation faster)
As far as I can tell, the debugger code doesn't run unless you're in debug mode. So your emulation should be just as fast as Bisqwit's. In any case many people make use of the debugger.
- Rockman 1&2 RAM analysis with frame display (displays X&Y position&speed and magnet beam positions)
- Magnet beam solidifier (a visual enhancement filter for Rockman 1, has to be manually disabled for all other games)
Game-specific. I don't really want to bloat FCEU with mods for every game. Someone else certainly could add it, though.
- Now actually says it's 0.98.15; Nitsuja's source code had still "0.98.13" somewhere
I've also made sure the version number is correct everywhere :)
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
Luke wrote:
I like the idea of displaying a controller to show the input. If it's not difficult I'll try to add that later, but don't expect it in the next release.
give me the specs (bits per pixel, resolution) and i'll give you the graphics for it ;)
Emulator Coder, Site Developer, Site Owner, Expert player
(3598)
Joined: 11/3/2004
Posts: 4738
Location: Tennessee
Another problem: the memory viewer really doesn't allow enough of text box for a good description of the ram address, I find my self running out of room even when abbreviating everything. Could the text space be doubled? I don't think it bloat the window size too much. If this is a pain in the ass then don't worry about it, but if it is an easy correction it would help a lot.
Also, could it be set up so that the tab button advances from one field to the next?
EDIT:
sorry for so many ideas but:
can the cheats menu in FCEU be set up so that it can stay open while playing the game? when finding ram addresses it is a real pain to have to open & close it so much.
Another problem: the memory viewer really doesn't allow enough of text box for a good description of the ram address, I find my self running out of room even when abbreviating everything. Could the text space be doubled? I don't think it bloat the window size too much. If this is a pain in the ass then don't worry about it, but if it is an easy correction it would help a lot.
Yup, easy fix.
Also, could it be set up so that the tab button advances from one field to the next?
The resource compiler in MinGW seems to eat the tab orders. (along with menu hotkeys) It annoys me too :/ I don't know how to fix it though...
can the cheats menu in FCEU be set up so that it can stay open while playing the game? when finding ram addresses it is a real pain to have to open & close it so much.
I looked into this, but the cheat menu isn't programmed to update in real-time; that's why it has to stop the emulator when you open it. Actually I just thought, a possible quick solution is to add an "update" button to it, so that you manually have to update the values.... hmm.
