Game Emulation on the Carbon Engine with Dimitris “MVG” Giannakis

0:00Video game emulation is the process of using software to replicate the functionality of gaming hardware. It's a fundamental approach to making older games accessible on modern devices. The Carbon Engine is a tool developed internally at video game publisher and distributor Limited Run Games. It allows a variety of emulators to interface with modern video game hardware, and it supports emulation of SNES, Genesis, PlayStation, Game Boy Advance, and other consoles. Dimitris Gianakis is the lead developer of the Carbon Engine. He is known for his many contributions in the hacking, emulation, and game development space, and for his highly popular YouTube channel, Modern Vintage Gamer, or MBG.

0:42Demetrius joins the podcast with Joe Nash to talk about how he got started in game development, building emulators from scratch, scoping an emulation project, homebrew vs. official SDKs, the Carbon Engine, and more. Joe Nash is a developer, educator, and award-winning community builder who has worked at companies including GitHub, Twilio, Unity, and PayPal. Joe got his start in software development by creating mods and running servers for Garry's mod, and game development remains his favorite way to experience and explore new technologies and concepts.

1:28Welcome to Software Engineering Daily. I'm your host for today's episode, Joe Nash, and today I'm joined by Dimitris, otherwise known as Modern Vintage Gamer, lead developer of Limited Run Games' Carbon Engine. Welcome to the show, Dimitris. How are you doing today? I'm doing great, Joe. Thanks for having me on. It's a pleasure to be here. Well, so today, as I mentioned, we're here to talk about the Carbon Engine. But before we get into that, your path to Limited Run Games into the Carbon Engine is really interesting. Can you tell us a little bit about what led you to where you are today? Yeah, it's a really interesting question to ask.

1:59It's, you know, there's so many different ways to kind of get yourself into the game industry. Some people do the academic route where they go to school and learn game design concepts and game programming. I did some of that. I mean, I went to college, I did a computer science degree, but I didn't really go by traditional means. I kind of went in via, I guess you could say hacking and modding. Basically, the way that I kind of got my foot in the door was during the early 2000s when game consoles were becoming powerful enough to start to run homebrew on predominantly systems like the Dreamcast and the original Xbox.

2:39I found that there was a really interesting underground scene where people were kind of building emulators and applications and video players and MP3 players in an unofficial capacity. right and i was very fascinated by this and the system that really kind of kick-started the whole thing was the original xbox so my kind of way into the industry was predominantly by just messing around with game consoles hacking them building homebrew for them building or porting emulators and getting experience in these systems outside of official means and i think after that period i I started to get more focused on making YouTube videos as well, because I thought that at the time, it wasn't really, no one was really covering that kind of stuff on YouTube.

3:28No one was really covering the underground homebrew scenes and the areas that I had a lot of experience and familiarity with. So I thought, I'm going to cover this stuff, if not for anything else, just to almost keep a personal diary of some of the things that I've done in the past. and it wasn't really until one particular video that I made that got me recognized by a limited run and that was I ended up actually porting Diablo the original Diablo onto the Nintendo Switch in a homebrew capacity so it was completely unofficial completely I guess you could say illegal if we take Nintendo's stance on this and it got picked up by a lot of articles publications like Kotaku, IGN, and various other articles had kind of, you know, made this big post about a developer has ported Diablo to the Switch.

4:19And that's what ultimately got me recognized by Limited Run. They reached out to me and it was back in, I think it was back in 2018, 2019, around that time. And they reached out and said, you obviously are very experienced, you know what you're doing. Would you be interested in coming on board? We've got an exciting you project that we're trying to spin up here and that's kind of reintroducing old retro games to a modern audience and that sounded exactly like something that was up my alley and i guess that's how it all started perfect amazing yeah i mean what you said about the youtube channel at least functioning as a diary i think is really interesting well because i think one of the things about the homebrew scene and stuff you're working on is understandably given the legal aspects a lot of that information like if you're not at the time and place when the hack happens when the port happens it's very easy for that how it works and that to go completely missing and your channel i think it's been a fantastic resource for like actually getting an idea of what's possible what's happening out there but the technical detail you go into in some of your videos is really fantastic so yeah i've been from someone interested in the scene big thank you for putting that resource together but i guess on to that project you're working on now so i guess the best place to start is carbon engine being a title and a word will put people in mind of things like unity and unreal it's like you know single tools for developing a game and a couple engines a bit different right it's more my kind of impression of it is it's a wrapper around a bunch of emulators and tools for working with roms without source code is that accurate how would you describe it that's a pretty good way to describe it there's a little bit more nuance to that i would say there's obviously you could say that it is that but there's also a lot more functionality around it and it has to do with the various aspects of a good or modern game console you know design so there's also additional functionality in place for example things like trophies and achievements the various controller functionality that we support so anything that has to do with the modern console experience also features those things the social aspects as well but yeah i I mean, you could say at a high level, it's definitely, it's software that kind of encapsulates emulation.

6:29That's a good way to put it for sure. It's a really fascinating approach. I mean, A, because I feel like I say this every time, we cover a lot about how, what a nightmare porting is on this show. And as you're doing that without access to the source code, it was fantastic. But then, you know, watching some of the videos that Limited Run have put out and that you have put out about how you're able to add to the features like achievements and change UIs, like Shantae, for example, with just like hacking into memory and you're making tooling around that super super interesting so i guess to start with i want to talk about the emulators because i think one of the things that was surprising tell me about the emulators that you currently support that built into it because there's a mix of emulators that you've built yourself and yeah open and licensed right yeah yeah so it all kind of started when we first signed shantay and that was the kind of the the the original carbon engine release so at the time when I first came on board, Limited Run asked, you know, is it easier just to build our own or is it just easier to license?

7:26And I really wanted to build our own Game Boy Color engine for this. But since then, we've added NES, Super NES, PlayStation, believe it or not, we've done Spectrum as well. And fun fact, the Spectrum engine is actually being used by Digital eclipse in the jeff minter collection so the if you're familiar with the minter collection on the digital eclipse stuff if you fire up the the early jeff minter games that run on the spectrum or zx81 i think as well that's all stuff we've built as well so we have that we've also done genesis mega drive game boy advance and i think that's it i think that's all that we have i may missed one actually now that I think about it but it's a combination of licensed emulation and homegrown stuff and I think the choice is pretty simple and that is how long is it going to take us to build something versus just to license you know an open source emulation product out there and for Game Boy I think that's something that for me I wanted to take on the challenge of building my own emulator from scratch because I've done a lot of porting work over the years but I've never actually sat down and just, you know, opened a new project in Visual Studio and started coding one.

8:46So I basically told LRG, look, I think I can build one in about six months. And we were able to accomplish that. For Nintendo, we did the same thing. We built our own engine from scratch. And the great thing about building emulators, like, you know, those old early 8-bit emulators, is that there's so much documentation and information out there. And there is an amazing emulation community that really can help you along the way. So it doesn't matter if you're doing it in a commercial sense or if you're doing it in a hobbyist sense, there is so much really good information, solid information out there.

9:20But yeah, I mean, it's really just a, I guess, a mix of in-house developed stuff and licensed stuff. Like PlayStation 1, for example, there's really no point for us to build our own PS1 engine. It would probably take us about two to three years and there's already some great some fantastic ps1 solutions out there so it's just an easier you know conversation just to um chat with the original developers get their approval license the emulation and then just go from there awesome so when you talk about the community support and the resource community out there i think one of the things that really surprised me about the video on your game boy build was the test cartridges can you talk about that briefly?

10:00Yeah. So with Game Boy, and there are definitely other platforms that have very similar tools, but Game Boy is one such piece of hardware where developers, homebrew developers, have built test cartridges that all they do is literally go through all the different facets of the hardware and kind of compare it against your emulation. And it will tell you if you have any kind of specific errors along the way. So there is one particular cartridge that, well, it's a ROM basically that tests every CPU opcode in the Game Boy, which is a variant of what's the Z80. It's the Sharp processor, which is the variant of the Z80.

10:45So it will test every single, you know, instruction for you, right? And it'll tell you, and so it will just perform simple instructions for you. So, you know, there'll be like a load instruction, a store instruction, you know, things like that, right? So it'll, and branching instructions. So it'll basically just run through the gambit of all the different tests and it will tell you, did you pass this one? Did you fail? And those types of things are really useful because if your emulation has some type of issue where you are playing games and you don't really know exactly what's going on, it's always good to, you know, run these test cartridges to just kind of verify that, hey, my CPU instructions, They're all good.

11:23They're all accurate. But there's also cartridges that also test things like the V-blank timings, the PPU timings, the sound accuracy. So there's all these tests that you can run. And I will say that there's probably only maybe one or two Game Boy emulators out there that can basically pass the entire suite of tests. And getting to that point is obviously something that everyone that's developing emulators wants to get to. But I found these tools very, very useful to basically get the appropriate accuracy and level of compatibility that we were looking for yeah so it's one thing that i was wondering when given that the first project was like you know specter shanta you knew what game you were building for when you were building out that first emulator were you targeting the features that you need were there things that you left for future titles being like that's not worth dealing with in detail right now i'll come back to it or you aiming for a general platform from the get-go?

12:19So the way that we kind of do things is it's, the focus really is about the game itself. So it's a good question too, because if you are familiar with the Game Boy, the cartridges, there's different what they call MMC chips, or they're basically mapper chips, right? So in the sense of, you know, in the example of Shantae, there's no reason to build the other mappers out if we're only focusing on Shantae, which is, I believe it's MMC5. I think it's an MMC5 mapper. So there's no point building, you know, the other MMC chips if we're just focusing on this. So the way we kind of work is we just kind of build feature sets as we need them, right?

12:59So in the case of Shantae, the first, it was kind of an iterative process when you start building the emulator, because as I was building the emulator, I was still learning about the Game Boy hardware. So I kind of took a very iterative approach and just kind of had a couple of milestones in mind. The first one was just getting the Nintendo logo to scroll down the screen, you know, like the initial kind of power on. That was kind of step one. And then step two was getting a simple game like Tetris to boot up, which has nothing to do with Shantae. And obviously, it's not Game Boy Color at that point.

13:33It's just original Game Boy. But Game Boy Color, the additions of Game Boy Color kind of adds on top of the Game Boy code anyway. So it was really a matter of just getting some small steps in place, kind of proving out that we could do this. And then once we had something up and running, we had original kind of DMG Game Boy running. That's when we started adding the Game Boy Color enhancements to the engine. And that's when we really started to focus on Shantae itself. So everything else outside of Shantae wasn't really considered at that point, but we have since added more Game Boy Color games to the Carbon Engine.

14:12And in the case of that, if there's a different mapper chip or if there's different functionality that we're not using, then we basically just go back and add those things as we need. Now, in the case of licensed emulation, usually most of those things are already done for you because they've already built out so many different features. So it's not really a case of going back and adding more things. But in the case of our kind of in-house developed stuff, as we kind of get new projects, sign new projects. If there's functionality or if there's some piece of hardware that we're not emulating properly, then we're going to go back and add that in.

14:47Right, that makes sense. So beyond the emulator, what is the functionality that Carbon Engine's providing to developers? Or what kind of tooling have you built out to help your porting work? So it's basically a very rapid tool to spin up new games very quickly. And we have it not only for developers, but we also use it when we want to do some demos at trade shows like GDC, DICE, and things like that. Every year, we obviously want to sign up more of our partners and bring their old games back. And we have a solution for them, right? So basically, it's all pretty much internal stuff. It's not really an outward facing product, but it's a very, very easy thing for us to say, hey, we've signed or potentially going to sign this new deal.

15:37So let's spin up a demo with some nice looking front end and some functionality in place and the game itself and maybe a couple of features here and there. And then just present that to our partner and see what they think about it. so it's really very very easy to kind of spin up something very quickly that we could offer our partners and show them and have them take a look at awesome so it's like a smorgasbord of things that blew my mind that's all about this so like i guess to focus on shantae so in shantae you were doing various things like changing ui for swapping the button controls i think some other tiles that changes you made and i think i've met so you mentioned at one point that you know you had localized various games but the context for why that will be reminded so a lot of these cases you know you're not doing that on the source code you're doing that in memory right like what kind of tooling are you building to support doing that quickly as you say because that seems normally understanding a game's memory layout and what's editing is a laborious process so there's a couple of different ways we approach i'll just use the word rum hacking because that's what we're doing right there's two ways that we do it and there's really no set method whatever kind of makes more sense, sometimes it's a matter of just going in and editing the ROM itself directly.

16:49So for example, one of the things that we have to do is remove any old licensing information from the game. So when you plug in a Game Boy game or a Super NES game, the first thing you're going to see is licensed by Nintendo on the screen. So obviously, because that does not apply, we have to remove any kind of old Nintendo branding. So it's a matter of at that point, are we literally just hex editing or tile swapping out those tiles or are we doing it dynamically in code right and there's really no one set answer to how we approach it it really just depends on the game itself some games have a little bit more sophistication as far as things like protection and and compression some games have some custom compression that we're not really familiar with so it's just so much easier just to say right we're going to just get a debugger out and we know that the license screen gets hit here.

17:44So we're just basically just going to patch out information on the fly. So there's really no set kind of way that we do it. We kind of just approach it in different ways. But on our team, we have some really experienced people that have been around emulation for many, many years. You probably know one of them. You spoke to him recently on the channel. Yes, we've had Randy Linden on. So between the three or four of us, we usually figure out a way to get things done. I think that's the best way. But we use things like Lua scripts to kind of intercept. We do our own custom interception handlers as well.

18:17We do ROM hacking. It really just depends on what is the most sensible approach to get things done. Yes. I mean, the interception, I guess that was another area that I think is really interesting. So I guess the interception comes into play when you're saying things like achievements. So you're looking for specific bits of memory being set and then triggering achievements. How does that work in terms of the, I guess, what is the distributable here? So like there's obviously some binary that contains the emulator and then a bunch of scripts on top and then that's ported for the platforms. Like what does that look like?

18:48Yeah, it's all C++ code. It's not really scripts that we use. So we predominantly just build things using C++, but we have, you know, without getting too kind of, I don't want to talk about specifics about what we do, but we basically have the engine, the emulation engine itself. And then on top of that sits kind of the game handler. And that game handler just basically handles all the specific aspects of that game. So it'll manage, you know, the achievement, the trophy handlers for us. It'll manage any type of patches that we need to do on the fly. It'll manage the social part of a game console.

19:25For example, you know, what users currently signed in. It'll manage the number of controllers that are connected up and if the game's two player or versus one player things like that so that's kind of how we do it we don't really use kind of scripting in a traditional sense there's no like dot txt file that tells the engine to do all this sort of stuff we just kind of do it ourselves in c++ awesome and then in terms of platforms i know for some games you're targeting specific platforms obviously shantae was looking for a switch release but you've released games now on a number of platforms, right?

19:55Yeah. So the Carbon engine itself runs on everything. And initially we built it for the Switch because again, we started out, we had signed a deal with WayForward to bring Shantae to the Nintendo Switch, the original Game Boy Color version back for the Switch. But since then we did River City Girls, Zero, and that was pretty much to everything. I think we release on all platforms, including Steam and Xbox. So we quickly realized that we had to kind of make sure that the engine was portable and kind of up to date everywhere. So we did spend a little bit of time after the launch of Shantae to just get the engine running everywhere, right?

20:35And since then, obviously, we've seen systems come out like the PlayStation 5, the Xbox Series. So we keep updating and making sure that the engine is running and available everywhere. Now, the choice of what systems that the engine is running on, it's really up to our partners what they want. It's not really up to us. We have the engine running everywhere. So, you know, if they tell us we want this on PS4, PS5, Xbox and Steam, then that's what we're going to do. We can facilitate that. But a lot of the times they'll say this is Switch only or this is Switch and PlayStation only. Sometimes they'll tell us it's on, you know, this will run on Steam.

21:11Sometimes they'll tell us it won't. We don't get to make those decisions. It's really up to our partners on that one. Right. Yeah, that makes sense. The emulators is what I'm interested in here. So you've got these emulators running on all these platforms. Have you had to port a licensed emulator? Because I imagine the emulators don't have access to the official SDKs, right? What's that experience been like? It's not too bad. I think, again, we've got some really smart people on our team that understand C++ and they've done a lot of porting work over the years. I'm someone that is very experience in porting.

21:43I've been doing it, like I said, since the homebrew days on the original Xbox and the Dreamcast back in the early 2000s. So it's not really that daunting for me, getting a license emulator and porting it to consoles everywhere. I mean, there's definitely some work and there's definitely some things that you need to do. But at the end of the day, if it's running a graphics API like OpenGL that something like the Xbox doesn't understand because it's direct decks based and the playstation has no knowledge of what open gl is getting those things running on on those platforms there's a little extra work that's involved but i wouldn't say it's anything that's too difficult to do if you are experienced with porting code i would say right yeah that makes sense and then i guess that's an an interesting aspect i think i saw your comment on one of your videos that you've done all this porting work for years and years in the community tool set in the unofficial tool set and now you've got access to i imagine at at this point is every official SDK under the sun, which I know there's limitations and what can be said about that for the NDAs for the platforms, et cetera.

22:44But how has that been as a transition? And I guess as a developer, what is your impression of the official tool sets versus the community tools you're used to? That is a great question to ask. I will say that the homebrew community or the unofficial or the hobbyist SDKs that are out there, most of them are very very well put together i think the only thing that makes them not as good is and it's not really the fault of the sdks themselves is that things like remote debugging those types of features aren't available because that's when you really need an official sdk to connect up your dev kit to and do it that way but a great example is we talked about the start how I was an unofficial Nintendo Switch port of Diablo.

23:31So I used the Homebrew Switch SDK, which is called LibNX, I think it is, or Lib, I think it's LibNX. When I actually got my hands on the Switch dev kit and I started working in official capacity, it was pretty easy. It was very, very seamless. I didn't feel like I had to start over again, start learning things again. The way things were done were kind of the same. And it was just kind of very organic and very natural for me to move from a homebrew unofficial SDK to an official one. And in some areas, I will say that the homebrew SDKs offer some more functionality over the commercial ones. I shouldn't say anymore because I may get in trouble, but there's been a lot of work put into this stuff and you can really tell that the community does really care about this stuff.

24:18And I think, you know, for me, it wasn't really something that I got blocked on at all. It was pretty easy and pretty seamless to get things moved across. That's awesome. I guess I imagine the answer is there, but like, is there ever a point where you reach for a home brutal now? Is that even allowed on certification or does everything have to be on their official SDK? Everything has to be on the official SDK only because I believe there are certain rules around code signing and things like that. I do have a friend of mine, this is a side tangent, but I had a friend of mine that actually used to work making games on the PSP, Sony PSP.

24:58This has gone back years ago. And he actually used a homebrew unofficial SDK and published a game with that. So I think things have changed a lot since then. But yeah, I mean, I would say that there's probably no way you could do that anymore. But I haven't really tested the waters either. But it's an interesting question for sure. Yeah, absolutely. So, you know, we're talking about various ways that you modify the ROMs from outside. Has there been anything that, you know, you've wanted to do or add to a game that you've struggled to do in that approach? And have you investigated things like reverse engineering for any of the games you're looking at?

25:38Yeah. So reverse engineering is something that we do as well. And we're getting more into because we're starting to now look at PlayStation one games. And I think there's a different mindset when it comes to bringing back old PS1 games. And a lot of the times people want to see some enhancements, including things like widescreen support on games that never had it. Some of the things that we are looking at would be enhancing the games because predominantly all the ones that we look at are old games that run at four, three aspect ratios, right? So adding 16 by nine, it's very difficult in a lot of scenarios to do that because even though you may be able to get something that does run in 16 by 9 there's always going to be some menu or some font or some issue where something is not right you know something is not aligned properly or there's just some overarching glitch on the screen that you can't really say look we can ship this the way it is you know so a great example is tomba that we recently released the special edition so tomba is a is a ps1 game that we released earlier this year in August.

26:46And a lot of people were confused as to why we didn't add widescreen support. And we'd heard some stories about how some community people had enhanced it with widescreen. And we took a look at it and we did actually quite a lot of reverse engineering on it. We were able to get the game running in widescreen, but there's just that occasional frustum clipping issue where something just magically just disappears off the screen on the left or the right-hand side, outside of the typical 4x3 viewport. So we just said, look, we can't do this. It's close, but it's not good enough. And if it's not good enough, you can't really ship a product, a commercial product with something that's a little bit off.

27:29So in that aspect, we just have to say, look, we can't do this. But we are doing more work, more reverse engineering on things like enhancing the game with widescreen. The other thing that we have done is TripWorld DX was a game that was originally just a game boy you know original game boy dmg game we did a full color translation of that so we brought a completely new color palette to the game which by the way was something that the original author had in mind for the game so we were able to get kind of the color values from the original developer of the game and you know with his blessing we were able to do a full color version of it so we definitely do a lot of a lot of that enhancement work as well and look sometimes you know it does pay dividends sometimes we we kind of go down this path and take a look at things but we just ultimately we have to stop yeah yeah that's such a cool getting the original color palette from the author who didn't get to publish it and being able to do that is awesome i guess that brings to mind the question of i imagine when you first sign a new client for a game there's an element of okay the start of this project is going to be some investigation work we're going to work out what assets are there we're going to be asking them to dredge the vaults how does that usually play out do people come to you with like you know we know what we've got for this game or have you end up having to get people go through like obscure filing cabinets somewhere in Japan?

28:47Yeah. So I think the latter. Now I will say that I'm not the person that is involved in most of that stuff. That would be our producer, Audie Surley. You may know who Audie is. He's awesome. He's been around video games for a long time, knows a lot of people and very well connected with many other people in the industry. So usually we basically just ask, we'll just ask for it. What do you have? What's available to us? And you'd be surprised when we did Tomba, for example, we got a couple of CDs worth of just archival material. And a lot of that ends up in our museum area in our games. So most of our games will have a museum section where we will produce things like key artwork, prototype drawings, all sorts of things, design documents, level design documents, old video clips and archive material anything that we think is interesting we'll make available so most of our games that we have it's not just about the game itself we also have just this kind of museum piece where we really want to offer as much as we can that we've we've dug up from the archives and make that available to our fans awesome yeah it's really i think i saw the art board for shanta day it was a good example of that cool so i think that covers most of the things i want to ask about carbon so you mentioned earlier it's mostly internal projects so i guess from a internal tools always fascinate me from a developer experience perspective because it's so can we tell it so so much for your own needs so i guess to start with will this be an internal project forever is this something you see limited run licensing to other archivists or you know other companies that want to preserve their old games or anything like that is this that you see as releasing as a product at some point.

30:29You described it as a product earlier. Yeah. I don't think we've ruled it out. I think there's been some talk about maybe making this, opening the face of this product outward facing and making it available. I don't think really we've given it too much thought other than it would be something that we're thinking about doing in the future. At this point, we're just kind of heads down. We have a lot of projects going on, basically taking us throughout the end of 2026. So it's really a matter of putting our heads above water and thinking about what we do with this, right? But I wouldn't rule it out.

31:03You know, I think there's been some talk about, you know, maybe making it available in the future. But at this point, we're kind of just focused on getting games done. Yeah, absolutely. Cool. So that leads me on to, I guess, and again, this might be me asking very particular questions that are, you know, outside your warehouse. But so in terms of the limited run made a splash about the Carbon Engine and its existence, you know, you've spoken about it. It's been on, there was a podcast launched, etc. etc. Having the public face of it, is that from a business perspective, that's letting your potential partners know that you have this technology to resurrect their old games?

31:34Is that what the aim is? Yeah, that would be one pillar of it. I think the other thing is that when you think about limited run games, most people think about physical products. Limited run games, they open up a pre-order for a game, it's open for two weeks and all that stuff. So every week we have new physical products that we sell. So I think the point of the CarbonCast that you mentioned and the marketing around the Carbon Engine is also to let not only our partners know that, hey, we have a product for you guys, but also to let just people in general, our customers know, our audience, our fans, our followers know that, look, we're not just a company that does physical products.