Grand Theft Auto III on the Dreamcast with Falco Girgis and Stef Kornilios Mitsis Poiitidis

0:00Grand Theft Auto 3 is a 2001 open world action adventure game developed by Rockstar Games and it had a profound impact on both gaming and popular culture. Its success cemented video games as a dominant form of entertainment and storytelling, and paved the way for future blockbuster franchises. The game was also a technological milestone that redefined what was possible in open-world game design. It was one of the first fully 3D open-world games to offer seamless exploration, blending mission-based gameplay with a living, breathing city. The game was originally released on PlayStation 2 and PC, but never had an official Sega Dreamcast version.

0:39However, the homebrew community embarked on the goal of porting the game to the Dreamcast and recently released the port to much acclaim. Falco Girgis and Steph Cornelios Mitzes-Poetidis are developers on the GTA 3 Dreamcast port. They join the podcast to talk about the Dreamcast hardware and the heroic task of porting GTA 3 to the console. 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.

1:17Check out the show notes to follow KBall on Twitter or LinkedIn, or visit his website, kball.llc.

1:36hey guys welcome to the show hey thanks for having us thanks for having us yeah super excited to dig into this let's maybe start with each of you giving a little bit about your backgrounds and how you got into the sort of GTA 3 and Dreamcast world. So I'm traditionally a Dreamcast emulator developer. That means I have implemented the Dreamcast in software. That started as a childhood project. Actually, it's been ongoing for 20 years, this involvement with on and off periods. And after I kind of withdrew from that scene because I decided that other people are now So on the forefront, I don't want to do the emulation aspect so much.

2:18I was like, okay, what can I do to make something run on the Dreamcast this time? You know, play the other role. And that's how this happened for me. Awesome. What about you, Falco? All right. So I'll start off saying I actually taught myself C and C++ at age 14 because I specifically wanted to make Dreamcast games. When I was a kid, this was before there was like an iPhone market. this was before Xbox Live Arcade. There was no way for an indie developer to target a console ever, except for this Dreamcast thing, which was just recently discontinued, right? And I found this scene of developers like Steph, like so many others who are doing really cool stuff in this Dreamcast community.

2:58And I was 14 and I made a forum post, hey man, how can I make Dreamcast games? You know, do I use Pearl or whatever? And they're like, God, no, you C and C++. So I used to walk to the library to get books on it. And like fast forward way too many years. And now I helped to maintain the Calistios SDK where I used to use that SDK when I was a kid to do Dreamcast development. And for me, Steph, I knew about him and what he did and his emulator work. And every time he was in Discord, I knew, wow, this guy is really, really impressive and knows pretty much everything ever about the Dreamcast. And then he started working on a GTA 3 port, and I'm just watching from the background, and everyone's doubting this guy.

3:41And I knew that if anyone could ever pull this off, it would be him. And then I saw some other developers who were just, man, like A-tier rockstar Dreamcast people coming. And I just knew, oh my god, I have to be a part of this. Like, even if it fails, it's what a privilege to be a part of something like that. Nice. So let's maybe talk a little bit about GTA 3 and what makes it such an undertaking to port it to Dreamcast. So, yeah, there's various aspects. First of all, we are starting from the PC version. That's the reverse engineered one. So the requirements are substantially higher, especially on memory.

4:19And also the models are a little bit more complex, but it's mostly memory. Like audio memory, the sound effects don't fit. Texture memory, the textures don't fit. System memory, the game loads too many models in it. You want to tell them exactly how many megabytes we're working with? We have 16 megabytes of main memory for everything, and then 8 megabytes for video, but that's also for the transform models. So it's like at the end of it, we have like two, two and a half megabytes free for textures and a little bit less than two megabytes for audio. That's like very small specs compared to even then PC standards.

4:57Yeah, I think those of us who are in the modern world now, that's like mind bogglingly small. But I'm kind of curious, like if you look at, okay, what was this originally shipped at? How much of a downsize are we looking at here? The PS2 version that was the most compact version, it shipped for 32 megabytes of RAM and similar audio and video RAM sizes like the Dreamcast and the PS2 are not directly comparable, but they are similarities. But twice the RAM that's what we have. So we have to compress things further. Yeah, PS2 had 32 meg system RAM and four megabytes of video memory. But that gets complicated because Dreamcast, you have to store other things in video memory.

5:37I'm sure that will be something Steph talks about where it's not, oh, you have eight megs of video memory at PS2 at four. You know, why is that a problem? But yeah, I'm sure we'll get into that. Okay. So memory is a big domain. What other aspects of Dreamcast were different enough that it involved a substantial porting effort? I'll say one thing that I am working on that, oh man, I'm still working on it. because I didn't want to screw up the alpha release by pushing for it without too much testing because if you mess this up, it's really bad. And for the stability of the game, it's physics engine stuff.

6:11We can at least see in our code base where they were using a vector unit in the PlayStation 2, a coprocessor that is a little bit like a DSP and how you'd program for it. And they were accelerating a lot of like the collision check, stuff like that. We don't have that on the Dreamcast, no vector coprocessor, But we do have some pretty cool instructions that like a very fast sine, cosine, approximation, inner product of vector dot products, two 4D vectors and one instruction, things like that, to where you could start accelerating some of that math. But the only problem is, like I was saying, those are approximations.

6:50And when the approximations are too approximate in like a physics engine, that things go very poorly. But luckily, actually, this works. It seems to be a very stable physics engine. Unless I do something just really stupid, like forget to copy a sign because some inverse square root. There's a really funny approximation trick. A floating point division on the Dreamcast. Steph, how many cycles? I think it's 20-something. I have to ask him because I don't know how many. It's quicker to use. Are you familiar with the Quake 3 inverse square root approximation? Why don't we spell it out a little bit?

7:26Because not everybody will be. Okay, yeah, great. And Steph, correct me if I'm wrong. I'm not exactly 100 % sure, but the folklore is that this really crazy integer bit shifting, I don't even understand how someone could figure this out. Approximation for an inverse square root, it's very fast. And taking a real inverse square root or even a square root is extremely slow. So they figured that out. And that's very fundamental for doing things like normalizing a vector that you can multiply by the inverse square root. And the cool thing is on our FPU on the Dreamcast, that's one instruction. F-S-R-R-A.

8:04What does it stand for, Steph? I actually have no idea. Something reciprocal square root. Anyway, so it's faster for us. A division is like painfully slow. It's faster for us if the sign does not matter to multiply a number by one over the square root of itself times itself, if that makes any sense. That's kind of hilarious. Right. So I'm sitting there in the physics like, hey, maybe I can, you know, get rid of some of these divisions. And luckily, it looks like so far, it needs to be soaked a lot more. But it looks like as long as you don't actually need the sign, because you're losing it with the squaring and square root, it looks like it's pretty good.

8:43So that I think the level of optimization that we're talking here is almost it's kind of hilarious but it's endemic to building for old hardware right you're trying to take something that could not do this and squeezing every extra erg yes just wait till steph talks about what he did for the tnl the transform and lighting i think it's one of the most glorious things i have ever like if ever i wanted to see code that was like yeah this is why i'm on this team it's what he did there it was just really cool stuff well so let's maybe start at a bit of a high level, when you're doing these types of transformations, like where are you starting?

9:21Do you have original source code or do you have just a binary and you're intercepting there? Like what does this process look like to get to, oh, I have a bit of a game to run, but it's stuttering here. So I need to intervene. Like what is the flow of development? We had the full reverse engineer source code for the game by the Airy3 project. And also we had the fully reverse engineer code of the game engine that they used, the LibarW project. Without these two projects, this would have been a totally different scope. Like the Dreamcast port is a small addition to the previous work done. After finding those projects and getting everything to compile together, the rest of it was pretty straightforward to get to the menus.

10:03And then it was just we needed a new renderer for the game engine because it doesn't support. That's one of the other major chunks that we had to write, the renderer, because the game engine, of course, it only supports OpenGL, Direct3D, and it has some beats for Xbox and PS2, but only some beats. And we had to bring in support for all of the custom texture formats, the graphics card support for the Dreamcast, implement the pipeline tools to convert, to repack everything to the Dreamcast optimal formats, then actually go ahead and write the transform and lighting pipelines and submit the vertexes to the graphics card.

10:38That was the major part of the work. You know what's really cool is this driver-level graphics work he's talking about is actually separate from the GTA 3 codebase, or the reverse-engineer RE GTA 3 codebase. It's actually part of something called RenderWare that was a very famous middleware that was used in that era. So we actually made our own RenderWare backend for the Dreamcast. That's kind of cool. Yeah, actually, let's talk about that. So you're building these pieces that are specifically to adapt it to the Dreamcast. Are those reusable for other games? In theory, yes. We don't have any other projects.

11:14I mean, there is one other project using the same engine and it's the GTA 3 Reversion Engineering for, is it Vice City? What's the name? Yeah, Vice City. Like the Miami brand, Vice City. So that's another project that uses the same rendering library with some changes, but similar enough. And there are a ton of other games that use this library, especially back in the Dreamcast age. It was a very dominating library for PS2, Xbox and GameCube. so there is hope that more games will be reversing near and then use it and also ideally we would contribute back upstream so independent developers could also use LibarW to develop their own applications right their own games that was one of my motivations for wanting to be part of this team too is like okay we have this team of alpha dreamcast developers doing this like crazy lighting and we're pushing a lot of polygons and we've implemented this middleware layer and you know can we help democratize like the upper echelons of the Dreamcast hardware for the rest of the community with some of this work that we've done for GTA 3 and I think the answer is yes you know I think this could benefit the Dreamcast indie scene like as a whole.

12:26So let's maybe dive in a little bit to these different pieces and tell me if I'm wrong here but I think what I'm hearing is one, there's like big chunks that were missing for Dreamcast that you're able to sort of implement as a package. And those you can plug in your architecting in a particular way. And then there's other places where you're like, okay, this is maybe part of the game code or doing something, but it's too slow, or it's taking too much memory. We are both doing it cleanly implementing on a driver boundary. And then on the other hand, we're going in with the sledgehammer and game code too.

12:58Yes. Yes. So let's maybe like talk about for those driver pieces, like what does the architecture look like? What were some of the interesting sort of technical challenges to get this to work? And maybe for someone like you, Steph, who's deeply familiar with what the Gamecast is, it's just obvious. But for those of us who aren't, like what does that whole piece look like? And then we can come back and look at those places where you're taking in the sledgehammer or the scalpel to tweak things. Well, for the Dreamcast, for the LibarW, it actually follows a typical pattern similar to, let's say, a modern game engine would have, like Unity.

13:34It has a scene graph of transformations that have child objects. I mean, they call them atomics, they don't call them objects. So at the lower level, you have to provide basic initialization functions like query the driver for the screen size and things like that. And also it has three rendering paths. one for immediate mode 2D graphics, one for immediate mode 3D graphics, and then one for the Atomic rendering. And you slowly have to go through and implement those parts. And to get into slightly more detail, an Atomic is made up of a mesh. A mesh has an index buffer, which is the indexes of the geometry, and a vertex buffer.

14:15So you look up the index, and then you fetch the vertex, then you transform the vertex, and you send it to the graphics card. That's the basic flow. and you do this for every mesh, for every Atomic that the game engine asks you to. The game engine itself is pretty straightforward, to be honest. You register the renderer as a plugin to the game engine and it will call your callbacks. So as long as you register all of the correct plugins, then you will get all of the callbacks. And if you implement them correctly, you will get your scene rendered correctly, right? For the Dreamcast, there's some major problems.

14:46like the Dreamcast doesn't render all of the types of geometry in the order you submit them you have to sort the geometry into opaque, transparent and alpha tested and this creates some problems with the ordering of geometry because the game expects things to be rendered in the way it sends them and then we have to split them into lists. And that's universal for any port to the Dreamcast like that's fundamental to our architecture like we sort our geometry by lists that are opaque, translucent, and there's a third list punch through. Punch through. Yeah. Got it. Okay, so where does that, you said most of the game engines aren't going to expect that.

15:26That's a Dreamcast limitation. So at what layer does that transformation happen? And is it transparent to the game engine? Or do you have to go in and then start doing those interjections later? Well, this is where Steph at first was doing something cool where we were deferring everything, right? if the Dreamcast needs it in a certain order, then you have to capture the pipeline state of what you're trying to draw, the vertices that you can defer it until it needs to be drawn. And our first cast, Steph had some stateful C++11 lambdas that were just like capturing the whole pipeline state. It was like, it wasn't really what you would want for high performance code, but it was like, man, that is a really useful use of a stateful lambda right there.

16:11and then he placed them into standard vectors and then he could iterate over them later when he needed to. It's also mostly transparent to the game engine. We did have to modify the game a little bit, like in the places where it expects certain depth ordering, like, for example, the fog. It rendered it at a predefined depth and it expected this to be the minimum depth, but it did this in the wrong order of things, so we had to help it there. but for the most part it works out of the box the reordering okay cool and so to make sure i understand it you sort of implement kind of a middleware that's capturing these things as they're coming in then you sort them in the way that the dreamcast expects and send them on the way do you have like a size of buffer or is it over a per frame or like how does that it's just a vector right now it's dynamic at first but he is doing a clear but he's never doing a shrink to fit on the vector.

17:05Okay. So once it's kind of stabled out, it's basically like a static. Nice. Okay, cool. Any other of those sort of big driver layer? Well, on the driver layer, like Falco mentioned, we had this capturing lambda stuff, and it was wonderful from a language perspective. Yeah, right. It was the ultimate modern. We got a lot of stuff, man. Why do you need? When I joined the team, I was the guy who went into the make file and was like, whoops, C++23. and it caused so many problems because our host compilers couldn't support that for the tool side, you know? So I had to back it down to C++20, like, okay.

17:42And people asked, what good is that going to do you for this project? And that was right there, you know? It was pretty nice. The thing is that I unfortunately had to move away from that to avoid copies because we spend a lot of time copying the lambdas around and do it to several intricacies of the lambdas. you can't have zero copies when you can select them into a vector. So now we use this concept of contexts. So for every atomic, we create an atomic context and we attach some other contexts like a material effects context, if it has reflections, things like that. And then we capture only the context number, which is enough for us to recover the information.

18:23But from a functionality perspective, that's how the driver works. The other part is how we actually submit the geometry to the graphics card that is interesting. Because like the normal way is that you de-index the buffer, you fetch the vertex and then you transform the vertex and then you send it to the graphics card. Then there is a smarter way that you can transform all of your vertices. Like usually you have more indexes than vertices. That's why you have indexed buffers. So the smarter way is you transform all of your vertices at first and then you de-index them and then you don't have to transform them twice if they appear more than once.

19:00And then we did this approach where we sliced our buffers in 128 vertexes, which was tricky because we had to regenerate the topology of the mesh a little bit, like to cut it into chunks in a way that doesn't generate too many more vertexes, too many duplicates. It's a trade-off everywhere. And then we handled this at 128 vertexes, which actually can fit in the cache. So we freeze half of the cache with some tricks. Then we transform into the cache. And then instead of doing a memory copy for the index, we directly send the cache to the graphics card, like send the cache line. Yeah, I think that was the most mind-blowing thing.

19:41We have a mode where he split the cache in half, right? And then we can manually control what goes into the second half of cache. So he preallocates this above where the GPU expects the vertices to go. And he does all the TNL there. and then to send it to the GPU, cache flush. It blew my mind. Yeah, you just blew my mind. So if I'm understanding, you're essentially splitting the cache into two logical sections and using one of those to essentially prepare all of your data, which you can then just flush straight to the GPU. Yeah, in the order that you want. Yes. Isn't that crazy? I've been doing Dreamcast stuff for a long time and that was pretty crazy to me.

20:23Yeah, this is getting down to a level most of us never touch in terms of control over your hardware. So one of the things you said a little bit ago, Falco, made me want to kind of dig in. What does the kind of build chain tooling environment look like building for this? Okay, that's where I come from is I work on the, it's called Calistios. The Dreamcast community is kind of unique in that no one uses the commercial stuff in our community because not to brag, but our stuff is pretty good. our open source stuff, it's been around since 2001, right? It was around back when Sega was still doing Dreamcast stuff.

21:00So it's had a lot of time to mature. There's a lot of stuff in there, like supporting IPv6, supporting different mods and things for the Dreamcast, the hardware mods. Like my Dreamcast actually has 32 megs of RAM. So I don't know about this GTA 3 out of memory stuff. I'm just kidding. But yeah, we support a lot of hardware modifications that have come around for all these years. And one thing that we're pretty passionate about is keeping our tool chain up to date. Like the Super H4 is our architecture and it's still maintained in GCC, believe it or not, because it's used in Casio calculators and it used to be used in set-top boxes and routers.

21:38So it never really went away from the GCC tool chain. So we actually like, oh, GCC 14 2.0 came out the other day, I think it's 2.1 now, we had a midnight launch like, oh, hey, you can already use this some preview like C++ 26 features on the Dreamcast. You want to do that? Yeah. So we nerd out pretty hard about our tool chain stuff and our tool chain support. And the crazy thing is we're not the only ones either. The Nintendo 64 community is pretty much on the tip. The PlayStation portable community, some guys I know on the Saturn scene, I don't know what it is. When we're with retro hardware, We like to not be retro with the software in.

22:14That's awesome. Well, and I think, Steph, you mentioned you started out kind of on the emulation side. So are you able to run all of your test suite, whatever you're doing with this, on an emulated piece of hardware? Tell them about all of it. There's several layers of inception in this. But yes, I maintain a fork of my old emulator. It's no longer the best emulator for Dreamcast. But it's one I'm very confident within the code base. So I maintained that just for this project. So every feature we use, I add to the emulator, like these cast tricks. I added them to the emulator. And also, we have added a lot of validation.

22:52Like every time we have found a mistake in how we have the hardware, I try to add the check-in to the emulator. So that next time we do the same mistake again, it will warn us about it. And it was extremely useful. There were times we were stuck. And it's not so easy debugging on the Dreamcast. that, yeah, a lot of people, we have a lot of people who are like, oh, I print FDebug exclusively. We have a GDB stub, but it's not the best. It's lacking a lot of features. So Steph's inception of his virtual Dreamcast really saved our butts many times. It helps. And we can also cross-compile for PC. I mean, the code base originally worked on PC.

23:28So we did the splice thing together, like take some parts of the emulator and then splice it with the rest of GTA. so we can run into this hybrid mode where it's actually the CPU is running native but the graphics is running through the emulation and this means we can use tools like Valgrind or Address Sanitizer. A couple of bugs have been found this way. Like the memory, we had the memory leak of a matrix. There's no way we would have found where it came from without Address Sanitizer. So there's this tooling that has been developed for the project around the Dreamcast simulation that I'm familiar with and this has really helped us, yes.

24:05I think his emulation background has helped in every, you know, I have started from like indie. I haven't seen this big picture he's seen where he has had to emulate all of the AAA titles. So he knows all their tricks, you know, it's been fantastic just learning from him from that perspective. Well, and one of the things that stands out to me here is like hardware quirks, right? Things where it doesn't actually work as advertised or like, I don't think I would have ever thought about going into the abstraction layer of the cache and like splitting that out and taking separate. control of different pieces, right?

24:36So I guess that would be an interesting thread to go down is like, what unexpected hardware quirks are there within the Dreamcast? And how do you end up having to work around those? How does debugging those work in terms of the emulator, things like that? Well, hardware quirks, to be honest, most of them are handled at the Calisti OS level. Like there are some known hardware bugs, they are handled in the initialization layer and everything kind of works out of the box. The one we run into is that, so the Dreamcast has, apart from the cache, it has these two buffers called store queues, where you can collect some data and then write it all together as 32 bytes into the memory, the graphics card, whatever you want to write 32 bytes.

25:19It's like an ultra fast 32 byte mem copy or mem set, if you use it like that. They alternate and you can write into it and flush one. While one's flushing, you write into the other one and they alternate. And it's just, it's a really cool thing. But you cannot read from it. So I learned. It sounds like something you learned through pain, perhaps. And you also can only write 32 or 64 beats at them, like four or eight bytes. You cannot write two bytes or one byte, for example. And these are quirks we have in the emulator. We have them assert. Like if you use them, it goes and says, hey, you're doing something that you shouldn't be doing.