Tried to record an AVI of Zelda no Densetsu: Mujura no Kamen (J 1.00) via AVI Writer.
http://pastie.org/pastes/8345136/text?key=aqqdqrrxkb5cyzxt6xria
Additionally, if I choose to continue, the BizHawk window will be completely unresponsive, except to "joystick" input. I cannot even right-click BizHawk's button in the taskbar to close it down. System: Windows XP SP3 (x86).
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?
My video card drivers are up-to-date. I use K-Lite Codec Pack for codecs, if that helps narrowing it down? My installation of K-Lite may be a few months old now though (but not older than a year at least). I can record AVIs via "regular" Mupen 64 perfectly fine, and have never had problems before either.
By the way, when I try recording with ffmpeg instead and I have a Lua script with some gui.text() lines, to print some "OSD" text, I just get a black screen in the final video file... If I remove the gui.text() lines from the script the video comes out properly, and for a second I thought it even solved the AVI Writer issue, but the error message came back after I retried it yet again a few minutes later (and this time I didn't even have the interface for Lua open).
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.
I tried a fresh "unpack" of BizHawk on another computer (fresh XP SP3 x86 installation by the way), same ROM, no default settings of BizHawk changed. I get the exact same error... And I don't have anything other than BizHawk and its dependencies installed apart from the aforementioned (very) newly installed system itself, so there's no "junk". I have to ask, did you even try to reproduce it yourself? Because I have no problems recording NES, SNES, Genesis or other older game systems with AVI Writer.
Well anyway, I don't mind using ffmpeg.. in fact, it probably is a better encoder anyway. But I feel that you, as a developer, should want to fix bugs, or at least not even offer any buggy, or even worse, "unfinished" functionalities. It's great if you're willing to fix the ffmpeg black screen issue, but it feels like you're trying to find a "valid" reason not to do anything about the AVI Writer. You know.. this it typical of software developers, too; always blaming the users of being too "n00b" to do some standard troubleshooting, or a little research when they submit bug reports. I have tried older drivers, too, and I don't notice any difference (i.e. it doesn't fix the AVI Writer issue).
Out of curiosity, what would you want me to uninstall in that case.. ? I don't mind uninstalling things - I'm quite capable of restoring my software configurations if I have to re-install it. So just tell me, and I'll try it, but I doubt it'll help since it doesn't even work on a fresh installation of the system... Maybe you guys just don't intend for support on XP?
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
Indeed. But a clean setup may help sometimes with some apps, so I figured I'd try...
You know, I sort of thought of this at one point, don't know why I didn't try it yet. Until now I've used Glide64mk2. I'll get back to the thread once I've tried the others.
It unfortunately does not get that far. The error appears when I click the "OK" button on the dialogue where you choose which writer to use.
Hmm. Why do you say glitchy? I mean, is this something you know for a fact? I haven't noticed anything that would suggest the graphics card is damaged, but then.. I haven't run any actual tests in a while. I'll say this though: when I insert this particular graphics card (ATI Radeon HD4850 by the way) into the motherboard, I have to press it kinda hard to be able to properly screw the bracket into the computer case. I don't know if's an "incompatibility" with the case, or the motherboard, but I did recently get a new computer case, and it was as bad with this as the previous case, so that probably rules out the computer case being the problem for that. I can't say I remember it being as difficult with any previous graphics cards I've had...
I just assumed most people was dropping support for Windows XP "because it's 11 years old, blahblah..." I still say XP is superior to the cherished Windows 7 though, no matter how many "bugfixes" (or much less important to me, new implementations) it supposedly has. It's good to know you guys are still supporting XP.
Yes, that and chipset drivers. I never actually installed any graphics card drivers at all on that system actually, so that I can't uninstall. Uninstalling the codec pack won't help, because I actually already tried before installing it.
Do you recommend any particular codec pack by the way? And are you saying, what I think you are; that nVidia is recommended over ATI? Or older graphics cards in general even.. ? Because I'm seriously noticing a drastic fall in hardware quality these days (monitors are a nightmare for example).
I'm back!
Switching plugins didn't really work. However... for WHATEVER reason, enabling all the OSD settings under "view" (i.e. "display FPS" etc.), disabling "display status bar" and then rebooting the BizHawk core "solves" it. I'm not sure why, but maybe this info helps somehow? I've reproduced it without errors by doing this at least three times now (and actually reversing these settings every other time to check if it throws an exception again).
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 should mention, if you havent installed any video drivers at all, then youre either operating in a configuration that the codec suppliers probably havent tested, or youre using a default video driver which is as likely to have bugs with the codecs as any other driver. Perhaps on configurations where you havent installed video drivers, software opengl is getting used by the mupen core and thats hosing your codecs in a way i havent ever even tested. You'd know because mupen should be going about 1fps.
Possibly youre using a 16bpp or 24bpp desktop color depth? That's getting hard to support or test anymore.
bizhawk doesnt depend on any services or anything strange that the prerequisite installer doesnt install. windows codec subsystem is crashing, not bizhawk.
its strange that both your test systems have the same cpu. do they have the same motherboard and gpu as well? since some combination of hardware and drivers is likely causing your problem, testing two very nearly identical systems isnt the most valuable of tests.
I got it working. I had to install the DirectX 9.0c SDK (http://www.filehippo.com/download_directx/7692/). So screw that web installer, throw the SDK in the prerequisites archive instead. ;)
EDIT: it's back... kinda. But now it's at least resolvable - until the next time I reboot the core. It comes back if I cancel the compression codec window (i.e. test for exception errors) and reboot the core. I notice in the Temp directory, that there are files being created even though no actual file has started recording. Are you making proper use of file handles?
(Otherwise it's pretty much indeed solved.)
You should notice also that the file disappears when the codec selection process is done.
I'll be glad to debug a different stacktrace, if youve discovered the directx SDK can un-scramble your drivers. If you get the same stacktrace now with your new repro steps, then all youve done is paper over the real problem somehow by jiggling your files around a bit.
We shouldnt be depending on anything in the SDK. Maybe for some reason directx web update is malfunctioning on your system(s) but thats usually very reliable
Emulator Coder, Site Developer, Site Owner, Expert player
(3574)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
BizHawk 1.5.2 Released!
The big change in this release is completely redone Ram Search, Ram Watch, and Cheats tools. With the demands of N64 TASing, I had to add more support for things like float and fixed point, and tighten up ram usage and performance.
Another fun feature is the ability to load games on the ti-83 core.
As usual, I recommend reading the
full release notes.
Windows binary
Oh, wow! This new release is a huge improvement in performance on my machine. Max throttle speed in GBCHawk went from 77 fps in 1.5.1 to 400 fps in this! Thanks, BizHawk team!
What's the correct hash and filename for the TI-83 BIOS? Neither the hash nor accepted filename is listed in BIOS_Info.txt, and I've tried setting several different ROMs manually with Set Customization but haven't found anything that's worked.
Those hashes are weird. I'm not sure what they are. Theyre supposed to be typed.
I just made edits to add a info (details) view to the firmware options dialog so you can see which files the firmware manager is expecting and what their hashes are. This will make it easier to solve this problem in the future.