I think I came across something that prevents using this patch to do VS Unisystem runs - the emulator doesn't seem to record coin insertions. I did a practice run without rerecords through VS SMB, and when I played back the movie, it would not leave the attract mode. I should think that it would be a good idea to somehow retain the DIP switch settings as well.
I think I came across something that prevents using this patch to do VS Unisystem runs - the emulator doesn't seem to record coin insertions. I did a practice run without rerecords through VS SMB, and when I played back the movie, it would not leave the attract mode. I should think that it would be a good idea to somehow retain the DIP switch settings as well.
This is strange, because the movie file format clearly supports those events.
I think I came across something that prevents using this patch to do VS Unisystem runs - the emulator doesn't seem to record coin insertions. I did a practice run without rerecords through VS SMB, and when I played back the movie, it would not leave the attract mode. I should think that it would be a good idea to somehow retain the DIP switch settings as well.
This is strange, because the movie file format clearly supports those events.
Well, I just brought up DIP switches in case they weren't supported, I don't know if they actually are or not (I didn't even modify them for this practice run). I uploaded the recording to http://ssonicnet.com/localhmc/localh-vssmb-bullshit.fcm, so you can look at it if you want. I know for a fact the coin insertion didn't work, as I wouldn't have recorded the length I did if I hadn't actually inserted the coin. This movie uses no rerecording and only slowdown.
Cheers, im trying to compile this mother on OS X 10.3.7..
To be short i followed Bisqwit's instruction on compiling it for linux/unix, that is dl:ing the blip source, dos2unix it, apply bisqwits patch, running configure and automake then make:ing it.
All goes well until i bump into sdl-sound.c, here's the dump:
drivers/pc/sdl-sound.c:342: error: conflicting types for `KillSound'
drivers/pc/dface.h:20: error: previous declaration of `KillSound'
drivers/pc/sdl-sound.c: In function `KillSound':
drivers/pc/sdl-sound.c:348: warning: passing arg 1 of `free' discards qualifiers from pointer target type
make[1]: *** [drivers/pc/sdl-sound.o] Error 1
make: *** [all-recursive] Error 1
I have SDL 1.2.8 installed, running on GCC 3.3 in a bash 2.05b environment..
any help on this would be appreciated
Since it has been long time FCEU wasn't updated and contains several bugs/misfeatures, it would be nice if someone could update it and also using the latest source, 0.98.13, that some bugs are now fixed or may use that version, http://cah4e3.deruspsx.com/fceultra.html .
Changes from 0.98.12 to 0.98.13 :
* Fixed button configuration when using joystick hats
* Readded checks in ines.c for some common bad dumps and non-working hacked games
* Sprite hit emulation is more precise
* Fixed mapper 185 emulation to work properly with the Japanese version of "Spy vs Spy", and hopefully with the GOOD dump of Banana
* Added per-game hacks for Shougi Meikan '92 and Shougi Meikan '93
* Fixed a bug in SetupCartMirroring() that could cause some games to have corrupted mirroring if loaded in a certain order
* Added many iNES header corrections
* Fixed emulation of the "ISB" and "DCP" invalid opcodes
* Optimized the PPU background drawing code with inline assembly
* Optimized some of the low-quality sound emulation code
* Added a command-line option to the configure script to enable the FCE Ultra debugger(disabled by default)
* In unix-netplay.c, replaced the ioctl() on a socket to read the number of bytes available to read with a select()
* Replaced archaic include of "malloc.h" in unix-netplay.c with "stdlib.h"
* Fixed a bug in sdl-sound.c that would prevent FCE Ultra from being compiled on certain platforms (Mac OS X)
* Fixed variable declarations in some files to be compatible with C compilers that don't adhere to C99
Is there a "allow left+right/up+down" option anywhere? I know someone, I think it was you, made a patch that allows it, but I think it should be an option for everyone. Then we won't have to hunt down patches.
put yourself in my rocketpack if that poochie is one outrageous dude
yes, it can be added though, it's Bisqwit who told me what code to change.
lfe wrote:
Cheers, im trying to compile this mother on OS X 10.3.7..
To be short i followed Bisqwit's instruction on compiling it for linux/unix, that is dl:ing the blip source, dos2unix it, apply bisqwits patch, running configure and automake then make:ing it.
All goes well until i bump into sdl-sound.c, here's the dump:
drivers/pc/sdl-sound.c:342: error: conflicting types for `KillSound'
drivers/pc/dface.h:20: error: previous declaration of `KillSound'
drivers/pc/sdl-sound.c: In function `KillSound':
drivers/pc/sdl-sound.c:348: warning: passing arg 1 of `free' discards qualifiers from pointer target type
make[1]: *** [drivers/pc/sdl-sound.o] Error 1
make: *** [all-recursive] Error 1
I have SDL 1.2.8 installed, running on GCC 3.3 in a bash 2.05b environment..
any help on this would be appreciated
* Fixed a bug in sdl-sound.c that would prevent FCE Ultra from being compiled on certain platforms (Mac OS X)
So, you'll be able to compile it under MAC OS X.
FCEU sometimes changed a valid savestate to another savestate that reset the game.
THAT SUCKS.
But we haven't managed to find what was the real reason of this bug.
We= Me and Genisto because this bug occurs more often on Genisto's machine than mine.
My level was almost done and now, I must redo a whole part.
I do have proof that this bug exist since it happens once when doing my Battletoads run and I have done backup of those files.
This is a MAJOR bug.
Too many bugs in this emu, all my projects are paused.
It's not easy doing a 2 player run and even harder when the emu is unstable.
I hit that bug once while doing Cocoron. I was able to recover it though...I can't remember if I rerecorded from earlier in the movie or hex-edited a keypress out. I thought it was just my fat fingers hitting the reset key by accident.
OK, I finally got around to giving this a try.
I couldn't make all the changes Phil suggested, but here are the changes I made:
-Fixed bug causing playback desyncs and differences between Blip's and Phil's Patched FCEU
(I think this should also fix the "FCEU sometimes changes a valid savestate to another savestate that resets the game" bug, but I've never seen that bug happen, so I'm not sure)
-Fixed bug preventing the auto-fire keys from working
-Integrated all changes/fixes of FCEU version 0.98.13
-Integrated all mapper and board additions and fixes of the fceu-mm project
-Incorporated a much better default palette
-Added Record from Start (power-on + wram clear) as default recording option (and previous versions can still play it)
-Added "Input Display" (activated by a hotkey, like the frame counter)
-Added "Toggle Read-Only" hotkey for switching movie playback/recording without reloading
-Made frame advance repeat after a delay if you hold it down
-Made frame advance pause the game if pressed while it's unpaused
-Made loading a save state show its graphics immediately even if paused
-Fixed bug that allowed key-up events to activate hotkeys when 2 hotkeys had different modifiers
-Stopped emulator from using 100% CPU power when left paused in the background for a while
-Added a warning to help catch if a save state becomes corrupted
-Prevented exiting movie play dialog while movie browse window is still open
-Worked around bug in DirectInput that prevented the Pause/Break key from working as a hotkey
-Changed the default key setup (it's still configurable and your old settings won't be erased)
Compatibility with version 0.98.12(blip) is maintained in almost all cases, which means that each version can play movies made in the other version (so you can watch previous movies with input display on, for example, and the process of verifying movies made with this should not change).
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
wow very nice job nitsuja, but i think that palette is very different from the real nes, at least battletoads-wise. good job though, i got a new fceu :) thanks!
wow very nice job nitsuja, but i think that palette is very different from the real nes, at least battletoads-wise.
Hmm, well I checked against actual video captures of Mario 1, 2, 3, and Cybernoid to make sure the relative brightnesses and hues of the colors match up. But, there is no way to get a truly accurate palette for the NES because it doesn't even output RGB and displays will vary, so there isn't really 1 most accurate appearance. You can always load whatever palette you prefer to override the default, anyway.
edit: I see what you mean, though. You must be talking about the bright red/pink "brain" rooms. That color is off, I'll try to fix it with some values from another palette. This is from BMF's palettes, btw. ASQ's palettes had major problems such as the color for "black" being very bright (to simulate how crappy the TV is or something, which probably shouldn't show up in the emulator).
I've tested things that you said that were fixed and edited the first post. There's still some work to do ;) But I am happy with that new release. Nice job.
FODA: I fixed that region of the palette to be better - Battletoads doesn't look so weird now, and it made the red color for Mario look better as well.
Phil wrote:
FCEU sometimes change a valid savestate to another savestate that reset the game. This bug rarely happens, but when it happens ... :@
Does this bug still happen? I have never seen it but it might be fixed.
Phil wrote:
When playing a movie that can be played with an emulation that uses a mouse, ex. Arkanoid paddle, it just doesn't desactivate it, you can play while playing a movie. I have converted Genisto's Arkanoid movie by using Bisqwit's Nesmock, FMV to FCM, Arkanoid paddle emulation activated, this bug occurs. Evidently, all input must be desactivated when playing a movie.
Before or when playing a movie, if you select a device, config>input, other than gamepad, the video doesn't go well.
I think this bug is fixed. I haven't tested it, but these inputs should be disabled now on playback unless I missed something.
Phil wrote:
-Fix timing problem with SMB3 PRG1.
I've never heard of this... is it explained somewhere? (If you mean the desync problems Genisto was having with SMB3, I think this is now fixed. The desync at the airship unfortunately already got into his movie so he'd have to fix that manually. Also, the regular left+right version will desync on that movie where it shouldn't, because it doesn't have that bug fixed.)
Another bug that could be on the list: Gimmick (J) sound problems when you pause the game or die, this still happens. EDIT: No, actually it only happens if you have the sound set to "Low Quality". The sound in that game is fine if you choose the more-accurate "Highest Quality" sound option.
This is from BMF's palettes, btw. ASQ's palettes had major problems such as the color for "black" being very bright (to simulate how crappy the TV is or something, which probably shouldn't show up in the emulator).
I recall from the discussion that the black was mandated to be a bit lighter by Nintendo so that it wouldn't damage the TV screen, so it may as well be the same in the emulator to be authentic.
And why not leave the default palette the way it is and offer .pal files in some other topic?
put yourself in my rocketpack if that poochie is one outrageous dude
FCEU sometimes change a valid savestate to another savestate that reset the game. This bug rarely happens, but when it happens ... :@
Does this bug still happen? I have never seen it but it might be fixed.
I don't know what's causing this so I don't know how to repiclate it. It's just randomly happens.
nitsuja wrote:
Phil wrote:
When playing a movie that can be played with an emulation that uses a mouse, ex. Arkanoid paddle, it just doesn't desactivate it, you can play while playing a movie. I have converted Genisto's Arkanoid movie by using Bisqwit's Nesmock, FMV to FCM, Arkanoid paddle emulation activated, this bug occurs. Evidently, all input must be desactivated when playing a movie.
Before or when playing a movie, if you select a device, config>input, other than gamepad, the video doesn't go well.
I think this bug is fixed. I haven't tested it, but these inputs should be disabled now on playback unless I missed something.
I haven't tested that.
nitsuja wrote:
Phil wrote:
-Fix timing problem with SMB3 PRG1.
I've never heard of this... is it explained somewhere? (If you mean the desync problems Genisto was having with SMB3, I think this is now fixed. The desync at the airship unfortunately already got into his movie so he'd have to fix that manually. Also, the regular left+right version will desync on that movie where it shouldn't, because it doesn't have that bug fixed.)
Well, it isn't supposed to desync at tank(not airship) at all. The movie is played back fine sometimes not. That's not the movie's fault but FCEU. And this random emulation still occurs in your version.
Well, it isn't supposed to desync at tank(not airship) at all. The movie is played back fine sometimes not. That's not the movie's fault but FCEU. And this random emulation still occurs in your version.
Could you explain? This isn't helpful information at all. It always plays back exactly the same for me, which is the same as the non-left+right patched version plays it.
Bag of Magic Food wrote:
I recall from the discussion that the black was mandated to be a bit lighter by Nintendo so that it wouldn't damage the TV screen, so it may as well be the same in the emulator to be authentic.
I know it's lighter. I don't have it at 100% black either, but that palette was still too bright for the black, and also didn't take into account that some of the other black colors are supposed to be slightly different from each other.
Bag of Magic Food wrote:
And why not leave the default palette the way it is and offer .pal files in some other topic?
Because the way it was before was extremely inaccurate by any standards, fairly arbitrarily chosen (and not very consistent) RGB values that nobody bothered to look at changing for a long time. And, many people agree that BMF's palette is a quite accurate, and I don't see how it can be any worse a default than the previous one. I seem to recall there being complaints about how bad the FCEU palette was, as well.
Are you doing anything different when Mario gets past there? (You mean the airship, right?) Like, do you play the movie twice in a row and the first time it doesn't work, and the second time it does? I tried to get it to work past that point, but looking at the input, he just presses the jump button way too late to survive getting auto-scrolled to death, so I can't tell what's happening that shouldn't be.
(Also, this is news to me that anyone has managed to play it past that point. I thought nobody was able to get it to work.)
No, it's the first tank stage. And that's not related of playing the movie twice. Sometimes, close the emu, open the rom and the movie is desyncing and just redo the same step and the movie is playing fine.
An AVI is coming soon.
nitsuja wrote:
Phil wrote:
When playing a movie that can be played with an emulation that uses a mouse, ex. Arkanoid paddle, it just doesn't desactivate it, you can play while playing a movie. I have converted Genisto's Arkanoid movie by using Bisqwit's Nesmock, FMV to FCM, Arkanoid paddle emulation activated, this bug occurs. Evidently, all input must be desactivated when playing a movie.
Before or when playing a movie, if you select a device, config>input, other than gamepad, the video doesn't go well.
I think this bug is fixed. I haven't tested it, but these inputs should be disabled now on playback unless I missed something.
I've just tested it with Arkanoid. It's true that it is desactivated but gamepad arrow keys as well. Only select, start, A and B button seems functional.
