Emulator Coder, Site Developer, Site Owner, Expert player
(3576)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
PikachuMan wrote:
It said it fixed load times of Zelda's Birthday. I do have 1.8.2, but it still doesn't load Kakariko Village. Is there anything I'm doing wrong?
You misread, it fixed the LOADING of the game, nothing more. Whether or not the game actually plays is different. It doesn't actually run well in any emulator other than PJ64, talk to the author of the romhack about that.
I want to know the exact differences between the three profiles of BizHawk:
1) Casual Gaming
2) Tool-Assisted Speedrun
3) Longplays
The keywords for them are "performance", "accuracy" and "stability" respectively, but this doesn't tell much.
I don't do speedruns (as in: clearing the game as fast as possible), so I suppose I can ignore the second option, right?
But... I do gameplays of me clearing a game without taking damage and stuff, so... for example, let's say I want to beat a shmup without dying. Shmups are short, they can be cleared quickly. So... should I choose "Casual Gaming" for that?
But... what if I want to do a full RPG playthrough: RPG's are long, they take hours to be finished. So, should I select the third option (Longplays) for them?
I just want to know if I got things right. As in: if the first option is for short games and the third option is for long games.
Performance = emulation accuracy is overrated, you want the game to play fast and be responsive.
Stability = emulation should be as accurate as possible without going overboard and slowing the thing down to a crawl.
Accuracy = emulation should be as accurate as possible, and speed be damned; there will be faster computers in a nearby future, and perfect accuracy is paramount (say, for archival purposes).
Casual gaming = you play sometimes for your own amusement; you just want the thing to play well. If something happens differently in the emulator and on console, you probably won't notice.
Longplay = you want to make a video showing as much of a game as possible (probably aiming for 100% completion), and you want the emulator to be accurate without sacrificing speed. Ideally, anything you show would be possible to do on console, and since you are unlikely to exploit any glitches, this is enough.
Tool-Assisted Speedrun = you want to bring the game down to its knees and make it cry for mercy; speed of emulation is irrelevant, since you will be working on frame advance anyway. You want as much accuracy as possible to make sure that the game breaking bugs you use are not due to inaccurate or buggy emulation.
EDIT: marzojr answered, but I'll keep my text here:
synnchan wrote:
I want to know the exact differences between the three profiles of BizHawk:
1) Casual Gaming
2) Tool-Assisted Speedrun
3) Longplays
1) It provides a precise emulation, but not 100% precise, and is useful if you just wanna play around. I tested right now and got 100~120 fps without problems. It uses bsnes performance core.
2) The objective here is to emulate the console very accurately. A TAS must ideally be done like it was on the console. Even the lag count is very similar. The fps I got was 60~70. It uses bsnes compatibility core.
3) Here, the aim is not to crash the emulator in the middle of a long play. Crashing in the making of a TAS is generally not a big deal, because we are recording anyway. It uses bsnes compatibility core as well.
By the way, I'm curious on why there's no accuracy core for Bizhawk and lsnes...
And why both desync (lag) after some time.
it takes an extraordinary amount of effort to repair bsnes so that it's usable in a rerecording emulator. with two cores already done, there is less priority on a third.
Your parenthetical comment about desync and lag can't be analyzed. It doesnt make sense without more detail. Those cores aren't expected to be desyncing right now.
Joined: 11/13/2006
Posts: 2822
Location: Northern California
Fully expecting a storm of people asking where 1.8.3 was without realizing they've technically been using it this entire time.
TASvideos Admin and acting Senior Judge 💙 Currently unable to dedicate a lot of time to the site, taking care of family.
Now infrequently posting on BlueskywarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
I used to think git revision hashes were dumb, but if they train people not to expect sequentiality of releases and wonder where missing revision numbers went, as if there's gonna be a missing volume on their collection shelf, then maybe there's something to it after all...
How can I read the size of the lateral gaps: the left, right, top and bottom dimensions of the black area around the game area? This, together with client.screenheight() and client.screenwidth(), would be awesome!
feature for reading letterboxing area was added after 1.8.4. youll be able to get the screen size as well.
Q: do other lua-bearing emulators youve used have or need this? is this problem bizhawk-unique for having a frontend which does the letterboxing? are other emulators displaying the frontend-space rendering only within the black-boxed area (such that it is impossible to draw outside it?)
I think I didn't understand perfectly the definition of 'letterboxing'. :(
I've used the black space to display text and hitboxes in Lsnes. You can add the black area manually in the configurations (lateral padding) or via Lua script (lateral gap).
The drawing functions usually don't care if the text is outside or not. But in Snes9x, nothing is drawn outside the game's area.
Screenshot: https://pbs.twimg.com/media/BxYgf_uIMAAiOar.png:large
This might be a bit delayed but I've been away for a bit.
Was the GBC timing issue introduced in 1.7.0 (I believe that was it, or 1.7.1, not sure) fixed yet?
I remember when the timing change occurred it wasn't uncommon for a movie to desync after playing back properly 5 times because it was tracking inputs in a really bizarre way or something.
A "timing issue" won't cause a movie to desync after playing back properly 5 times. A _bug_ causes that. Therefore I suspect you're asking about the desyncs you mentioned in another thread which you created, which was left at a "OK, I'll test it in 1.7.1" state, but just randomly guessing some crap about timing being involved because it sounds super serious.
