Emulating Retro Games on Modern Consoles with Robin Lavallée and Bill Litshauer

26:22Super popular. Yeah. Yeah, I just look at the Lua script and that's exactly it. We have a hook that will check for an address and then, you know, the CPU will say, oh, our temperature will be like, oh, do we need to, we haven't made a table at 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 it the wrong font or something, some texture was wrong. Maybe can we do the optimization here? Like the game was doing a tight loop here. You mentioned the Vsync at the beginning, like some game would just like loop until Vsync like a million times.

26:58Well, we're just wasting our time here because we actually, 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 game continues and it flies. That's fascinating. Yeah. Okay. So 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. So can we talk a little bit about what the different types of augmentations you get asked for are or what Syrup supports?

27:34And are there any that implementation-wise are more than, here's the spot, insert the Lua code? I'm going to go, Bill, just for the high level. And I can go to technical detail after. Sure. Yeah. I mean, trophy support and achievements 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.

28:17We implemented that for micromages. 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. 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 three disconnects their controller? What happens if someone joins mid-game?

28:51What happens if you have two players who are local and two players who are network 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 about that a little bit. But I will say, you know, from a non-technical standpoint, you know, GGPO is great for fighting games. That's basically what it was designed for.

29:29So that you have this rollback system and it's for tight performance 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. I guess one of the issues with GGPO is it synchronizes everything.

30:10Like, you know, a fighting game is easy in the sense that you have two-player fighting. If you replicate each people's input, you do predictions. So I don't know if your agents 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're still going to 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 he has pressed it again, and you just go run the game with that.

30:45At some point, you receive the packet of the network that will tell you, hey, here's the D-pad state of that player. If it matches your prediction, all good. So you were able to save time and do it. If you got it wrong, then now the state of the game is wrong because actually you simulated that you were pressing right. Actually, the guy pressed left. what do you have to do well you can't it's a deterministic game now you got to go back in time to the previous frame re-simulate 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 ggpo 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 is low and the latency is very low it's happened less often but it will happen every time you press a button for example So like you're about to get the GCPO doesn't know about the game.

31:35Like 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, the system is deterministic. It will always stabilize itself. Just to make it, you may get some like weird issues there. So just to make sure I understand GCPO, 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.

32:09And it is sort of a predictive one. So it's, it's saying like in a lot of cases we can sort of optimistically assume that these sort of continuous things and that that'll get us most of the way there. Yeah, correct. Let's just say, it's just say it doesn't, 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 UDP stuff, but I mean, 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.

32:38And then the game is responsible for rewinding the state and going back. This works well for the NES game, but it forces you to run multiple frames in a single frame. You say you got it wrong by five frames, let's say actually you simulated things for five frames and figure out, oh jeez, I was wrong five frames ago. Now I need to go back in time five frames, first I need to save that state. and then I need to reapply those five inputs there. So I need to run those five frames within one frame of the game. If that's running those five frames takes longer than the time you're allowed, you're going to start lagging behind forever and never catch up and things will get really bad.

33:13So performance becomes important. Like you'll be able to run the original game five times the speed of the... So what about sound and vibration? Like I just talked about the game state, like, you know, RAM and things. What about, you know, controller was shaking. Like, look, 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. It 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 start vibration.

33:47Now we need to have 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 vibration could be sound effects if they're not if they're done that way so a little thing like that i mean it's not too bad worst case it just vibrate a little bit and it stops you'll be like and maybe you thought you you got hit but you did not okay but you know it's a silly thing like that happens 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 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 the 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 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 the memory snapshot of that put that in in the file somewhere now we do the matchmaking on playstation 4 or 5 find the players blah blah okay cool start the game everybody agree and now all the players will load the same safe state together at the same time and now we start the gpu over there and then everybody synchronize So there's a bit of, again, people don't know about this.

35:20It's just being told, like, by the way, you're 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 know what kind of game you want. 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 games? I mean, it depends on what the game was doing. Yeah, okay. And where do you put that? Right. So it is still just, it is games that were multiplayer, but multiplayer locally. Correct. 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 that?

36:01That 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 were multiplayer, but that you want to add multiplayer? We haven't done those yet. Yeah, because they may have their own protocols. But we do rely on, you know, 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. Got it.

36:35That's still super cool. Okay, Bill, you were going to mention some other domains. Requests, yes. 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 20 seconds or whatever 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.

37:15So 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.

37:49Custom 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 i want to add something about aspect ratio so we're doing one game it's a ps1 game so if you're just one game if you remember right there were four by three all right tv now is 6.6 in my night all right so you're going to get the letterbox but that game was also widescreen 4x3.

38:27So 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 going to get a black box all around. Like a stem. That looks terrible. Now we can actually zoom it. So we made some chance to zoom the game. Now we're back to 16x9. Except one problem. The game will display sometimes its HUD under that black bar at the bottom. So that would be out of the screen. Well, Lua comes to the rescue. We can use the Lua hook to just move that back up. And it seems to work. It's like, we haven't finished the game yet, but now we got a PS1 4.3 game running 69 as if it was 69 originally because they were learning 69 in the 4.3 converted back to 69.

39:10Anyway, it's per game stuff again. Yeah, that's wild. So on that kind of note, are there particular types of games that tend to be more challenging to emulator port? Yes. 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 60 FPS now. And we're like, all right. And it's more tolerant on the code. It's using the M-Deck. M-Deck is the media decoder of the PS1. And then the way it's using it, we're able to cheat. It's asking for, I don't know, a buffer. And we return it immediately. And the game's happy about that.

39:51And it's in 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 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 at the first game. So I think it's a bit like you do one thing, you know a little bit about it. You do of them, if you do three, pretty prime number.

40:19You do three, five, seven, you know, 11. At some point, you probably get a bigger coverage of everything that the game requires. 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 good question ps3 is a big platform i mean the way i see it we got you know ps2 ps2 is running right now truly on ps5 and ps4 so maybe ps3 would be on PS6. So who knows? One of the big challenges I saw with PS3 is the memory. I mean, there's some advantage to this advantage.

40:59You know, going back, PS1 and PS2, they were not modern rendering pipeline. They were like, kind of like, you know, Lego blocks. Like, I don't know, PS2 has its CPU as a VU0 unit, VU1, and then there's also their like 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 normal graphical pipeline. But you get now SPUs. There's like eight CPUs on that machine, and that doesn't really translate well to a modern hardware either. The other big challenge I see is I think it has 512 megabytes of RAM. And so if you're just like, you know, we're just going to save the memory of that every frame, we're going to be saving like a few gigabytes of every second, and that won't scale.

41:48The 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. Let's swap them to memory. Now you have almost like ADBCM compression between the frames. So in order to... Like a video decoder. In order to see frame X, you need to have the previous frame, and then you apply the delta on that. You can't do lossy compression like a video. 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.

42:22I think it's going to be easier on the system software. The game where I am saving here. I am asking for networking. I am changing the resolution. On the old game, it was like, there's no HDMI. 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. The separation between the OS and the user runtime makes it easier to like inject yourself like okay the game is saving here let me save on my xbox we didn't talk about this media size it's there's a lot of data we use google drive we use get up but you know the ps3 games we're talking about the ps2 game they were like you know a dvd size sometimes and they're multiple regions sometimes so by multiple regions i mean like there's a european version a japanese version an american version you need to support all those version 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 three four five all right a few gigabytes it's a ps2 game now you get the same thing but at the four gigabyte level times something a 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 You need a hard drive, SSD, and so on.

43:44Like, oh, let me test this game. All right, I need 20 gigabytes here, 20 gigabytes there. It adds up. And then you're testing with QA. Let's make package. All right, I'm going to make a package of this. And now it's 100 gigabyte. Put this on Google Drive. Somebody has to download it. You need to have that gigabyte 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 they need to swallow this data. You can just say, oh, yeah, just modify the system and copy it every time. People like to do this in the cloud.

44:13Like, 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 it's going to 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 then you have to maintain them. But guess what? You can put whatever hard drive in one of those things. and there's no like Docker and it's actually pretty fast. Yeah, it is interesting, the sort of scope of data that you end up talking about here when you're 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.

44:52Yeah, that's fascinating. And it would push you towards how do I shrink the distance between my data and my processing machine? The data, the distance between the data, because we were talking about physically, we need development kits. Like you need a switch development kit. You need Xbox development kits to work on this thing. You might say, well, cool, I'm going to put it in a 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 we're telling you about the ROM?

45:19Like we replaced it with 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 it's 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. 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.

46:00So 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. Yeah, so it's basically based on GitHub actions. It could be based on anything, but it's based on a lovely YAML file. No opinion here. And then it runs on the... So we have like runners connected to GitHub.

46:35and then we have like I mentioned like hardware like you know Switch hardware Xbox hardware precision 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 NES game on 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 an 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 and 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 games when they make a change right that's going to waste their time and so but sometimes there's false positives right they'll be like oh this game is just like i know the miniatur is a bit wrong there or maybe the dev kit is down.

47:33It's actually a physical machine, like I mentioned. By the way, the cloud is also made of physical machines. You don't see them, but somebody's taking care of them for you. But it's just a physical machine at the end of the day. Other networking is also something to manage. 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 experts, and we also need to be careful about it. This is exposed to the public internet, so we don't want people to just join in and start hacking our kits and code and stuff. But yeah, the auto test runs.

48:04It runs on every commit we do. We try to make them fast. Obviously, there's a constraint on like, you know, if you're going to run a switch test every commit and you only have like three kits on switch and there's more kits. Other tests we're looking at is not just screenshot tests, but just like, you know, scenario tests, you know, like test the 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 certs will never be sent, well, check for that. And so we have lots of heuristics.

48:34I wouldn't say people like to write pure code. I believe more than heuristics. So if you do enough heuristics, because at the end of the day, humans will be interpreting those results. I mean, and then reading them. Oh, it fails because, okay, that's why. So it's good to have it 100%, but I don't think it's ever achievable. So I'm more the case that heuristics are better. 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? I believe we have done that for a few there, yeah.

49:09So, for example, like going in that menu, going to 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. Do we record high-level, or do we record input replication? Almost like GTPO, but a file. We even did some OCR thing. It might sound funny, but on the PlayStation DevKit 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 the hard power reset, it tells you like, this is what's wrong. Press X. There's a way to bypass the screen.

49:39But before we knew about it, we use 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, you know, outlets, a smart outlet. you know like the console try to reboot it try to connect to it if nothing works what about well turn off the power and turn on the power can you so now we do that remotely as well i'm gonna get scary that to know that github action is like playing with electricity but it works and going back to the ws 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 you started you just don't see it but it's doing that 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 you're pitching publishers like what does that business model look like for game emulation 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.

50:51And 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 limited run games on Pure 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's required. But what we also found is that we would get requests from smaller studios, really small studios. They've sold 300 copies of their game, a NES game, for example. But they would love to have it on Switch.

51:30They 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 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.

52:11And he's going to be launching nine games on the Switch really soon. They're all nice 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.

52:49It's not in licensing hell, 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 all the different things? The artwork. work. 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 and it's like, we actually don't own that.

53:205 % 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 those are some of the factors that we look into when we're working on things.

53:55And 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 the vast majority are work for hire. So we're doing work. We reach out to a publisher, sometimes cold, and say, hey, 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 out an agreement and deliver them 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 but plus someone is doing that and there's all the there's a lot of low-hanging fruits game like they didn't sell i mean copies but they didn't sell 100 copies either they sold maybe 10 000 copies or 50 000 copies and nobody's doing those games and those games are just lost right now.

54:55The 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 Bill was mentioning, like, we can talk with the publisher. They would be like, cool, guys, we actually found, you know, 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 or 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 may be the example so i'm not saying we're going publisher route and going there but it's just like the division is there where i believe there's you know there's a big loss of retro games and there's two markets for those games there's the market of people like bill and i we would play those games in in the past and want to play them again because nostalgia but there's also the new market there's newer kids that they're now 20 years old, 30 years old, they never play those games, actually.

55:58And some of those games are actually good. They're still good. Some are crap, by the way. But some are good. And they would pay for it if they were given the chance, like on the Switch, like, oh,$5.99, I'm going to pay this. But they can't right now. The only way they can play those games is find them randomly on the internet and download them. And nobody's making a buck out of this. And I think there's thousands of those games. 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. Localization, of course, is a feature that we provide as well, too.

56:31Both 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. 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:11Well, I have one thing. I think one of our things we're really proud of is our community. Our community works. They're incredible what they do. Our head of community does an outstanding job managing that. So you can find us at implicitconversions.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 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 Lugia, for example, is a game that has come up numerous times.

57:51And 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. didn't we mention 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 in the gtv 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 no draw this triangle draw this mesh to actually like a ps4 or a switch open gl so a switch with the open gl call then you can use a different frame buffer size different target and then render the thing higher resolution.

58:42Now you get those little hedges that would seem like big pixels. They're going to look very tiny, like thin, except the texture would be wrong. The texture that was used, it would still be the lower resolution texture. So now you get nice mesh with lower resolution texture, but it's a bit better there. You may also get some scenes issue. The game was rendering 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, it's a floating point error. And now you see through it. So, so these are the, some of the features, uh, up-and-and-and-and-features that, that we want to do more.

59:17You know, sometimes we have to remove stuff. Games were using blur back in the nineties, 2000, a lot of games used blur. Like, you know, it was cool. Like, you know, 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 new apaches so so i think there's a lot of work a lot of interesting work actually so people interested in like you know gaming and solving problems and 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 a lot of like I work on the simulator.

1:00:03I like to toy around with the NS. 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 it's sort of like the skill set that actually works really well at this company. Awesome.

1:00:32Peace out.