use config > gui > use gdi+ display method and see if that helps. without gdi+ display method, its using direct3d. a lousy videocard/driver, combined with direct3d, combined with opengl, combined with video codecs, is really pressing your luck. we have a long term plan to replace the direct3d with opengl which should improve things a bit after a period of some pain.
nvidia is always recommended over ati, in all circumstances, in all eras.
I never suggested a freshened bizhawk directory would have any effect. Instead, I suggested that it didnt have anything to do with bizhawk. But it was a good idea, anyway, since I suppose it might have been affected by your choice of n64 video plugin. And another system is of course a great idea. Im dissapointed and sort of surprised that didnt fix it. Try using the uncompressed RGB avi codec, (if you can even get that far...?), which can help (but not authoritatively) eliminate a number of problems from consideration.
You probably have no problems recording on older game systems with AVI writer because theyre not booting up the 3d on your glitchy video card which is hosing your codec system. Also, sometimes glitchy codecs can be glitched by perfectly functioning videocards/drivers due to everyone trying to hardware accelerate video codecs, and in this case the added stress of 3d could be exercising the codec in a way its not accustomed to (most people are not doing 3d rendering on GPU while encoding)
I, as a developer, have offered finished and largely bugless (at least on par with other emulators) AVI-writing capabilities. If your system is malfunctioning, which I suspect it is, it isn't our fault. I'm trying to find a "valid" reason to have even an inkling of a suspicion that there is a flaw in bizhawk here, instead of in your system. Unfortunately, 100% of evidence suggests its your equipment's problem.
Why assume the issue has anything to do with XP? It worked fine for me on XP. We intend for support on XP. We dont knowingly do anything that wouldnt work on XP.
Clearly, if you have a fresh windows install with nothing else installed (except, presumably, a codec pack?) then theres nothing to uninstall except 2 things: the video driver and the codec pack. So, I suggest you try different/older codec packs, or better yet, none at all to positively rule that out. Also, different video card vendors might be called for. I doubt video card vendors give a crap about XP anymore, so theyre likely releasing massively bugged out stuff. Changing vendors would change bugs substantially.
Allow me to recap; I've been disorganized. Here's what works for me: bizhawk 1.5.1, mujura no kamen, windows XP, avi writer, RGB uncompressed
Thinking you have updated software doesnt mean your system can't be hosed. For example, even brand new ATI drivers are junk compared to years old nvidia drivers. Actually, new drivers from any vendor are more likely to be junkier than old drivers (new drivers do nothing but fix new games and break old things) so downgrading is always a smart choice as well. Additionally, virtually any other junk installed on your system can interfere with bizhawk, malfunction, and then interfere with the avi codecs.
About all we could do is attempt to dredge up additional information when that win32 operation fails, and print it for diagnostics.
Best bet for you is to use the ffmpeg writer, unless youre willing to uninstall things willy-nilly. If theres a bug with that and the OSD capturing, then lets fix that.
Sounds like a problem with your system that bizhawk isn't responsible for. It's crashing from the windows code which manages the video codecs. Likely other video-related things on your system are junked up and broken. Try reinstalling codec packs and video drivers. Can you dump avis from any other emulators?
In progress in SVN. Whether ieeee754 standard was used (on console X) depends on which console X you mean (but probably). If some other float format is employed, someone had better tell us.
Lua's memory.readfloat() etc. is completely unrelated to ramwatch/ramsearch.
The external input was part of a "shared memory" system which memory-mapped various features of the emulator for access by other processes. This was tightly associated with a "basic bot" framework which could receive specially formatted commands and turn them into input.
in r2130 (march 2011) the shared memory system was removed, due to it not being used, it being horribly crusty code, the emulator depending on it despite it being 'optional', it misbehaving in wine, and its having been obsoleted by lua. I have no explanation for why it's in the docs. It may predate fceux.
FCEUX doesnt offer anything like an API that lua uses for its external usage. FCEUX, as with most lua-containing emulators, exposes its internals straight to lua without any intermediate layer. This isn't an accident, and there are reasons it is smart.
Your evaluation of lua lacks context and correctness, as there are many editors for lua, and it isnt the gazillionth special-purpose-language, it is the predominant language for scripting emulators and game programs. If you try to do what youre doing any way other than with lua, then youre doing it differently from most other people.
Of course, I understand, theres reasons to prefer having other interfaces depending on what youre doing with it. However, FCEUX is architected too horribly to support anything like that. You might check out bizhawk instead which doesnt have an API as such but is architected to have sufficient modularity for such things, or retroarch which has enforced a somewhat generic interface on its core modules.
You could also try nintendulatorDX, which is more accurate than any of those other emulators, and now contains a lua interface. I havent checked it, but I doubt it is any better architected than FCEUX.
dotNetFx40_Full_setup.exe is the file that's in the prereqs package we distribute. It's actually the web installer. "For some reason" because the full version is 48MB and I havent heard anyone say the web installer functions in any different way.
Historically, our prereqs installer would mistakenly detect .net 4.5 as .net 4 and fail to install .net 4. If you were suffering from that, then installing "Microsoft .net framework 4.0 FULL" would have solved your problem for no other reason than it being the first time .net 4 was installed on your system. This was fixed in r4766 of bizhawk svn, any prereqs installer newer than 12-aug-2013 shouldnt have this problem.
1. the N64 is a 32-bit console
2. never expect a correlation between the power of the console and emulation performance. there are many other factors in play.
The only proper way to investigate this is to see which bsnes versions it happens in. We use bsnes v87 compatibility core. So, check bsnes v87 compatibility and accuracy core, and newer bsnes/higan versions to see when it got fixed. And keep in mind, we're unlikely to upgrade our bsnes core. There's a chance we could introduce the accuracy core as an option.
There is a fair chance that what he means is "this one zipped rom i have isnt working anymore, and the problem has something to do with the filename of the rom inside it, and also the only relation to recent roms is that its the only way i've tried opening this rom" which could be related to some of the MSU-1 path-finding support code we added
This seems to happen if you enable config > gui > single instance mode. Guess this feature isn't working properly. Disable it and the problem goes away.
Pokemon Red/Blue has a minor graphical error during the Name Entry screen. The End icon, is garbled. Other Pokemon games do not have this issue.
Bugs which are pretty clearly emulation errors in c++ cores we've imported from other projects should get addressed to the author of the original core, if youre able to determine whether this applies.
hegyak wrote:
Discohawk has issues with this CUE file. I think it may be the blank lines at the end of the file.
If Bizhawk crashes, then the save for the current game (games?) will be lost. Is it due to the data stream not being flushed? Though, I wouldn't even know how to detect "Game is saving"
I think there are two different revisions of the FDS bios? The one I built and tested the FDS mapper core against is 57fe1bdee955bb48d357e463ccbf129496930b62; offhand, I don't know where the other one is from. I will look into it.
There are two FDS bios versions. One is from the actual FDS, and the other is from the Twin Famicom, which has a little bit of tweaked out graphics but shouldnt function any differently. See here for details http://tcrf.net/Family_Computer_Disk_System . As of r4837 they'll both be detected.
The other "ROM" I am having trouble locating is the Super Gameboy for SNES (SGB.sfc)
I also have several, and none of them are the same as yours. This is why you have the ability to set whichever file you want to satisfy the firmware. We've only validated the behaviour of the SGB with one firmware version, and thats the version in the firmware manager subsystem. FWIW, I have that labeled as "Super Game Boy (World) (Rev B)". If you've validated another super gameboy as working fine with it and want us to add it as an acceptable alternative, as long as you're sure it's an unmodified actual rom that exists in the world (good* isnt always accurate) then propose it. But I suspect one of our sources is largely junk. We should probably check to see whether the OCD higan community has a recommendation.
BizHawk 1.5.0 doesn't recognize my disksys.rom even though it's in the Firmware folder. When I right click the FDS Bios in the Firmware dialog, click Set Customization, and double-click my disksys.rom, an error message appears:
diagnostics steps
1. reboot
2. run the prerequisites installer
3. reboot again. cos you never know.
4. say whether C:\windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll exists
5. run bizhawk from a folder on your desktop
6. disable your security software
7. look for folders in the bizhawk dlls subdirectory which have an unblock option from the windows file > properties dialog, and unblock them
8. dearchive it with winrar instead of whatever you used
discohawk's purpose is to convert a diversity of weirdly formatted discs to something (normalized cue+bin) which can be consumed readily by bizhawk, not to mention other emulators. However, presently, it only supports cue and iso. We would love to support other formats, but there are other priorities and it is not easy to find documentation for many formats.
The only way to get an unfair _tasing_ advantage is if the number of cpu cycles in a frame changes, which is never the case, or else 95% of NES games would instantly break. The number of cpu cycles in a frame is constant in FCEUX. Whether a frame is displayed on your monitor for 1/60 of a second or 1/60.1 of a second is not constant.
Whether you sync to audio or video or the clock isnt relevant to tasing. Whether you run at 60fps or 100fps or 5fps in slow-mo mode isnt relevant.
Of course, any time youre in slow motion you have an unfair _gaming_ advantage.
not that im promising anything, but you can increase the odds of this happening by nominating yourself Power User Advocate Just In Case and parking yourself in #bizhawk to advocate for it when the situation arises and provide confidence that a dreamcast power user is nearby to supply information and situational awareness.
someone with this problem needs to do some debugging on irc with us. I would like to try hooking up the assembly resolver in an exception handler, looking for anything interesting in the windows event viewer, running fuslogvw, running dependency walker.