← Software Engineering Daily
Software Engineering Daily
Emulating Retro Games on Modern Consoles with Robin Lavallée and Bill Litshauer
01:01:17
Emulating retro games on modern consoles is a growing trend, and allows players to experience classic titles with improved performance, enhanced resolution, and added features like save states and rewinding. However,
Loading summary
Transcript79 lines
- [00:00]
Kevin Ball
Emulating retro games on modern consoles is a growing trend and allows players to experience classic titles with improved performance, enhanced resolution, and added features like save states and rewinding. However, this process raises many challenging technical questions related to hardware compatibility, performance optimization, rendering and state management. Implicit Conversions is a company focused on emulating retro PlayStation games on modern consoles. Robin Lavallee is the CEO and Bill Litschauer is the COO at the company. They join the show to talk about the engineering that's needed to emulate and enhance retro games. Kevin Ball, or K. Ball, is the Vice President of Engineering at Mento and an independent coach for engineers and engineering leaders. He co founded and served as CTO for two companies, founded the San Diego JavaScript Meetup and organizes the AI in Action discussion group through Latent Space. Check out the show notes to follow K. Ball on Twitter or LinkedIn or visit his website K Ball LLC.
- [01:14]
Host
Hey guys, welcome to the show.
- [01:16]
Bill Litschauer
Oh, great to be here.
- [01:18]
Robin Lavallee
Hey, nice to meet you.
- [01:19]
Host
Yeah, excited to get to dig into the kind of cool stuff you're doing, but let's maybe start with the two of you. So can you take turns? Introduce yourself? Who are you? How'd you get started in engineering and game development? And what is implicit conversions?
- [01:34]
Robin Lavallee
I'm Robin Lavallee. I'm a French Canadian. I live right now in Northern Philadelphia. I'm a software engineer, geek video Gamer, programmer at Art. Started programming when I was, I guess, seven years old when my dad bought me a Cocoa 2 Radio Shack TRS 80. It was in French, the manual was in French. It was important. I didn't speak any English. I started coding BASIC and I guess I never stopped. And then I got a job, you know, I work at Ubisoft, I work at 2K Games, I work at Twitch, I work at Meta, where I work on the Oculus, you know, the Oculus Quest on the Project Horizon there. And at some point I guess I got bored. What I did was I was always late on my gaming. So like when the PS3 came out, I was like, cool, now it's time to buy some PS2 games. And when the PS4 came out, I guess I never bought it. And so the company just came from there because, you know, I play old games and why not? I must not be around doing this. So yeah, that's me.
- [02:30]
Host
Awesome.
- [02:30]
Bill Litschauer
Cool. And my background is I'm also a Canadian. I was born in Montreal and moved to Toronto after I graduated from Queen's University. I had a computer engineering degree there, although I studied the hardware side of things like IC Design. I never. And I vowed I would never work in software because I didn't like it at the time. My first job was in software and I've never not been in software since then. I couldn't do anything with hardware now if you asked me to. So I worked at some digital signage company called omnivx for a while and then my first gaming experience was at Webkinz. So that's pretty retro for most of us. I was there from 2006 to 2009 and I was very fortunate to join there just as it exploded onto the scene. I think I was the 23rd,000th virtual pet that was adopted. And when I left three years later we were at 100 million. So it was massive growth and I got to be a part of that. And I was director of QA there. From there I went to another organization called Earth Rangers, which help kids protect animals. So there was a lot of casual games there as well too. So all told, I've helped produce over a hundred casual games throughout my career. And I was introduced to Robin through a friend of mine and we hit it off really well. And of course I'm big into the old games, anything classic. We have similar passions and we hit it off really well. And this is pretty much the dream job for me. And I've been here since I think it was the fifth or sixth hire and I'm COO here, so I manage operations.
- [04:12]
Host
Okay.
- [04:13]
Bill Litschauer
Yeah.
- [04:13]
Robin Lavallee
Awesome.
- [04:14]
Host
And so the company Implicit Conversions, y' all are emulating legacy games. Is that fair? What kind of game systems do you emulate?
- [04:21]
Robin Lavallee
Yeah, so we mostly PlayStation, so PlayStation 1, PlayStation 2, PlayStation Portable. Although we have started looking at others platform like behind the scene. We did nes, so we have a micro mage that we actually port and publish and we had a networking support. So that's been the pretty interesting. I used GGPO with the rollback networking library that's mostly used in like the street fighting games. And so this is the next game, you know, that was made by independent Morphcat and then we added like PS4 PS5 support to it and it working there so you can play four players online. So we did that and then now we're doing from those PS1 game I just mentioned now we're exporting them to Xbox, to the Switch and. And Steam gog. And I'm missing something here. Please teach on obviously.
- [05:09]
Bill Litschauer
Yeah, PS4, PS5, yeah. The big thing, we get requests for our PlayStation games, especially PS1. That is by far the number one request that we get from our Clients and they want it on Switch. That is the big thing. So that's. We have our. In our own proprietary software and our called Syrup. So it's called the Syrup emulation engine and that allows us to integrate different emulators as sort of modules or plugins. Our PS1 emulator is called Pancake. And our future PS2 emulator might be called Waffle and PS3, which I think we may talk about a little bit in the future, might be called Benedict because it's the fanciest of the three. But we just keep adding these emulators to it. And Syrup, what it allows us to do is add a whole bunch of special features to the game. So for example, on a 2D, like micromages, which is a 2D platformer that scrolls upwards as you're playing, we can add widescreen support so that you don't get the two black bars on both sides. We can also add like an interactive manual overlay which is really slick, you know, we added a shader so that you can turn the pages and you still relive that experience of when you bought a nes game in 1990, whatever. And then you, I suppose it would be a super NES game at that point, but you would read the instruction manual on the way home in the car ride. At least that's what I did. And so you're able to do that with our games now. And of course, like Robin said, we integrated modified GGPO so that we could have netplay support, which had its own challenges. So whatever the request is, we're able to add that as a module into Syrup and branch that out. We support Genesis for example as well too. We just haven't had requests for that at the moment.
- [06:50]
Host
So let's maybe dive into what it means to port one of these games over. So you mentioned the word emulation. So does that mean that you're essentially starting with an existing binary and then sort of running a simulated machine underneath it? Or like what does the stack look like as you're bringing one of these games from PS1 to Switch, for example?
- [07:09]
Robin Lavallee
Yeah, it's emulation, so we don't use the source code. So for example, let's say we have the ISO file, the ROM file for modular game. Right now we are doing Fear Effect one. So let's say think it's two disc game or maybe four disc, I got it wrong. But anyway, so we have those files obviously as part of the package and the stack looks like, you know, we have a, we have a command library, you know, like all the low level file handling and stuff like that, you know that Utex and so on. We have Pancake, which is our PS1 emulator. You can see it like a bit like any PS1 emulator that exists in open source, except this one is proprietary. And then we put this on top of Syrup, which is basically like a front end based on Retroarch Libretto. And so in that case, that front end is ported to console because, you know, there's a lot of emulator. You might say, like, why are you doing all this? Militaries already exist on, if I go and get up, I can find hundreds of them. Right, that's true. But they are on PC mostly and people are not buying them. And the reason they're not buying them is because, well, we won't talk about it. But either way, and then the issue is, okay, fine, how can I get a Switch, a legal emulator on the Switch? Well, that doesn't really exist because you need an NDA with Nintendo to do that, you need an NDA with Microsoft to do Xbox and so on. And so we have, with my gaming experience that I had at Ubisoft and so on, I learned a lot about console development. And then from the emulation side, if you join those two together, now we get emanation for console, basically. And now I'm using my, a bit less geeky now, but my business connection to try to convince developer or publisher to say, hey, you know, you got this game, any game, I don't know Silent Hill, we didn't do it, but it's a silent deal. Like I want Silent Hill on the original one and do it again on the Switch. Well, we can do it. People are actually surprised. I don't think the publisher, developer fully understands sometimes that we can do port, we call it port because in the business dev, it's what it is support without the source code. And so I think that gave us a big advantage.
- [09:07]
Bill Litschauer
It's a company, okay?
- [09:09]
Host
So as someone who's not a game developer and some of the folks out there will be very familiar with what goes into game emulation and some will not. What does that end up looking like? So you have this file, it's making a set of essentially system calls down into the game level and you are providing an interface for those and mapping them in some way. But what does that stack inside of the emulator look like?
- [09:30]
Robin Lavallee
We have HLA emulation. So basically like, you know, the original game. Let's go back to the PS1 game. PS1 game was compiled by you know, a team 30 years ago, and it was put on the disk. And that code that live on the disk is, you know, has a bunch of game code, which is fine because we got permission to use this game code from the publisher. It also has NDA code, like the SDK code from PS1. SDK. Okay, you might say, well, who cares? But we do care, because that code, technically, this SDK is copyrighted by Sony Interactive or Sony Computer Entertainment. Back then, if you want to run this on PlayStation device, that's fine because I guess you're doing Sony to Sony. But if you're running this on a switch, you're not supposed to be running SDK proprietary code, putting that on the switch. You don't own this thing. You're not allowed to do this. So we have to remove that code. Okay, all right, let's remove the code. Let's say the code is, I don't know, code to save on a memory card. All right, so there's some, like, function that they added, like we call MEM save or whatever slot, and then it does stuff. Well, okay, you remove that code now, you can't save anymore. Not really. So you need to hook at this point in the function, like it was calling this C function to save. All right, we replaced that code. It's gone. We have a mapping. The interpreter. When it gets there, it says, okay, you're calling function X. All right, let's call our code now the code in pancake, it's a PS1 code. Now we do our own stuff. Well, I'm running on the switch, all right, I'm going to put this on the buffer somewhere, blah, blah, blah, blah. And then when the PS1 is done saving, now I can use the switch SDK function to actually save on what the switch expect on Xbox. Xbox. So now you got this little layer of like, you know, the save for Xbox, the save for this, for the switch, the save for PC, for example, that's for saving. There was something else I wanted to say about this. So, yeah, talk about the interpreter. So you might say, well, all right, we got an interpreted emulator. Like, you're just interpreting, like the CPU instruction on the MIPS computer on PS1 that can be slow because you're always interpreting code every time. If you have a tight loop that's just waiting for Vsync, for example, well, your emulator is just doing useless work. It's just spinning around, waiting for no reason to some external event that doesn't really exist. So we do what we call aot. We cannot jit another big thing from different. So on PC emulator you can use just in time compilation. That's not allowed on console for security reason. So I mean the kernel does it like, you know, if you use a web browser, for example, on PS5, I believe it's based on the WebKit, I believe it may have used JIT on the PS4. I think they may have removed it on PS5 for security. That's why many of the security issues are web based on console. But nevertheless. So we had to use AOT ahead of time compilation, which was the. You know, if you go back in time, I believe when Flash was removed from iPhone, I guess 10 years ago, people still were making Flash games and we're like, well how do I target iPhone anymore? And Adobe provided some kind of compiler. Adobe, I might be wrong. Adobe Hair and that use AOT basically would pre compile your Flash bytecode into like C code or C code and then you would actually build this thing and then run it on the iPhone. Well, it's the same thing we're doing. We generate, we take the MIPS code from the PS1, we generate a bunch of C code from this, and then we run the compiler on that. Bang. And then that's it.
- [12:42]
Host
Oh, that's interesting.
- [12:43]
Robin Lavallee
Yeah, yeah. So there's nothing new there. I mean, this has been done before, but we have to do it and we have to do it efficiently because you can't just like, you know, do it. Yeah, yeah.
- [12:53]
Bill Litschauer
And I can add to that, like one of the number one questions we get is, well, how can it be difficult to run a PS1 game, which was a very weak machine compared to the PS5, which is gargantuan. Well, you're still limited by the hardware restraints that existed by the PS1 to a certain point. Right. So when you're running your emulator or pancake as a PS1, the games expected delays in certain parts, Right. So if you're reading from the CD rom, it expects that, okay, when I read from this sector, it's going to take X amount of milliseconds or what, whatnot. Well, that doesn't exist anymore. Right. We're reading from disk, which is almost instantaneous relative to the CD rom. So we have to account for those timing issues. And timing issues is one of the big things that we have to deal with when it comes to PS1, PSP and PS2. So that's one of the things we have to take into consideration as well too. And like Robin said, performance is arguably the Number one issue we have to worry about, especially on lower end devices like the Switch. So ahead of time compilation. What we do when we first get a game is our QA team will play through it and we profile it. So using our tooling system, we're able to see what all the hotspots are. So by running through say the first level, we're probably hitting all the major functions within the game, almost all the major functions within the game. And the profile will then generate files, store them in a library and then those files will be called. The next time you run the game, it's running that pre compiled code as opposed to running it on the fly. So that non performant part of the game now runs really well. So aot solves a lot of problems when it comes to performance.
- [14:36]
Host
Got it. So are you ending up actually just to make sure that I understand and once again new to the game emulation space personally and trying to echo this for everyone else who doesn't have that background. So you're basically taking this binary, running it through a real time emulator that is then capturing what's functionality and then using that to generate code so that you can actually rather than real time emulate, you're going to compile a new binary that will run against whatever machine you're targeting?
- [15:06]
Robin Lavallee
Yes. I mean the AOT will only be generated once because it's the same C code, it will be portable. You have to compile it on each target. So you decompile that C. We create a DLL actually like a. Well, yeah, dynamic library. So file or whatever the format is on the target, but using clang for example, so you know, it just works. Some of the issue we may encounter is like sometimes when you do aot, you might end up like, you know, you're trying to find a function, like you know, trying to find the beginning of the function. In the end it might be like a very long function if you just have the C function here and there's no interrupt when you're running this like you know, whatever the system call was happening or like the, like the real hardware was doing other stuff like what's interrupting you to service some IO stuff. We're not doing that like just running the whole thing. So maybe we need to insert like you know, some delay there or like, you know, like oh about. So now you need to have it the code to be reentrant kind of. So I'll be honest, I didn't write. I'm managing a company now, so I have a background in software Engineering, I'm a programmer, but all the details, I don't, I don't know them. Okay, yeah.
- [16:11]
Host
So let's talk a little bit about those timing issues then. Right. So if I'm understanding. Let me summarize back a little bit. Right. There are. Because this older hardware had these dependencies on things like reading from the CD rom it would build in a whole bunch of techniques for managing the fact that this is going to take three seconds, this is going to take however long it's going to take. And if suddenly that delay goes away, things may not work at all or they may be really choppy or just feel very awkward. Are those delays predictable by device, by function call? How much is this A. Oh, we can map directly to. Based on the code that we have the binary and running our test file, we know where the delays need to be versus this is an interactive. Oh, this feels funny. I need to insert a delay here. Like iterative process.
- [17:00]
Robin Lavallee
There's a bit of both. For example, we know from the CPU manual how many cycles an instruction is supposed to take. So, so you can simulate like cycle count. Like you know, all right, it's been. You did a load instruction, load memory. All right, 12 cycle. You did a had one cycle. That's approximate because you know the load memory. You know, what if it's in the cache? What if it's not in the cache? Well, we're not really simulating the real. I don't know what it was 64 ways association cache on the PS1. We could but at some point maybe it doesn't really matter. So maybe everything is in the cache. Most games will tolerate that, but some might not. Like give you an example, maybe there's legacy bugs. Like maybe the game would actually ask to read from the disk and then immediately after check if the read is ready. That would fail. Right? Because it would. Please read. Is it ready? No. And then it would do some code. Now if we do it better and we say, you know what, you want to read this 100 megabytes on the disk. Yeah, you got it. Well now the code will enter a path that you never did in the legacy game. And now maybe dragons will appear. Maybe it will be fine actually. So depending on how the game was coded, it might crash or not. So you probably should be better really behaving like the old hardware. But if you do that now, you got long loading screen, for example. So there are times where. Let's say you're the loading screen. The extreme is black. You can. How about we just reduce the cycle count. Or how about we just pretend the CPU is not running at 33 MHz but now it's running at 1 GHz and let's see what happens. And sometimes it works. And so now people are happy. They say, oh, there's a loading screen from 10 seconds and now like half second. That's awesome. But you're right, it's hard to know. Sometimes we have to patch it. I haven't found. Maybe AI will have in the future, but I haven't found. I don't think we have found a good way to do it at scale.
- [18:42]
Kevin Ball
This episode of Software Engineering Daily is brought to you by Capital One. How does Capital One stack? It starts with applied research and leveraging data to build AI models. Their engineering teams use the power of the cloud and platform standardization and automation to embed AI solutions throughout the business. Real Time Data at Scale enables these proprietary AI solutions to help Capital One improve the financial lives of its customers. That's technology at Capital One. Learn more about how Capital One's modern tech stack data ecosystem and application of AI ML are central to the business by visiting capital1.comtech.
- [19:22]
Bill Litschauer
But what does happen over time is the like the success of an emulator is generally measured how well the games run, but by the broadness of its compatibility. So as you play more games or you work on more games, you find more and more of these timing issues or other bugs and then some of them will fix many other games that use a similar system or similar architecture. And so over time, the more games you produce, the more robust your emulator becomes. And so you broaden the compatibility and so you're looking for 90% plus compatibility so that you pop a game in your emulator and it just runs. That's the ultimate goal and there's less work to do. But you know, for PS2, for example, because it was significantly more powerful, there are performance issues. So there are per game fixes that we have to do on a pretty regular basis with respect to performance and sometimes with the GPU as well too. There's graphical glitches that happen. Like Robin said, you'll change the timing of one thing and it'll mess up something else indirectly.
- [20:30]
Robin Lavallee
Going back to timing, sometimes there are legacy bugs. Let's say there was a game on PS2 that would crash. I don't know 1% of the time when you were doing pulling this level. Well, it's possible that because the timing of the emulator just we change it that now this legacy bug happens 100% of the time. And so now you actually. I guess you have to have a choice. Either you figure out, you fix the legacy bug itself. You're like, all right, this code was actually wrong. Let me fix it. In our LUA patch, we use LUA as a scripting language for patching. Or, well, you figure out whether the timing is off animation and change it. And now we're back to that 1% occurrence. And you're like, all right, now we're back to the Gessi state.
- [21:07]
Host
Yeah, I want to dig into that patching in a minute. But first, so we've talked a lot about timing as one of the sort of challenges when you move from a legacy system to a new system. Are there other classes of problems that tend to show up when you're moving systems like that?
- [21:24]
Robin Lavallee
I mean, there's. From a less technical perspective, there's all the texture replacement we have to do sometimes. So if you're going from PlayStation to position, that's easy. Like, you know, X square, triangle, circle. If you're going for PlayStation to switch now, you have to use A, B, X, Y or Xbox, where A and B is reversed and whatever. And now those textures, they might be in the game, they might be in movies. We got to replace them. So how do you replace them? Do you replace them on the disk itself, like the ROM file? Do you replace them at runtime, like, you know, when the. What about if the game is modifying those texture dynamically, like it's loading at X square, then doing, I don't know, some. Some replacing the pixel there or seeing some effect there. There's all kind of challenge there.
- [22:06]
Bill Litschauer
Yeah. And especially with some of the older games, too, there are things that are not necessarily appropriate for today's climate in certain games or the license has run out on certain them, Especially like sports games, you know, like, there might be an advertisement, you know, in a tennis game, there might be an advertisement for. Or Adidas that needs to be patched out. And of course, the famous example is the Red Cross. Like, healing packs in the old days were all. Almost always health. You know, health packs were red crosses. Well, that's copyright of the Red Cross, the organization right now. So we can't use that anymore. So we have to patch that out with a different image every time that appears.
- [22:44]
Host
So let's maybe talk about then what that patching looks like, both from an implementation standpoint. Like, is that something that you do at the syrup SDK level? How does that work? And then also, like under the hood, what is actually happening? You're starting from this legacy binary. Like where does the patched code end up?
- [23:03]
Robin Lavallee
Yeah, so most of the patch are. We have a LUA runtime. LUA is very easy. If you have never used it, I suggest you do. I know it's. Let's go on a tangent here. Python is very popular. JavaScript is very popular. But for LUA is very easy to compile and embed in any program. Like, it's like I think 5C file. It compiles very easily. So that's why it's so popular with game development. Like if you play the Sims from ea, it has a Lua, you know, engine there. Many other games have LUA anyway, going back. So we have LUA script file. Basically each game will have its own data file and then there will be like a directory with a bunch of LUA patches and, you know, implementation there. We also do our trophies and achievement in lua. So I think it's similar to patching where, you know, the, the logic in LUA will run and we'll say, well, you know, let's take it. I don't know what game micromanage again. You want to know how many boxes you have destroyed in the game. Well, maybe there's a counter in the RAM that tells you how many bugs you have. It's a buy somewhere. Well, the LUA script will just have this address there and just read it like, all right, is it. What's the value? If it's higher than 50? All right, then call this function in our SDK, unlock this achievement. Bang, you're done. So those LUA files are actually a programmer writing them. Like, you know, there's just like, you know, this is your like usual script file. And then they're being hooked. They're found Sync. LUA is so easy to use. They're found dynamically. So at runtime, you know, we just look through the folders, find out the UI file, load everything and like there's some entry points and shop them and then you just call the function there. That's for trophies for patch. I think it's very similar. I think we just replace. Like I said, I'm being a bit out of my patch. As far as I know, we either like prevent memory from being written or replace code. Totally. Like, you know, like again, going back to that function I was telling you about, like, if the game called this function, then instead of run this code and then in Lua we say, well, this is the new code, blah, blah, blah. And so this way we have fixed some incorrect there's some PAL game, NTSC to PAL game. So a PAL game, we're running at 50 frame per second. At 60. Well, there's no more TV running at 50 FPS now the TV's gone at 60, 120 and so on. So what do you do when you convert from 50 to 60? Well, it depends on the game. Maybe the game was. And some games were incorrectly converted, like they actually run slower on the 50. So can you make them come run faster? Sometimes you can. Sometimes you can. You can. If the game is frame based, then you know the whole game. I think you can just like run it faster. If the game is time based, then depending on how it was done, it really depends, maybe the physics would break, things like that.
- [25:37]
Bill Litschauer
I think one of the cool things to add just to the LUA side of things, especially when it comes to trophy implementation, is the reverse engineering aspect of it. So when you're playing the game, you're trying to find out, like Robin said, where in memory a particular value is being stored. And it's interesting how that's done. Do you remember back in the Flash days when I worked on Flash games, we used a tool called Cheat Engine, And Cheat Engine allowed you to basically find those values in memory and then change them. So if you wanted, you know, a thousand gold coins, you could find that value. But the way you would find that value is you'd scan memory, you'd play the game and you'd see, okay, right Now I have 52,300 points. Okay, so then you'd look, scan through memory for 52,300, and there'd be like a thousand registries with that or addresses with that amount. And then you would modify your score out of it. So now it's 60,000. And then you would scan again and then you would whittle it down until you eventually get down to this, to the exact memory address and you know exactly where it's being stored then. And then from that, that's when you can, you can use LUA to find out what the, you know, the score is or the number of deaths or the number of hits or whatever that happens to be counted, if it's counted. Sometimes things aren't counted and it's very difficult to track those things. Incidentally, that is the most common thing that we get asked is trophy support. I mean, that is a number one request from a business development standpoint is everybody wants trophies and it's huge. Super popular.
- [27:07]
Host
Yeah, Yeah.
- [27:07]
Robin Lavallee
I just look at the LUA script and that's that's exactly it. We. You have a hook that check for an address and then you know, the. The CPU will say oh, inner temperature will be like oh, do we need to. We have made a table first, you know, so we know exactly when to call this. And then the LUA hook will just like, you know, read this memory, write this memory and then add some logic there. Like oh, are you trying to. I don't know, is this the wrong font or something? Some texture was wrong maybe. Can we do an optimization here? Like the game was doing a tight loop here. For example, mentioned the VSYNC at the beginning. Like some. Some game would just like loop until Vsync like a million time. Well, we're just wasting our time here because we want to run faster or something like that. Just remove that loop. So if you call this, just pretend the condition is true, put back the memory there, return from lua and then the guess the game continues and boom, it flies.
- [27:55]
Host
That's fascinating. Yeah. Okay, so you talked a little bit about trophy support. And so this is one of the really interesting things here is you're not just emulating the old game as it was. You're now augmenting it based on requests from clients of different sorts of. So can we talk a little bit about what the different types of augmentations you get asked for are or what syrup supports? And are there any that implementation wise are more than. Here's the spot. Insert the LUA code.
- [28:24]
Robin Lavallee
Go Bill, just for the high level. And I can go to technical detail after.
- [28:28]
Bill Litschauer
Sure, yeah. I mean trophy support and achievements, that is the number one load time improvements are definitely another thing. Being able to speed up when the characters are talking and it's just going so slow across the screen and people just want to speed through it. Being able to skip through that, skip through dialogue, that's a pretty popular request. The widescreen has been particularly popular. I think the most complicated one, which Robin will need to Talk about is NetPlay and adding that we implemented that for Micro Mages. That was something that the original game did not support and we supported it on PlayStation. That comes with its own can of worms. You know, with one player, the game's fine. Two players, it's not that bad. But then when you get to three and four players, which is what we support, well, it gets very complicated. Like you have to think about all the TRCs or technical requirement checklists that Sony will check for when they're doing their certification check before it can be published. What happens if Player 3 disconnects their controller. What happens if someone joins mid game? What happens if someone, you know, you have two players who are local and two players who are network, you know, from different countries. What happens in those cases are the PS IDs showing the PlayStation IDs displayed. How do you handle that? Is it a lobby, is it a matchmaking system? Like there's all kinds of different things and the complexity grows very quickly. Even going from two to four players, it grows very, very quickly. And ggpo, you know, we can talk.
- [30:03]
Robin Lavallee
About that a little bit.
- [30:04]
Bill Litschauer
But I, I will say, you know, from a non technical standpoint, GGPO is great for fighting games. That's basically what it was designed for so that you, you have this rollback system and you. It's for tight performance for, for fighting games where performance is extremely important. We went with GGPO and in hindsight it came with its own challenges because we weren't using a fighting game, we're using a 2D scroller. So we were working on something that's not perfectly well suited for that particular genre of game. So that made it more challenging than it maybe needed to be. But yeah, I think I hand off to Robin here to talk about ggpo because he was involved in the last push to get it fixed.
- [30:50]
Robin Lavallee
I guess one of the issues with GGPO is it synchronize everything. Like, you know, fighting game is easy in the sense that you have two player fighting if you replicate each people's input and you do prediction. So I don't know if your audience know about ggpo but basically you try to predict like if you're pressing the right button on your D pad on frame X, it's likely that you can still be pressing it on frame X plus one. Right. And so using that assumption, you can, if you're a client doesn't know yet if the other person has pressed the D pad right, but you know he has pressed a frame ago, you can probably simulate that. Yes. Press it again and you just go run the game with that. At some point you receive the packet of the network. It'll tell you, hey, is a D pad state of that player? If it matches your prediction, all good? So you were able to save time and do. If you got it wrong then now the state of the game is wrong because actually you submitted the, you were pressing right. Actually the guy pressed left. What do you have to do? Well, you can't send. It's a deterministic game now. You got to go back in time to the previous frame Resimulate as if it was pressing left now and then figure out the new frame that you just did. So depending on how laggy you are in gtpo, you might see like, like little glitches, things going weird. The fighting game is I guess it's okay because you know, like, you know, punch like. Oh yep. I guess something happens. Obviously if the lag is low and the latency is very low, it's happening less often. But it will happen every time you press a button you're about to get. The GPU doesn't know about the game. Like it's not game aware. So if you're about to jump, every time you're about to jump, the prediction will be wrong by a frame or two. And so you will see yourself like a little bit like you know, glitching on the jump, things like that. So but it works at the end of this disability these system is deterministic. It will always stabilize itself. Just. It may get some like weird issues there.
- [32:38]
Host
So just to make sure I understand, ggpo, which we're talking about here is kind of a. It's a networking stack of some sort that allows you to kind of synchronize game state across distributed systems. And it is sort of a predictive one. So it's saying like in a lot of cases we can sort of optimistically assume that these sort of continuous things and that'll get us most of the way.
- [33:00]
Robin Lavallee
There's yeah, correct. It's not game aware. It's not even like, you know, it's not a rendering engine. It doesn't have networking stack. I mean it has a little bit of like little bit UDP stuff but it's on. It's just a. Here's the state. Here's the state I think you have. Here's the state I think I have. Here's the combined state. You got it right, you got it wrong. Here's how you fix it and so on. And then the game is responsible for rewinding the state and going back. This work well for the NES game. But it forces you to run multiple frame in a single frame. You say you got it wrong by five frame. Let's say actually you simulated things for five frame and to figure out oh geez, I was wrong five frames ago. Now I need to go back in time five frame. First I need to save that state and then I need to reapply those five input there. So I need to run those five frame within one frame of the game. If that's running those five frame takes Longer than the time you allowed. You just start lagging behind forever, never catch up. And things would get really bad. So performance become important. Like you'd be able to run the original game five times the speed of the. So what about sound and vibration? Like I just talk about the game, the game state, like, you know, RAM and things. What about, you know, controller was shaking like, like the enemy hit me and because of that we started vibrating the controller that you're holding. That's cool. Turns out I was wrong. The enemy did not hit me. They go back in time, it did not hit me. All right, cool. Now we're not vibrating anymore. But the game doesn't know about that. It's not going to send a stop vibration because it never sends a star vibration. Now we need to add custom code to stop that. So anything that's like programming a pure function, anything that's not pure that's basically leaking out will break. Could be like I mentioned, vibration, could be sound effects if they're not. If they're done that way. So little thing like that, I mean, it's not too bad. Worst case, it just vibrated a little bit and it stops. You'd be like. And maybe you thought you got hit, but you did not. Okay, but you know, it's silly. Things like that happens.
- [34:54]
Host
I mean, I think this, this adding multiplayer support to me is fascinating because you're adding it to a game that was not multiplayer aware. So there's like whole classes of problems like you're highlighting of like rewind, restart and synchronization that it just like has no concept of what is the span of that? Like that just. That feels like a massive endeavor.
- [35:17]
Robin Lavallee
I mean, going back to the fighting game. I mean like the title screen, you won't synchronize it. Like the game that, like, where do you do matchmaking? Well, how do you start the game with the two players? So we have a safe state actually. So we did. We like, you know, we put the game like we, we ran the game with two player locally or four players and we say, okay, this is the beginning of the level. Now we made a safe state there, like memory snapshot of that, put that in. Indeed. Found somewhere. Now we do the matchmaking on PlayStation 4 or 5. Find the players, blah, blah, blah. Okay, cool. Start the game. Everybody agree? And now all the players will load the same save state together at the same time. And now we start GPO there and then everybody's synchronized. So there's a bit of. Again, see, GPU doesn't know about this, it's just being told, like, by the way, you are now synchronized. But we need to know because the original game did not have matchmaking. The original game did not have like, you know, find the game and find the players and you know, what kind of game you want. So. So now we toy around, like, how do we add. Can we add easily networking to any games in the past that were like co op game? I mean, it depends on what the game was doing and where do you put that?
- [36:29]
Host
Right. So it's. It is still just. It is games that were multiplayer, but multiplayer locally. But then. Okay, so that does narrow the scope a little bit. Because I was imagining you're taking a single player game and adding a multiplayer mode and I'm like, whoa, what is even.
- [36:43]
Robin Lavallee
That would be harder. No, you need to have support for multiple controller there. But then there's another set of challenges. What about games that say that were multiplayer but that you want to add multiplayer? We haven't done those yet because they.
- [36:57]
Bill Litschauer
May have their own protocols. But we do rely on. We have to use PlayStation's SDK and Xboxes and switches. And we call into that, like Robin said, we call into that their matchmaking system and they have their own PlayStation IDs and you have to subscribe to get all that stuff. So you can have online play and then it's sent to ggpo.
- [37:16]
Host
Got it.
- [37:17]
Bill Litschauer
You go from there.
- [37:17]
Host
That's still super cool. Okay, Bill, you were gonna mention some other domains requests.
- [37:23]
Bill Litschauer
Yes. Okay, so Robin mentioned save states and that's what reminded me. How could I forget? So one of the big features that our emulator has is rewind system, and this is pretty common in a lot of emulators as well too. So as we have all these save states, we're able to. The player or the user is able to use a rewind system and go back to a save state that they want to. So if they're trying to get through a boss fight and they can't do it and they don't want to, they keep dying. They can just rewind, you know, 20 seconds or whatever, however far back they want to go and replay that over and over again. Which really helps with QA when we're doing our trophy testing. So when we do trophy testing, what we'll do is we'll get to a particular spot and then create a save state, and then we can reload that and start from that area so you don't have to play through the entire game to unlock a trophy. It's like Beat the final boss? Well, no, you just have to get the save state from that particular point. So rewind is popular. Up rendering is another thing that is requested to improve the graphical quality of the game. Sometimes post processing effects. So let's say you want to add a CRT filter or an arcade filter to make the game look even more retro. You know, adding scan lines, we can do that. Custom audio, visual, contextual button remapping. So if you want to be able to remap and actually controls is a pretty big issue that Robin could talk about more. Especially when it comes to PSP. Because PSP had a different controller than a PlayStation 5 controller, which is very different from Switch controller. So there's that as well too. And of course, adding rumble. Like, you know, games didn't have rumble in the past and now they do. So we were able to.
- [38:56]
Robin Lavallee
I want to add something about aspect ratio. So we're doing one game. It's a PS1 game. So PS1 game, if you remember right, they were 4 by 3. All right, TV now or 6.6 by 9. All right, so you're gonna get letterbox. But that game was also widescreen 4 by 3. So the game itself was rendering as if it was a widescreen game in a 4x3. So now if you convert that without thinking about it, you're gonna get a black. Black box all around like. Like a stem. That looks terrible. Now we can actually zoom it. So we. We made some change to zoom the game. Now we're back to 16 by 9. Except one problem. The game would display. Sometimes it's HUD under that black bar at the bottom. So now that would be hard to the screen. Well, LUA comes to the rescue. We can use the LUA hook to like just move that back up. And it seems to work. It's like we haven't finished the game yet, but, you know, now we got a PS1 43 game running 69 as if it was 69 originally because they were living 69 in the 4 3. Convert it back to 16:9. Anyway, it's per game stuff again.
- [39:55]
Host
Yeah, that's wild. So on that kind of note, are there particular types of games that tend to be more challenging to emulate or port? Yes.
- [40:07]
Robin Lavallee
I mean, it really depends on. Some games are more performance heavy. Like we have one game we're working on and we're able to do enough optimization. It runs at 60fps now. And we're like, all right. And it uses, you know, it's more tolerant on the code. Like it's using like the MDEC. MDEC is the media decoder of the PS1. And then, you know, the way it's using it, we're able like to cheat. It's asking for like, I think, I don't know, a buffer and we return it immediately and then the game is happy about that and it's playing the movie and everything is fine. Some other game we're trying, we did that and bang, the game doesn't like it at all. Like the game expect probably that timing delay I was mentioning again. So now we actually need to emulate the ring buffer of the M deck properly. In which we did. We did not do it yet. And so we're like, ah, geez. But we probably have to do this anyway because I expect more games to require this anyway. But we're just looking the first game. So I think it's a bit like you do one thing, you know a little bit about it, you do two of them. If you do three pre prime number you, 3, 5, 7, you know, 11, at some point you probably get a bigger coverage of, of everything that the game required.
- [41:08]
Host
That makes sense. Can you talk at all? We've talked about a bunch of systems switched and things and you sort of alluded, oh, PS3 might be one of the upcoming opportunities. Can you talk a bit about that and your plans there?
- [41:22]
Robin Lavallee
Good question. PS3 is a big platform. I mean the way I see it, we got PS2. PS2 is running right now on PS5 and PS4, so maybe PS3 would be on PS6. So who knows. One of the big challenge I saw with PS3 is the memory. I mean there's some advantage to disadvantage. You know, going back, PS1 and PS2, they were not modern rendering pipeline, they were like kind of like, you know, Lego blocks. Like the, I don't know, PS2 as its CPU as a VU0 unit V1 and then there's also another E. And all those things are like. There's no like graphic pipeline on the PS2. So it feels weird. On PS3 you're starting to get close to an actual like, you know, normal graphical pipeline. But you get some, you get now SPU's, there's like eight CPUs on that machine. And that doesn't really translate well to like a modern hardware either. The other big challenge I see is I think it has 512 megabyte of RAM. And so if you just like, you know, we're just gonna save the memory of that every frame, you're going to be saving like, you know, a few gigabytes of every second and that won't scale. Thing is that most games don't change all the memory. They just change a few bytes here and there. I mean not a few bytes, but so maybe we can use paging technique. And so like, you know, oh, those pages changes. Like let's swap them to memory. Now you have like almost like ADPCM compression between the frames. So in order to like look like a video decoder, like in order to see frame X, you need to have like the previous frame and then you apply like the delta on that. You can't do like lossy compression like on video to be like, if you do lossy compression on bits and bytes, you might get some weird effect. The game. I think this is a big challenge there. I think it's going to be easier on the system software. You know, the, the game where like I am saving here, I am asking for networking. I am changing the resolution. Like on the old game it was like, you know, there's no hdmi. There's. It's like, oh yeah. I think this game is running in this resolution because it sends some few packets and register here and the documentation is not clear. I think the system calls actually make it easier. Like the separation between the OS and the user runtime makes it easier to inject yourself. Like, okay, the game is saving here, let me save on my Xbox. We didn't talk about this media size. There's a lot of data. We use Google Drive, we use GitHub. But you know, the PS3 games we're talking about, the PS2 games, they were like, you know, a DVD size sometime and there are multiple regions sometimes times. So by reasonable regions, I mean like there's a European version, a Japanese version, an American version. You need to support all those versions. If you want to run the French version of a game, then the data for the French language was only available in that French ISO file. So now you got, you know, if it's a PS1 game, for example, 600 megabytes times 3, 4, 5. All right, a few gigabytes, it's a PS2 game. Now you get the same thing, but at the 4 gigabyte level times something. PS3 games, I don't know, Blu Ray, I haven't checked, maybe a few 20 gigabytes. Sometimes it looks easy, but you know, we're developers, you know, you need a hard drive, SSD and so on. Like you're, oh, let me test this game. All right, I need 20 gigabytes here 20 gigabytes there, 20 G ads up and then you're testing with QA. Let's make package. All right, I'm gonna make a, a package of this. And now it's 100 gigabyte. Put this on Google Drive. Somebody has to download it. You know, you need to have that gigabyte gigabit per second connection. And we do have that, but it puts a strain on the overall. Like now we're going on build system and Jenkins and GitHub and you know, they need to swallow those. This data. You can just say, oh yeah, just mount the file system and copy it every time. People like to do this in the cloud. Like, you know, use Docker and just spawn the os, spawn this thing. Like, well, it's going to take a few like 20 minutes every time and you're gonna cost you a lot. So don't do that. And so we don't do that. We went almost anti cloud. We have like custom physical build machine in the basement in people's room. And then they're connected to GitHub. And then those machines, I mean they cost a lot and they have to maintain them. But guess what? You can put whatever hard drive you want to those things. And there's no like Docker. And it's actually pretty fast.
- [45:24]
Host
Yeah, it is interesting the sort of scope of data that you end up talking about here when you're, you know, having to send this whole image over and every time you want to test a change, you need to update things and all of that. Yeah, that, that's fascinating. And it would push you towards how do I shrink the distance between my data and my processing machine?
- [45:42]
Robin Lavallee
The data, the distance between the data. Because we were talking about physically, we need development kits. Like you need a switch, you need Xbox kits to work on this thing. Might say, well, cool, I'm going to put it in the data center somewhere and that works. And then connect remotely to it. That works too. But what if the data is on your PC and you're constantly changing it like a few bytes on that. Remember that patching was telling you about the rom? Like replace it that X texture and okay, cool. You do it in the 20 gigabyte file. Now that data center that you connected to needs to read that file. Or maybe it needs to. So hopefully it only reads a few bytes of it. But if your tool is dumb, it's probably trying to open the whole file and read the whole thing and pushing 20 gigabytes every time. Now you need to optimize this thing. But it's just things you don't think about because when you're working locally, data is just there. But it's actually a challenge. I think solving that challenge efficiently put us ahead.
- [46:30]
Bill Litschauer
So one thing we could talk about is the auto testing system because that's something really cool that we have to. When I was mentioning earlier about the compatibility and the broadness of compatibility. So how do we check if there's been a regression in the games that we've done? And so we have an auto testing system that checks hundreds of games every night it runs and it checks all the different games that we've produced against all the different consoles that we support. And it can detect images, it can detect code changes, if it'll boot. So that type of thing. So Rob, maybe you've worked on this a lot.
- [47:07]
Robin Lavallee
Yeah. So it's basically based on GitHub. Actions could be based on anything, but it's based on lovely YAML file. No opinion here. And then it runs on the. So we have like runners connected to GitHub and then we have like I mentioned, like hardware, like Switch Hardware, Xbox hardware, PlayStation hardware and they would just run test scenarios. Basically most of the test scenarios are pretty simple. Like run this game, take a screenshot at frame 20 or take a screenshot after five seconds. Now we have reference screenshot like I mentioned, like the Nest game of Deterministic. So we have all those reference image and we have the image we just took. We compare them and if they're the same, well, cool, thumbs up and Slack is happy. And if they're not, then we actually create a HTML report and it's on the gist file, you can click on it, you can see like the expected image, the new image and the difference. We just do a delta. Then you can see like, oh, something messed up sometimes. So it works and it doesn't work. So it works because it allows us to have like good reliability. Like you know, if you run 100 games because you don't want the engineers to test 100 game when they make a change, right. That's going to waste their time. And so. But sometimes there's false positive, right? They'll be like, oh, this game is just like, I know the military is a bit wrong there or maybe the dev kit is down. You know, it's actually a physical machine like I mentioned, by the way, the cloud is also made of physical physical mission. You don't see them, but somebody's taking care of them for you. But it's just physical mission. At the end of the day. The networking is also something to manage. Like you know, first we need networking to be easy. So we use tailscale which is based on wireguard. So that's cool except we're not network expert and we also need to be careful about this is exposed to the public Internet. And so we don't want people to just join in and start hacking our kits and code and stuff. But yeah, the autotest runs, it runs on every commit we do. We try to make them fast. Obviously there's a constraint on like, you know, if you're on a switch test every commit and you only have like three kits on switch and there's you need to add more kits. Other tests we're looking at is not just screenshot tests but just like, you know, scenario test, you know, like there's a rewind system. Make a snapshot and reload it. Confirm that it's the same value. How about the logs? You know, the game starts and we expect a certain like you know, certain logs or asserts never be sent. Well check, check for that. And so, so we have lots of heuristic like I wouldn't say people like to write pure code. I believe a bit more heuristic. So if you do enough heuristic because at the end of the day humans will be interpreting those results, I mean and then reading them. Oh, it fails because. Okay, here's why. So, so it's good to have it 100, but I don't think it's very achievable. So I'm more the case that you.
- [49:36]
Bill Litschauer
Know, heuristics are better.
- [49:38]
Host
When you are writing these tests, are you able to essentially record play sequences as well where it's like oh, the controller is behaving in this way. Run it through these different pieces and then see what happens.
- [49:49]
Robin Lavallee
I believe we have done that for a few there. Yeah. So for example like going in that menu, going make a snapshot, saving it and reloading it. Those were recorded. We're trying to get QA to do a bit more of those recordings either in lua, like, you know, do we record high level or do we record like input replication like most like GDPO but with a file. We even did some OCR thing. It might sound funny but when the PlayStation dev kit reboot of PlayStation 5 you have, there's a screen that shows you that tells you like hey, you shouldn't have turned up the power. Like if you had a hard power reset, it tells you like this is what's wrong. Press X. There's a way to Bypass the screen. But before we knew about it, we use a AWS OCR recognition. Just recognize the screen there. Like oh, it tells you to press X and then we just send input to press X. We also had to. I just mentioned power cycle. So we have like no outlet or smart outlet. You know, like the console tried to reboot it, tried to connect to it. If nothing works, what about well, turn off the power and turn on the power.
- [50:42]
Host
Can you.
- [50:42]
Robin Lavallee
So now we do that remotely as well. I'm gonna kind of scary that to know that GitHub action is like playing with electricity in but it works. And going back to aws, when you go on on Amazon and you reboot your instance or the instance goes into some kind of weird state, it's probably doing that too. It might be sending power and just like, oh, this machine is just dead. Restart it. You just don't see it. But it's doing that.
- [51:06]
Host
So one last topic we haven't talked about that is kind of more on the business side of this, which is like who pays for this type of emulation work? Who are you selling to? Is this end user sales versus your pitching publishers? Like what does that business model look like for game emulation?
- [51:23]
Bill Litschauer
So it's mainly business to business. But there's two ways we're looking at it right now. So we have sort of the work for hire branch of the company and so we work with a number of publishers. For example, we're working with xseed Marvelous on a game that's going to be announced soon. We're working with Bloom, did run games on Fear Effect and a few others that we can talk about. So we're doing their PS1 ports for them. So they're paying us to do the emulation work and the trophy design work and trophy implementation and all the TRC checks or compliance testing that that's required. But what we also found is that we would get requests from smaller studios, really small studios. You know, they've sold 300 copies of their game, a NES game for example. But they would love to have it on Switch. They only have it on PC right now on say Itch IO. Well, it's not really cost effective for us to be able to port that game for them. And we get a lot of these requests but you know, it's not economically viable as they say. So what we've decided is to go the SDK route. So the syrup SDK is something that we're working on right now. It's in the alpha stage and we're Going to give that power to the developers and to the smaller studios so that they can put their games through our SDK and then launch, do the port themselves using our tech. And so that's in alpha. And we have a company working with us right now and he's going to be launching nine games on the switch really soon. They're all NES games. So within three months we'll have our first games published through the SDK. But typically we are working with publishers or studios to get the games done for them. Sometimes we will pitch the games ourselves. So if we think that a game has the potential to do really well, we'll pitch the publisher and say, look, we think this game is awesome. It did really well in the past. It was for example, only released in Japan and we think it should be released to a North American audience. It has a current demand from the community. It's not in licensing helm, because that is really the number one blocker for all these games is licensing who owns the IP and who owns all the licensing within the tech, so within the game itself. So who did the vo, who did the music tracks, who did the, you know, all the different things, the artwork. Everybody owns little bits and pieces and sometimes even the studios don't know if they own the IP or not. So we'll pitch it to them like, yeah, that's a great game to work on. Let's just verify the IP that we actually own it and then it come back a few weeks later. It's like, oh, we actually don't own that. Five percent of it is owned by the estate of a long lost person in Japan and we're never going to get that permission. So we look at a number of factors. We obviously look at the financial opportunity, we want to make sure that the game stands the test of time and that still works really well in today's market. So like pixelated pixel art is obviously really popular right now and has been for a number of years. So that works really well from a lot of NES games and SNES games and any of the 16 bit era games that work really well. So you know, those are some of the factors that we look into when we're working on things. And in that case, if we're pitching a game, usually it's going to be a revenue share agreement. So we're going to take a cut of the sales, the publisher is going to be taking the cut and we're taking on the risk of the development of the game because we believe so firmly in it. But you know, the Vast majority are work for hire. So we're doing work. We reach out to a publisher, sometimes cold and say, hey, you know, we're good at this, do you need it? And then they'll be happy to work with us. Other times they'll come to us and say, hey, I heard you guys really know PS1 games or NES games. Can you help us with these ones? And then we work on an agreement and deliver them.
- [55:16]
Robin Lavallee
Yeah, our goal is really to push all those games that are like, you know, people think Call of Duty, okay, we can't do Call of Duty. Plus someone is doing that. And there's all the, there's a lot of low hanging Fruits game. Like they didn't sell a million copies, but they didn't sell 100 copies either. They sell maybe the 10,000 copies or 50,000 copies and nobody's doing those games. And those games are just lost right now. The only way to play those games is through piracy or you know, and then we're like, what if we could scale this to make it so what my bill was mentioning, like we can talk with the publisher. They would be like, cool guys. We actually found, you know, the, the owner. We can do it, but only 50,000 copies. It's going to cost us more than like legal agreement and stuff. Marketing. We're not doing it. What if there was a way like you know, YouTube, Spotify, Airbnb, SDK way to scale this in such a way that, you know, people either the ip, owner, developer could use this technology and then self port the games and then everybody gets a cut. You know, people makes money out of it because people enjoy it. I guess Netflix might be the example. So I'm not saying we're going publisher route and going there, but it's just like the vision is there where I believe there's, you know, there's a big loss of retro games and there's two market for those games. There's the market of people like Bill and I, we would play those games in the past and want to play them again because nostalgia. But also the new market, there's newer kids that they now have, you know, they're 20 years old, 30 years old, they never play those games actually. And some of them, some of those games are actually good. They're still good. Some are crap by the way, but some are good and you know, they would pay for it if they were given the chance like on the switch, like, oh, $5.99, I'm gonna pay this. But they can't right now. The only way they can pay the playoffs game is find them randomly on the Internet and download them. And nobody, nobody's making a buck out of this. And I think there's thousands of those games.
- [57:00]
Bill Litschauer
So yeah, especially when you look into other regions. You know, we're working on a game that was released only in Japan. You asked about features. Vocalization of course is a feature that we provide as well too. Both the audio and visual side of things. That's a very popular request as well too. But anyways, we're working on a Japanese game that did really well in Japan but was never released in Europe or North America. And so we want to bring that. And there are tons of those games that were local to the Asian market and never came across to our markets. And so there's a real opportunity there because there's gems, there's hidden gems out there and we want to make them available to as many people as possible.
- [57:46]
Host
Awesome. So we're right about at the end of our time. Is there anything that we haven't talked about that you think would be important to leave folks with?
- [57:54]
Bill Litschauer
Well, I have one thing. I think one of our.
- [57:58]
Robin Lavallee
Things we're.
- [57:59]
Bill Litschauer
Really proud of is our community. Our community works. I mean they're incredible what they do. Our head of community does an outstanding job managing that. So you can find us implicit conversions.com and we're on all the social medias, but really on Discord we have a really active and engaged community who really are passionate about retro games. And you know, we get a lot of ideas from them. They submit bug reports for us, they ask for features, they rank games that they want that they're interested in. And like Legend of La Gaia for example is a game that has come up numerous times. And Simpsons Hit and Run that keeps coming up. You know, they want us to do these games so that gives us some valuable information that we can then use to pitch games. Or you know, if we're in discussions with some of those third party publishers, you know, we can share some of that information. But it's an outstanding community so if people want to join that, please do.
- [58:52]
Robin Lavallee
Season three mentioned about other up rendering would work like so for example like PS1 game ability were 320 by 240. So if you just take this frame buffer and put it in the hdtv, well cool, you got HD graphics but it's still HD graphics of like you know, the old game there you could if you remap like the render call like you know, draw this triangle, draw this mesh to actually like a PS4 or a switch OpenGL. So a switch with OpenGL call. Then you can use a different frame buffer size, different target and then render the thing higher resolution. Now you get like those little hedge that would be like seem like big thick pixels. They're going to look like very tiny, like thin. Except the texture would be wrong. Like the texture that was used must still be the low resolution texture. So now you get like nice mesh with low resolution texture but a bit better there maybe I also get some scenes issue. Like you know the game was like rendering like the floor and maybe the wall there and then now it's high resolution and maybe there was like again legacy bugs there. Now the legacy bug, there's a floating point error and now you see through it at the end. So these are some of the features up rendering features that we want to do more. You know sometimes you have to remove stuff. Games were using Blur back in the 90s, 2000 a lot of games used Blur. Like you know, it was cool. Like you're going fast in the car, use Blur, blur, blur, blur everywhere. That looks kind of bad on modern hardware. Like you actually want to reduce the blur because it's actually just remove the resolution or just remove it altogether. So going back to Lua patches there so. So I think there's a lot of work, interesting work actually. So people interested in like you know, gaming and solving problems and we always like, you know, something else to add. I'm always reading people sending us email or CV or resume the target audience. Like some people ask us like how do I get a job here? Well yeah, video game experience, console programming but a lot of passion that of like I work on the simulator, I like to toy around but they with a ns I, I do hardware, I do FPGA and I've been like, you know I do like conversion of NTSC to whatever you do if you're passionate about it. I feel like to sort of like the skill set that actually works really.
- [61:00]
Bill Litschauer
Well at this company.
- [61:02]
Host
Awesome SA.