Posts for arkazal


Experienced Forum User
Joined: 4/17/2017
Posts: 25
Not sure if this has been posted about, but starting from 2.4.1 and on, Bizhawk does not accept Down and Right inputs from my SNES controller when remapping controls. I've confirmed it does accept these directions in 2.4.0. If there's some way to let you know what my USB adapter is, let me know. It's a very simple one-port adapter and I'm using a Super Famicom controller. I tried to find it on Amazon, but I'm unable to. EDIT: Actually, it's a little more serious than that: these two versions of the emulator flat-out do not respond to these two directions in any way, even if the directions are manually remapped by copying the mapping configuration from the 2.4.0 config file; even in-game, they do not work.
Post subject: Import previous config
Experienced Forum User
Joined: 4/17/2017
Posts: 25
Is there really no way to do this? I want to update to the newest Bizhawk, but... reconfigure the controls, profiles and everything else for every single core I used? Seriously? Along with all the other options I had ticked for Bizhawk in general. I tried using the Load Config option, but I just get an error. Come on, there has to be some way to avoid redoing everything...
Experienced Forum User
Joined: 4/17/2017
Posts: 25
Something interesting I found recently. https://archive.org/details/610-6861_The_House_of_the_Dead_Taikenban_JPN The specs of the video on that page list 29.91fps. It's the same frame rate I came up with for N64 according to my friend's capture card, and also the same frame rate for the Saturn as a test a few days ago revealed. I think it's a little coincidental that I'm getting the same frame rate as somebody else if there's nothing to it. You can also do a Google search for sega saturn 29.91 and find several of those videos. Is it a positive fact that the N64 itself runs at 60000/1001? I'm not talking about emulators, I'm talking about actual hardware. And isn't the actual hardware what the numbers on the frame rates page are supposed to reflect? Why would we put in any other numbers? They would be arbitrary. Sorry if I'm being a pest, but I'm still not totally satisfied with the responses I got, as they gave me virtually no information as to how those numbers are known and why they aren't reflected on the frame rates page and in the emulators themselves if they are known. Just to point this out: if we connect an NES or an SNES to the capture card, AmarecTV has 30.04 in the Cap[] box without us setting the program's frame rate to record at 30.04. That's because it's reporting the signal it's actually receiving. So, it really seems like N64, and now Saturn too, are 29.91. EDIT: Looks like I'm not the first one to find this out (and it doesn't surprise me). https://www.videogameperfection.com/forums/topic/nintendo-64-de-blur/page/2/#post-12488 Read that post and the following few posts. If you double my value of 29.91 (because we're dealing with interlaced signal), you get 59.82, which is exactly what they're getting. Well, there are more decimal places, but yeah. Actually, on the subject of the decimal places, the number I got was 29.9148552, which multiplied by 2 is 59.8297104. The number given in that thread is 59.8261054. It's a difference of 0.003605. It's extremely close. I'm actually pretty proud of that calculation now, given I did it manually. Here's another post with 59.82: https://shmups.system11.org/viewtopic.php?f=6&t=51622 blizzz's post, who happens to be a regular at SDA. The more I search, the more I find the numbers my friend's capture card is giving us. I know it can be a bunch of people all mislead with the same false information, but the more times I find this number, the more I believe it's not. EDIT2: The thread at videogameperfection.com goes on to question the exactitude of the numbers used to calculate the frame rate, but the frame rate can, at the very least, be used as a ballpark figure. Any device you put an N64 signal into will not give you 29.97, it will give you 29.91. I don't think 29.97, or 59.94, is accurate.
Experienced Forum User
Joined: 4/17/2017
Posts: 25
Wait, what does it have to do with emulators? Aren't these frame rates the frame rates of the actual consoles? I'm really lost now. https://forum.speeddemosarchive.com/post/important_analog_capture_frame_rates_and_mysterious_gained_seconds.html I don't think that thread is talking about emulators, since SDA is against using them. I'm pretty sure they're talking about the real NES/SNES hardware having a frame rate of 60.0988. That thread is giving information about what will happen if you record a real NES/SNES console at 59.94 FPS. So what does it have to do with different emulators? I'm interested in knowing the frame rate of an actual N64 (among other consoles).
Experienced Forum User
Joined: 4/17/2017
Posts: 25
Then why hasn't that page been updated? And why the strange and matching behavior from both of these programs?
Post subject: Console frame rates
Experienced Forum User
Joined: 4/17/2017
Posts: 25
Sorry if this isn't a Bizhawk question but I really don't know where to put it. My friend recently got a Micomsoft SC-512N1-L capture card. It's quite a high quality capture card, PCIe and has a passthrough built in so you don't need an amplifier. When recording retro consoles, it's always good to be able to record at the actual framerate (the ones found on this page) so the video plays at the correct speed. While testing out different programs to record with, we noticed something interesting occur in two different programs, VirtualDub and AmarecTV. We used VirtualDub first, for a while, so I'll describe its behavior. When VirtualDub was told to record at an FPS that was not the same as the one the console ran at, it had a resample rate on the right-hand column where the recording information goes that was quite a bit more or less than x1.00000 depending on if the framerate was to high or to low. When 30.0494 was put in for NES/SNES, for example, the resample rate was almost exactly x1.00000 the entire time (it's never exactly, but almost). However, when we recorded at 29.9700 for N64, VirtualDub consistently reported a resample rate of x0.99816 on the video speed. That means it needed to go that much slower. I pulled out Windows calculator and did some quick math, and 29.97*0.99816=29.9148552. Here's where it gets interesting: when using AmarecTV, framerates are displayed a little differently, and the framerate you have chosen to record at is not what the program displays; rather, it displays the rate it is (presumably) actually running at. It displays this even when you're not recording, unlike VirtualDub. Here's what AmarecTV displays despite having the framerate set to 29.97 in the program: Pretty much what I manually calculated from another program. I only wish I could see more decimal places out (it unfortunately doesn't show more than 2). What I'm getting at is that the framerate page does not list an exact value for the N64's framerate, and I've always personally wondered what it is, and for this very specific purpose. It's nice to be able to capture games at their real framerate, so the speed of the video is correct, especially for speedrunning. Is it possible that this capture card is at least within some accuracy of the N64's real framerate? Or is that just wishful thinking? :P
Experienced Forum User
Joined: 4/17/2017
Posts: 25
Been a little while since a new release... I'm hopeful for an N64 core update :) Are there any N64 emulators still in development, anyway? It seems like N64 gets the least amount of love v__v
Experienced Forum User
Joined: 4/17/2017
Posts: 25
feos wrote:
so we could in future update the core on a whim.
:O N64 emulation is still in development? I thought it was pretty dead. I would love to see better N64 emulation one day, but I know it's a very pesky console to emulate. But even getting the most recent core into Bizhawk would be something :)
Experienced Forum User
Joined: 4/17/2017
Posts: 25
Any plans on updating the N64 core to the latest?
Experienced Forum User
Joined: 4/17/2017
Posts: 25
Hey, I know you posted this almost a month ago, but I just now saw it and I think I know the answer because I also had problems with analog control in Bizhawk. I scoured the internet looking for a solution and finally found one on some sort of Github or something. I'm pretty sure the problem is that you have the "P1 A" controls mapped. It's the first four. Oddly enough, while those say "A" as if they are analog, they are in fact digital. You need to delete those settings. I think that should solve your problem (and hopefully anyone else stumbling upon this thread). As for the reversed axis problem, there is a button for each axis that says "Flip Axis". Since you said up and down were reversed, you need to click Flip Axis for the y axis, since that's the vertical axis.
Experienced Forum User
Joined: 4/17/2017
Posts: 25
smellyfeetyouhave wrote:
ruadath wrote:
In the next release of BizHawk, can we update the mGBA core to 0.6.2?
The version in the latest dev builds (and I think 2.2.2 stable?) is https://github.com/mgba-emu/mgba/commit/633449dfd4dcb9e70646cccf217cea3d4f The only commit that actually affects GBA emulation since then is 633449d and that commit has actually been reverted as of yesterday so 0.6.2 stable would actually introduce a single reversion and that's it.
Wow... all that work I did talking about that too. He reverted the single change that didn't make the audio sound like it was coming out of a tin can and made all the bass notes higher and...? I officially give up on that emulator then.
Experienced Forum User
Joined: 4/17/2017
Posts: 25
I'd be interested in seeing this. Like others have brought up, how accurate would it be given the lag situation? I know, a silly question (accuracy) when it comes to N64, but some games actually do console verify. I can't see this game doing that though, given that it polls for input during lag. Somebody please educate me if I'm wrong though (and in the case of this game I'd love to be :D ).
Experienced Forum User
Joined: 4/17/2017
Posts: 25
Yeah, I suppose I'll go back to VBA-next, I'm just disappointed because it seems like it's not in development anymore, and there are things I like about mGBA. The bizarre audio issues are a tough hurdle to leap though. Audio in VBA-next sounds identical to when I play on real hardware, so... =/ EDIT: Interesting... Looks like someone reported the same problem I was having after I did, but much more eloquently. It was closed because the user reported not to be having problems, but it is still absolutely a problem. I've commented there as well.
Experienced Forum User
Joined: 4/17/2017
Posts: 25
For what good it will do, I updated my issue, but audio seems to be a low priority so it doesn't look like it will get much attention =/ Shame because mGBA seems like an accurate emulator in some ways, but the sound is so inaccurate in the games I'm playing that I literally can't play them, it's completely jarring from the experience.
Experienced Forum User
Joined: 4/17/2017
Posts: 25
andypanther wrote:
As far as I know, Bizhawk uses Mupen64 Plus 2.0.
Wow, seriously? v2.5 is like... 3 years old, isn't it?
Experienced Forum User
Joined: 4/17/2017
Posts: 25
Thanks, I've reported the issue. Probably not a very good report, but hopefully it will help. MUGG, thanks for the feedback about emulator accuracy. It sounds like mGBA is written with total accuracy in mind, and I'm not sure how much (if at all) VBA is developed these days, so I'll probably want to use mGBA in the future. That leads me to a question that will probably just annoy people, but... is there any realistic guess as to when the new release of Bizhawk will be released? I'd like to use mGBA in conjunction with Bizhawk's features. The "likely" release date for the 0.6.1 core update passed something like a week and a half ago though.
Experienced Forum User
Joined: 4/17/2017
Posts: 25
Hey, thanks for the post, Alyosha. I tried it in 0.6.1, but it's the same sound. It's particularly bad in Magical Houshin, but even other games sound slightly... fuzzy compared to VBA-next. I don't know what endrift's issue tracker is though. I just saw this thread about mGBA and thought I would post what I know. Can anyone answer the rather vague question of how much more accurate mGBA is over VBA-next? I'm currently a bit confused as to why I would choose one over the other. Currently, I've liked VBA-next a little more than mGBA, but it's mostly been for sound, and in Bizhawk, mGBA is the default core. Is this just because it's alphabetically first? Or is there an accuracy reason?
Experienced Forum User
Joined: 4/17/2017
Posts: 25
Hey there. I'm recently getting into GBA emulation and have been playing a bunch of games on both emulators Bizhawk supports to try them out. One such game I've played is Magical Houshin. The first time I played it, I was appalled at how bad the music was. Then I switched to VBA-next and realized that the music sounds really good :| But other games don't sound like total ass in mGBA, so I think it's just that game. I don't know how that's possible, but then, I'm a total dummy when it comes to any of this stuff. Is there any possible way you can look into that? EDIT: Also, I've noticed that SaveRAM files are 128kb when created by mGBA and only 64kb when created by VBA-next, at least for the games I've played. For a couple games I played, I looked at the save files in hex editors, and all mGBA seems to do is add another 64kb of zeroes to the file, which in some of the games I played wasn't even how blank data was stored (those games used FF), so it seems really... odd. Any reason this happens? It doesn't seem to belong there.
Experienced Forum User
Joined: 4/17/2017
Posts: 25
Ah, that's a good page. Thanks. Works like a charm now :D
Post subject: BizHawk open command
Experienced Forum User
Joined: 4/17/2017
Posts: 25
With emulators like FCEUX and SNES9x, I was able to write an AutoHotKey script that creates an EXE that runs a game just by double clicking it. The script runs the emulator (.exe file), then adds the -o command to open the ROM inside the emulator. The result is that the game starts instantly. I even give it a nifty icon :D But with BizHawk, the -o command doesn't seem to be working. I'm using the same script template, so I don't think I'm doing anything wrong. Does BizHawk use a command besides -o or am I going to have to look through my code again? I'm really hoping that's not the case, because the code is 1 line... XD
Experienced Forum User
Joined: 4/17/2017
Posts: 25
Right, I see. It's as I thought. If I compared recordings between Bizhawk and a real PSX I bet I'd be impressed by the similarity. Thank you :D
Post subject: PSX load times
Experienced Forum User
Joined: 4/17/2017
Posts: 25
TAS-capable emulators have a heavy emphasis on accuracy, which I love. We have emulators that are so accurate for consoles like NES and SNES that we can create something like TASBot and play input done on emulator back onto a console and it works! What about PSX though? For older consoles, the load times are obviously identical; if they were off by even one frame anywhere, the movies would desync. But a PSX uses a laser to load from a disc, and the laser has to move. Does Bizhawk somehow emulate even that correctly, or is that a silly question and there's no way to do that? I guess my question is "could there ever be a TASBot for PSX?" but my curiosity is not so much geared toward TASBot (though I find it interesting), but just accuracy in general.
Post subject: Questions about Profiles in Bizhawk, and about TASBot
Experienced Forum User
Joined: 4/17/2017
Posts: 25
I've been using TAS emulators for a long time, and while I don't really TAS, I love what you guys do and I am both entertained and fascinated by some aspects of it. First, how much do the Profiles in Bizhawk really affect? These are the options "Casual Gaming", "Tool-assisted Speedruns", "N64 Tool-assisted Speedruns", and "Longplays". A quick blurb is given about each one, but how much will it really affect? Say I want to do a 4 hour movie of a game; should I always select "Longplays?" Aren't some TASes quite long? I'm curious as to how much this matters, and in what way. Also, I'm really fascinated by TASBot, as are some of my friends. Is each TASBot made specifically for a certain movie file, or is there a way to load a movie onto a TASBot easily and then replace it with another later? I apologize if those questions are strange, but I suppose I don't understand the TASBot much at all. I'd love to goof around with one, but I'm afraid it would be way beyond my understanding. Are TASBots "user-friendly" or do you need to know what you're doing to use them?
Experienced Forum User
Joined: 4/17/2017
Posts: 25
The page I linked to already gives the approximate framerate for N64. I was talking about the real N64 framerate, the exact one, like given for other consoles out to many decimal places. When you Speedrun, recording at the accurate FPS makes a difference. You can read this thread for more info. But yeah... it would be nice to know the accurate framerate for the N64 like we do for other consoles.
Post subject: Will we ever know the real N64 framerate?
Experienced Forum User
Joined: 4/17/2017
Posts: 25
I'm a person who owns a capture card and enjoys playing "retro" console games and recording them. I do this mostly for personal enjoyment and occasionally I try to do some speedrun stuff. For the speedruns, I believe in having the actual framerate of the console, to set the recording FPS to be the same. I love this page because it allows me to see the real framerates of many different consoles. However, I believe the N64 is a sorely missed addition. Of course, I'm aware that N64 emulation has come a long way since its creation and still has a ways to go, and is not as accurate as other emulators. But I wonder if one day we could know the real framerate for this console... it would make me a happy gamer :') Am I getting my hopes up? How far off is that day?