Topic by Sonia

Posted: 6/24/2015 1:52 AM

Post subject: emulation inaccuracies in snes9x 1.52-rr

Quote

Sonia

She/Her

Joined: 12/6/2013
Posts: 435
Location: Brazil

Can someone give me a list of them or at least some notable examples? Because I'm seeing a lot of "bsnes is the only accurate emulator, the rest sucks" everywhere but yet nobody tries to make a comparison between the emulators. The only notable snes9x innacuracy I've seen so far is that it can't emulate the plane shadow on Air Strike Patrol. If bsnes is so infinitely better, then I'd like enough proof.

Posted: 6/24/2015 4:01 AM

Quote

jlun2

Skilled player (1707)

Joined: 9/17/2009
Posts: 4952
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"

1. 1.52 rr? Does that even have rerecord yet? 2. iirc, a certain lag glitch in some megaman that was doable only on console due to less lag on snes9x. Also applies to a varied extent for pretty much any game; some worse than others. Hard for me to give specific examples when I never really TASed SNES games and grew up with mostly gameboy. Sorry.

LLCoolDave wrote:

This seems to be competing for the "Worst looking TAS of 2011" Award.

Posted: 6/24/2015 4:11 AM

Quote

Sonia

She/Her

Joined: 12/6/2013
Posts: 435
Location: Brazil

jlun2 wrote:

1. 1.52 rr? Does that even have rerecord yet?

Well, I'm talking about this one: https://code.google.com/p/snes9x-rr/downloads/detail?name=snes9x-1.52-rr-r185.zip&can=2&q=

Posted: 6/24/2015 6:57 AM

Quote

FractalFusion

Editor, Skilled player (1941)

Joined: 6/15/2005
Posts: 3247

I cannot give too many examples since I am not well-informed; however I can point out some claims made by others. - According to Hetfield90, there is a glitch in Mega Man X2 (bypassing one of the sliding crystals). It can be done in a particular way that works on any version of Snes9x but not on BizHawk or console, because of inaccurate emulation of the physics of the crystal (I don't think this was the glitch that jlun2 was alluding to; that was another glitch in the same stage that was also emulator-dependent). Fortunately, I managed to find another way to pass through the crystal that does work on BizHawk (and later verified on console); the "fortunately" is because I did not realize for many years that the easier forms of passing through the crystal were based off emulation inaccuracy. - From the same game, the final boss fight has less lag than it is supposed to have. To be fair, Hetfield90 claims that BizHawk has this problem too, just not as much. Might be because Mega Man X2 is a Cx4 game and Cx4 is hard to emulate properly. - This page lists accuracy tests for SNES emulators. - This page gives a list of bugs caused by inaccurate emulation. The page also says that "roughly 2/3rds of them also exist in Snes9X v1.52 and earlier". (EDIT: byuu archive link updated to one without broken images. --Mothrayas)

Posted: 6/24/2015 10:27 AM

Quote

creaothceann

He/Him

Editor

Joined: 4/7/2005
Posts: 1874
Location: Germany

FractalFusion wrote:

- This page gives a list of bugs caused by inaccurate emulation. The page also says that "roughly 2/3rds of them also exist in Snes9X v1.52 and earlier". (EDIT: byuu archive link updated to one without broken images. --Mothrayas)

Alternative link: http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/

Posted: 6/24/2015 4:04 PM

Quote

Sonia

She/Her

Joined: 12/6/2013
Posts: 435
Location: Brazil

Thank you very much, guys. Those links are very informative and now I could finally see more examples of emulation inaccuracy. Seems to be true then. Bsnes is definitely more accurate, but at least snes9x can still emulate almost all games just fine.

Posted: 6/24/2015 5:13 PM

Quote

dekutony

Experienced player (633)

Joined: 11/23/2013
Posts: 2208
Location: Guatemala

Gamer Maiden Sonia wrote:

Thank you very much, guys. Those links are very informative and now I could finally see more examples of emulation inaccuracy. Seems to be true then. Bsnes is definitely more accurate, but at least snes9x can still emulate almost all games just fine.

though bsnes is really fucking slow.

Here, my YouTube channel: http://www.youtube.com/user/dekutony

Posted: 6/24/2015 5:15 PM

Quote

Noxxa

They/Them

Moderator, Expert player (4142)

Joined: 8/14/2009
Posts: 4083
Location: The Netherlands

Kurabupengin wrote:

though bsnes is really fucking slow.

You should read the Ars Technica article creaothceann linked to.

http://www.youtube.com/Noxxa <dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects. <Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits <adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.

Posted: 6/24/2015 6:13 PM

Quote

Amaraticando

It/Its

Editor, Player (158)

Joined: 1/10/2012
Posts: 673
Location: Brazil

Chrono Trigger's TAS of the year is based on bad emulation: Post #316780 Super Mario World credits warps is not possible on Snes9x, but was verified on console and emulators with the bsnes core. BTW: Snes9x 1.5x is not hated like you said, I hate the fact that some people still use the 1.43 version to TAS, just to save lag frames or due to laziness to switch.

Posted: 6/24/2015 6:16 PM

Quote

Sonia

She/Her

Joined: 12/6/2013
Posts: 435
Location: Brazil

Kurabupengin wrote:

though bsnes is really fucking slow.

Yeah, I noticed it. Even if you unthrottle the emulator, it still runs really slowly. I'm rather casual and don't care much about accuracy, so I will stick to snes9x to make my movies since it works much faster for me. The only thing that actually bothers me are nasty graphical or audio glitches, I don't really mind if the emulator has less lag than it's supposed to have on X game or stuff like that.

Posted: 6/24/2015 6:33 PM

Quote

adelikat

He/Him

Emulator Coder, Site Developer, Site Owner, Expert player (3600)

Joined: 11/3/2004
Posts: 4739
Location: Tennessee

I'm rather casual and don't care much about accuracy

I don't really mind if the emulator has less lag than it's supposed to have on X game or stuff like that.

We at TASVideos, do care. We want authenticity and verifiability. If you are attempting to make TASVideos quality movies, you should also care. If you were to make longplays, they care about accuracy just as much (if not more) than we do. If you are just making causal movies for yourself, then whatevs.

It's hard to look this good. My TAS projects

Posted: 6/24/2015 7:01 PM

Quote

Sonia

She/Her

Joined: 12/6/2013
Posts: 435
Location: Brazil

smh. I thought I made it clear I was speaking about myself and not in the name of the tasvideos community. Yeah, I know how things work here, but since I'm not going to submit my videos to this site nor to longplays, then I see no reason to care about accuracy so hard. I work independently.

Posted: 6/24/2015 9:03 PM

Quote

Sonia

She/Her

Joined: 12/6/2013
Posts: 435
Location: Brazil

Okay so, since I was the one that made this thread, I might as well get a bit deeper into it because I'm curious about a few stuff. I was analyzing [URL=http://tasvideos.org/EmulatorResources/SNESAccuracyTests.html]this page[/URL], and I see that snes9x 1.51 failed on some tests. I took the opportunity to learn a bit more about them over the web, and this is what I think they're trying to mean: Mouse Electronics Test / Mouse Button Test / Mouse Cursor Movement Test: Seems to be obvious enough. It has to do with the games that use mouse (like Mario Paint). Failure on this emulation will cause the mouse to act incorrectly. Color Test: snes9x doesn't emulate all color palettes accurately enough to pass the test? APU: Audio Processing Unit. Inaccuracy on this emulation will cause the audio and sound effects to play imperfectly? SNES OAM Test (3-high): no idea. Can someone make this one clear to me? SNES ADC SBC: From what I found, seems to have to do with latency. Does it have to do with how accurately the emulator emulates the lag from games?

Posted: 6/24/2015 9:58 PM

Quote

creaothceann

He/Him

Editor

Joined: 4/7/2005
Posts: 1874
Location: Germany

Gamer Maiden Sonia wrote:

APU: Audio Processing Unit. Inaccuracy on this emulation will cause the audio and sound effects to play imperfectly?

Probably. (Though there's also the case where ZSNES' failure to emulate the echo buffer allowed the creation of Super Mario World hacks that crashed in emulators that did emulate the buffer, and of course on real SNESes.)

Gamer Maiden Sonia wrote:

SNES OAM Test (3-high): no idea. Can someone make this one clear to me?

OAM is a 544-byte buffer for the attributes of the hardware sprites that are on screen. Like the video RAM it's loosely connected to the main CPU, and the connection has some quirks. For more info see anomie's register doc, register 0x2104 ("OAMDATA").

Gamer Maiden Sonia wrote:

SNES ADC SBC: From what I found, seems to have to do with latency. Does it have to do with how accurately the emulator emulates the lag from games?

ADC is the "add with carry" instruction and SBC is "subtract with borrow". When these instructions are not emulated correctly, calculations done with them will create incorrect results. As you might expect this should be easy to detect (games would most likely crash even before showing any graphics), but there are lots of parameters that can influence the instructions, and emulator bugs may affect only some rare variants.

Posted: 6/25/2015 4:45 PM

Quote

Sonia

She/Her

Joined: 12/6/2013
Posts: 435
Location: Brazil

creaothceann wrote:

OAM is a 544-byte buffer for the attributes of the hardware sprites that are on screen. Like the video RAM it's loosely connected to the main CPU, and the connection has some quirks. For more info see anomie's register doc, register 0x2104 ("OAMDATA").

And what sort of bugs/glitches could inaccurate emulation of "3-high" cause?

Posted: 6/25/2015 6:38 PM

Quote

creaothceann

He/Him

Editor

Joined: 4/7/2005
Posts: 1874
Location: Germany

The data in OAM would not be correct, so sprites could have the wrong position, use the wrong color palette or the wrong bitmap data, have the wrong priority (i.e. appear behind/in front of the wrong background layers), or might be horizontally and/or vertically flipped when they shouldn't be (and vice versa). Of course most of the time not all 128 hardware sprites are on screen (most are 'parked' beyond the right or bottom screen border), so even if the wrong data ends up in OAM it might not be visible. If the game is really starved for memory then theoretically it might use part of the OAM as additional RAM - just like some games had SRAM in their cartridges (not backed by a battery) for that purpose. If the data read back from OAM is wrong then the game might show all kinds of glitchyness or even crashes.

Posted: 6/28/2015 7:51 PM

Quote

creaothceann

He/Him

Editor

Joined: 4/7/2005
Posts: 1874
Location: Germany

Here's more info about why cycle accuracy is important and how difficult it is to achieve on the GBA.

Posted: 8/7/2015 6:11 PM

Quote

Sonia

She/Her

Joined: 12/6/2013
Posts: 435
Location: Brazil

Sorry for the bump, but I don't understand why snes9x 1.53 emulates pseudo-hires translucency perfectly but not snes9x 1.52 and earlier. Failure on this emulation makes games like Kirby's Dreamland 3 look rather awkwardly. From what I saw on the SNES accuracy tests page, there's no difference between snes9x 1.51 and 1.53 apart from snes9x 1.53 passed on APU and on the Mouse Electronics Test, Mouse Button Test and Mouse Cursor Movement Test. But I doubt any of those is related to pseudo-hires translucency. Can someone explain things to me?

Posted: 8/7/2015 7:04 PM
(Edited: 8/7/2015 7:47 PM)

Quote

moozooh

Senior Moderator

Joined: 8/4/2005
Posts: 5770
Location: Away

Gamer Maiden Sonia wrote:

Sorry for the bump, but I don't understand why snes9x 1.53 emulates pseudo-hires translucency perfectly but not snes9x 1.52 and earlier.

That's a... weird thing to ask. Might be because it was fixed in 1.53 but the fix wasn't there in 1.52 and earlier.

Gamer Maiden Sonia wrote:

From what I saw on the SNES accuracy tests page, there's no difference between snes9x 1.51 and 1.53 apart from snes9x 1.53 passed on APU and on the Mouse Electronics Test, Mouse Button Test and Mouse Cursor Movement Test. But I doubt any of those is related to pseudo-hires translucency. Can someone explain things to me?

Could be that neither of those tests checked for pseudo-hires translucency. Which wouldn't be completely surprising because this mode is a trick rather than a feature. Certain developers employed really unconventional techniques to make their products stand out, which often meant unexpected hardware/software interactions. I don't think there are tests written for every one of these, aside from the games themselves. (EDIT: I mean using hi-res to emulate translucency is the trick, not the hi-res mode itself. Out of the already few games that use that mode, even fewer use it this way.)

Warp wrote:

Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.

Posted: 8/7/2015 7:09 PM

Quote

creaothceann

He/Him

Editor

Joined: 4/7/2005
Posts: 1874
Location: Germany

This is what the SNES outputs in hi-res mode. Due to the analog nature of the TV sets of that time, the vertical lines blend together. This is a trick usually employed by Genesis games because the graphics hardware can't combine the background/sprite layers. SNES9x v1.53 has an option called "Blend Hi-Res Images" in its video options; this simulates the TV's blending effect and makes the games look nicer. It's not really more accurate emulation of the SNES itself though and it can't be detected by games, so it wouldn't matter for TASes. The SNES renders 512 pixels per line. The game can select twice which backgrounds and sprites are drawn, once for the even-numbered pixels and once for the odd-numbered pixels. When high-res mode is activated, all 512 pixels are sent to the TV. (This is what KDL3 does.) Usually the high-res mode is deactivated so you only see the odd-numbered pixels; this is called the "mainscreen". When "color math" is activated, the even-numbered pixels ("subscreen") can be combined with the odd-numbered pixels. This is how games achieve effects like transparency (the transparent layer is simply only on one screen).

Posted: 8/7/2015 8:40 PM

Quote

Sonia

She/Her

Joined: 12/6/2013
Posts: 435
Location: Brazil

I'm feeling stupid now. Snes9x 1.52 can emulate KDL3's translucence stuff as well, you just need to leave the "Hi Resolution Support" option enabled. I had it unchecked so that's why the graphics were opaque. >.> Thank you for the info, guys.