I've heard Byuu retiring but didn't know exactly why other than burnout but the tldr for those who don't want to read it all is the extreme difficulty of completing the last 1% for complete SNES...
I've heard Byuu retiring but didn't know exactly why other than burnout but the tldr for those who don't want to read it all is the extreme difficulty of completing the last 1% for complete SNES emulation. I have such admiration for people like this, who put so much time into something so many get out of and do it all for the love of the game.
I think if you're interesting in emulation at all, you can make the TL;DR a bit more specific: He's looking for someone to create a 100x magnification scan of the PPU (Picture Processing Unit) and...
I think if you're interesting in emulation at all, you can make the TL;DR a bit more specific: He's looking for someone to create a 100x magnification scan of the PPU (Picture Processing Unit) and map the individual logic circuits on it. More specifically, he estimates this to be a 600 hour job for someone with an extremely high-value skillset!
I believe the main issue is timing inconsistencies when a game reads registers mid-scanline (Air Strike Patrol seems to be the only game to do this intentionally but many more do it unintentionally and can still cause weird bugs if it isn't emulated perfectly). So currently, most emulators do a messy set of per-game hacks with estimated values, but none of them are "correct" and a fix with a guessed value for one game can cause bugs in other games.
Also, when applied per-game, most of these hacks seem to work just fine, so this is more about reaching "perfect" emulation than getting games playable. The state of SNES emulation is amazing.
This article is written by byuu, the creator of bsnes and higan, who's done some really amazing work moving emulation forward over the last 15-20 years. He also recently announced that he was...
But this was all really brought to the forefront for me in 2018, when pretty much every mistake I've ever made in life was chronicled and presented in the worst possible light against me.
I honestly don't know. I was a bit curious too, but it felt kind of rude to try to dig it up, since it seems to be something that he's ashamed of. I'm assuming that someone compiled a big post...
I honestly don't know. I was a bit curious too, but it felt kind of rude to try to dig it up, since it seems to be something that he's ashamed of. I'm assuming that someone compiled a big post full of times he acted like an asshole on forums/IRC, or something similar.
Near actually posted the direct link to the article themselves in the thread about this over on /r/emulation, saying something to the effect of "this is all public information". It then got...
I caught the thread before the link got taken down, and can confidently say you're not missing anything of substance. It was primarily a character assassination hit piece posted by someone who has a racial slur as part of their username. That links to the particular site where it was posted regularly get removed probably says everything you need to know about what was in it and how worthwhile it is.
There was a post made about him on Kiwi Farms. (More About Kiwi Farms). I won't link it here, but those wiki pages should give you an idea of what the content was.
There was a post made about him on Kiwi Farms. (More About Kiwi Farms). I won't link it here, but those wiki pages should give you an idea of what the content was.
There are a surprising number of stupid hacks...er...engineering choices made in the development of most systems. Stuff from the early 80s (Atari, C64, Apple ][, etc.) often had bizarre hardware...
I always assumed emulation was just a matter of the alternative device advancing to the point that it can dedicate enough resources to match the original consoles dedicated processes.
There are a surprising number of stupid hacks...er...engineering choices made in the development of most systems. Stuff from the early 80s (Atari, C64, Apple ][, etc.) often had bizarre hardware that had baked in assumptions about things like the number of pixels in the output, the frame rate of the output device, etc. You couldn't just pull out a monitor of a different resolution and stick it on a C64, for example. It assumed you were outputting to either a PAL or NTSC TV, essentially. (Both of which have really gross hacks in them, as well!) So games in particular would do things like figure out how many microseconds they had to do calculations for the next scanline they were outputting and then figure out how many instructions on that particular CPU running at that particular speed they'd be able to execute in that timespan. (See Racing the Beam for more info on this sort of thing.)
So when making an emulator, you can't just do things like copy a buffer to the screen 50 or 60 times a second if you want to run some of the games from the era. You have to ensure that you run the calculations of the emulated CPU at the right speed and output to your frame buffer in the right order with the right timing. It's those types of things that can be really challenging to get correct even on modern systems with far more capable hardware. It's fairly easy to do basic emulation of an old system like that, but not easy to get it exactly right or sometimes even close. But it is fun to try!
I wonder that myself since, surprisingly, PS3 emulation is already in a fairly developed state right now. I'm sure that under the hood, it's a mess of kludges and game specific hacks, but...
Will the PS3, with it's famously "challenging" CELL processor, pose similiar problems for emulators of the future?
I wonder that myself since, surprisingly, PS3 emulation is already in a fairly developed state right now. I'm sure that under the hood, it's a mess of kludges and game specific hacks, but compatibility's past half the library on rpcs3.
I doubt that CELL will be a problem for emulation. All the most important bits are already fairly well known since it's based on PowerPC, and there is fairly good documentation for the non-PPC SPU...
I doubt that CELL will be a problem for emulation. All the most important bits are already fairly well known since it's based on PowerPC, and there is fairly good documentation for the non-PPC SPU elements. Beyond that, microprocessors generally are well documented so that programmers and compiler designers can make the most out of them. They do tend to sell based on efficiency, after all.
Beyond that, new games are much different than old games. SNES games were written on the bare metal and had programmers taking advantage of errata and imperfections in the hardware. Modern games are all built on thousands of libraries that are usually written to be portable and therefore will generally not take advantage of odd tricks.
Modern emulators don't even take the same approaches that older ones did; it's not good enough to simply simulate what a processor will do because that demands insane performance. Instead of simulating processors, modern emulators act like virtual machines that JIT recompile code into something they can run much faster.
I've heard Byuu retiring but didn't know exactly why other than burnout but the tldr for those who don't want to read it all is the extreme difficulty of completing the last 1% for complete SNES emulation. I have such admiration for people like this, who put so much time into something so many get out of and do it all for the love of the game.
I think if you're interesting in emulation at all, you can make the TL;DR a bit more specific: He's looking for someone to create a 100x magnification scan of the PPU (Picture Processing Unit) and map the individual logic circuits on it. More specifically, he estimates this to be a 600 hour job for someone with an extremely high-value skillset!
I believe the main issue is timing inconsistencies when a game reads registers mid-scanline (Air Strike Patrol seems to be the only game to do this intentionally but many more do it unintentionally and can still cause weird bugs if it isn't emulated perfectly). So currently, most emulators do a messy set of per-game hacks with estimated values, but none of them are "correct" and a fix with a guessed value for one game can cause bugs in other games.
Also, when applied per-game, most of these hacks seem to work just fine, so this is more about reaching "perfect" emulation than getting games playable. The state of SNES emulation is amazing.
This article is written by byuu, the creator of bsnes and higan, who's done some really amazing work moving emulation forward over the last 15-20 years. He also recently announced that he was going to be stepping away from further development for various reasons.
What's that all about?
I honestly don't know. I was a bit curious too, but it felt kind of rude to try to dig it up, since it seems to be something that he's ashamed of. I'm assuming that someone compiled a big post full of times he acted like an asshole on forums/IRC, or something similar.
Near actually posted the direct link to the article themselves in the thread about this over on /r/emulation, saying something to the effect of "this is all public information". It then got removed by moderators because of the site that it linked to.
I caught the thread before the link got taken down, and can confidently say you're not missing anything of substance. It was primarily a character assassination hit piece posted by someone who has a racial slur as part of their username. That links to the particular site where it was posted regularly get removed probably says everything you need to know about what was in it and how worthwhile it is.
There was a post made about him on Kiwi Farms. (More About Kiwi Farms). I won't link it here, but those wiki pages should give you an idea of what the content was.
There are a surprising number of stupid hacks...er...engineering choices made in the development of most systems. Stuff from the early 80s (Atari, C64, Apple ][, etc.) often had bizarre hardware that had baked in assumptions about things like the number of pixels in the output, the frame rate of the output device, etc. You couldn't just pull out a monitor of a different resolution and stick it on a C64, for example. It assumed you were outputting to either a PAL or NTSC TV, essentially. (Both of which have really gross hacks in them, as well!) So games in particular would do things like figure out how many microseconds they had to do calculations for the next scanline they were outputting and then figure out how many instructions on that particular CPU running at that particular speed they'd be able to execute in that timespan. (See Racing the Beam for more info on this sort of thing.)
So when making an emulator, you can't just do things like copy a buffer to the screen 50 or 60 times a second if you want to run some of the games from the era. You have to ensure that you run the calculations of the emulated CPU at the right speed and output to your frame buffer in the right order with the right timing. It's those types of things that can be really challenging to get correct even on modern systems with far more capable hardware. It's fairly easy to do basic emulation of an old system like that, but not easy to get it exactly right or sometimes even close. But it is fun to try!
I wonder that myself since, surprisingly, PS3 emulation is already in a fairly developed state right now. I'm sure that under the hood, it's a mess of kludges and game specific hacks, but compatibility's past half the library on rpcs3.
I doubt that CELL will be a problem for emulation. All the most important bits are already fairly well known since it's based on PowerPC, and there is fairly good documentation for the non-PPC SPU elements. Beyond that, microprocessors generally are well documented so that programmers and compiler designers can make the most out of them. They do tend to sell based on efficiency, after all.
Beyond that, new games are much different than old games. SNES games were written on the bare metal and had programmers taking advantage of errata and imperfections in the hardware. Modern games are all built on thousands of libraries that are usually written to be portable and therefore will generally not take advantage of odd tricks.
Modern emulators don't even take the same approaches that older ones did; it's not good enough to simply simulate what a processor will do because that demands insane performance. Instead of simulating processors, modern emulators act like virtual machines that JIT recompile code into something they can run much faster.