EPISODE 1755

[INTRODUCTION]

[00:00:00] ANNOUNCER: Wipeout is a futuristic racing game that was originally released in 1995 for the PlayStation. The game fused fast gameplay, striking art direction, and licensed electronic music. It was a cultural phenomenon and an early showcase for 3D graphics and console gaming. Dominic Szablewski is an engineer, game developer, and hacker who has released projects such as Voidcall, Quake VR, and Q1K3, which is a 13-kilobyte version of Quake written in JavaScript. A version of the Wipeout source code was leaked in 2022, and Dominic created a nearly complete rewrite of the game that compiles to Windows, Linux, macOS, and Wasm. Dominic joins the podcast to talk about the project. 

Joe Nash is a developer, educator, and award-winning community builder who has worked at companies, including GitHub, Twilio, Unity, and PayPal. Joe got a 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.

[INTERVIEW]

[00:01:12] JN: Welcome, Dominic. How are you doing? 

[00:01:13] DS: I'm doing great. Thanks.

[00:01:15] JN: Awesome. Thank you so much for joining us today. To kickoff, we're here to talk about a rewrite of a classic PlayStation game. But I wanted to know what was your game development journey. How did you get to this point? 

[00:01:25] DS: Oh, it's a pretty long journey. I think the first game I ever wrote was on my parents' 486 in QuickBasic. But then it got really hard to develop games, because developing games for Windows was complicated. Setting up compilers and whatever. And I didn't do that for a while. But then later, I completely ignored Flash. But I remember when Steve Jobs announced that the iPhone won't have Flash on it. I thought that, "Hmm. Maybe there's an opportunity to do it with the things that the browser comes with like HTML5." And I developed this HTML5 game engine and was pretty successful with that. And then I did some casual games with the game engine and some original ones. Yeah, I've been always interested in retro gaming too. 

[00:02:15] JN: That's awesome. Yeah, your game engine impact, I believe? 

[00:02:17] DS: That is correct.

[00:02:17] JN: I'm familiar with it. It's good to hear where that came from and the timing about that. Because I've always perceived it as a very early HTML5 game engine. And it's great to hear that was like literally the stated purpose, which it's very cool. Leading into, I guess, what we're here to talk about, where did you get involved in Wipeout? Was Wipeout a game you played earlier in your life? I've seen you've done a variety of Wipeout-related projects leading up to this complete rewrite. Has it always been something you've been interested in? 

[00:02:44] DS: Yeah. Kind of. It was one of the most formative games, I would say, when I was growing up. We had a Super Nintendo at home. And the PlayStation came out and we saw the advertisements for it and it looked so awesome. But it was so expensive. We sent our father to the local video rental store to pick up a PlayStation for a few days. And he came back with the PlayStation and Wipeout and maybe another game. I can't remember. But Wipeout was definitely in there. And we played it the whole weekend. And it was really good. We've never seen anything like that before. 

And then a few years later, I saw in a local shop they had Wipeout for the PC for 10 Euros or something. Or 10 Deutsche Mark. I picked that up and played that a bunch on my PC. But I noticed that it's not that good as the PlayStation original. But nevertheless, I poked around on the CD and I saw that there's PCX graphics. And I tried to put my name on a billboard in the game. It never really worked out. I don't know. It was all gobbled in the end. But, yeah, I've been always kind of interested in hacking Wipeout.

[00:03:48] JN: Awesome. For folks who somehow missed Wipeout, can you tell us a little bit about what the game is and why it captured your attention so much? 

[00:03:55] DS: I think it was a launch title for the original PlayStation in 1995. And it was developed by a British developer. And they had a very distinct graphical style. There was a professional graphics designer who did all the logos in the game, and all the menu artwork, and whatever. But it was really an important game because it was like if you know F-Zero from the Super Nintendo, it was like that but the grown-up version. And it was like fully 3D. It had polygons. And it had like this dance music. And like a more serious - maybe not serious. But grown-up vibe to the game. Yeah. I guess I left out the most important thing. It's a racing game. A futuristic racing game where you fly around in these hover hips that attach to the track magnets or something.

[00:04:44] JN: Yeah. I mean, you say you missed out the most important. But you did mention the music. I actually didn't - I was very young when Wipeout came out. And I didn't realize until the noclip documentary just how much that game was driven not by wanting to create any particular gameplay, but the music and how important that was for it. Yeah. Also, it's funny you mentioned F-Zero. Again, kind of reflecting on F-Zero and Wipeout leading up to this chat today, I'm just kind of thinking about how the genre of like fast-paced anti-gravity races is very much one that has kind of died off. Right? There's no real contemporaries to these games. But there was quite a few titles in this roster of weirdly specific racing games. 

[00:05:23] DS: There's actually - I'm not sure if I got the name right. I think it's BeamNG. That is a modern interpretation of Wipeout. It's on Steam.

[00:05:32] JN: Interesting. 

[00:05:33] DS: I have to look up the name. But it's pretty good. 

[00:05:34] JN: Awesome. Okay. Cool. Good to know.

[00:05:36] DS: But, yeah, there's no big studios embarking on this again as it seems.

[00:05:42] JN: Yeah. Absolutely. Cool. Yeah. Onto the project. You have rewritten Wipeout based on, my understanding, some leaked source code that came out a couple years ago. Can you fill us in? How did this project start? 

[00:05:55] DS: Well, it started a bit earlier than that actually. I did a reverse engineering of the data format for Wipeout when I was young. I tried to put in my name into the graphics and it didn't work out. And later, with a bit more experience, and I think in 2016 I tried to figure out all the data formats for Wipeout. And I built a JavaScript renderer that just loads all the racetracks and ships and just displays it via WebGL in the browser. I was kind of familiar with the data format already. And, yeah, I was interested in this Wipeout thing. 

And then the source code leak happened. I don't think there's any information where exactly it came from. But it just showed up on its website. And it doesn't come with any license. It's kind of legal gray area, I guess. Well, I couldn't really get into it directly. I think it took a year until I found the time and the motivation to really dig into it. Yeah. And I just downloaded the zip file with all the code in it and started digging around.

[00:06:55] JN: Awesome. Yeah. The legally gray area I think is a really interesting one. Just touch on it briefly. You mentioned in your blog post - which, by the way, excellent blog post write-up. Everyone, please check out this blog post. I'll make sure to put it in the show notes. Your blog post about the rewrite that other people have had to go with this source code and other people have done things with it. And part of the reason that you're going after a rewrite is part of the fair use play.  For folks who are not familiar with the fun world of source code licensing, can you briefly go into that and why a rewrite in this case is an interesting way to explore the source code? 

[00:07:26] DS: Well, that's kind of tongue-in-cheek. I guess I'm still in the dark gray area even with this rewrite. Yeah, source code is - usually, if you write a program, it's usually copyrighted. And if somebody steals your source code, you can sue them for copyright infringement. And then there's licenses you can attach to your source code and say, "Hey, if you use the source code and modify it, you also have to release the modified source code." That's a GPL license. And then there's more permissive licenses like the MIT license where it's like, "Oh, you can do whatever you want." 

Well, my argument in the blog post that I lined out is, "Okay, it's based on the original source code. But it's a complete rewrite." None of the lines of code are where they were. And everything is different. I think you can still see the resemblance to the original source code in a lot of places. But, yeah, you could make an argument that it's an original work. Again, I guess it's kind of a gray area.

[00:08:26] JN: Yeah. I've seen some unhinged things done to make sure it's like a clean room implementation of this kind of thing. Someone reading the code, describing the algorithm, and then giving it to someone who's never seen the code and this kind of thing. It's a really interesting one. But it seems like it must be a really fun project trying to rebuild this thing in a way that's, as you say, original and different. 

With that in mind, one of the first questions I guess I wanted to ask you is, as we've kind of covered in your introduction, you've done a lot of I guess I would say like lower level JavaScript programming. Obviously, you've done WebGL. You've written a framework. But predominantly from what I saw of your background, you're a web developer, a web engineer. Why did you decide to rewrite it in C instead of, say, in JavaScript or in Impact even? 

[00:09:12] DS: Well, in my day job, I have to write in a lot of languages that are very high-level. JavaScript. I do a lot of PHP, Kotlin and Swift for the iPhone. And all these very handholding languages that are often nice to work with but they obscure what is really going on. Well, in the recent years I've just found it interesting to write C in my free time. Because it's like you get into the Zen state, I guess? You have to think about all the details. And it's fun to piece it all together. And it's like solving a big puzzle. And it gives you all the challenges that you don't have with higher-level languages where you just throw together some objects and see what happens. And with C, you really have to be care what you do. And that's kind of the appeal to me. I really like writing C even if it's not the economically sensible thing to do.

[00:10:07] JN: Yeah. That's awesome. Yeah, I love the approach of - I don't say historical. But earlier programming languages with more the sharp edges as a fun alternative to the modern languages you have to use in a workplace. What is the state of the rewrite? I've played it. It was playable. It seems great. How do you look at it? 

[00:10:23] DS: Well, it's difficult to find more motivation for it now that it's out. Once you release something and you get all the praise for it, you kind of stop working on it a lot. It's pretty close to being done. There's still some minor details that I'm missing. And, of course, there's a whole bunch of improvements that could be done that are improvements on the original game. The original game had a very steep learning curve because the collision response is just so unforgiving. You bump into a wall and you stop dead in the track. And newer games fix that. The newer games in the Wipeout series. This could be backported to this version 2. And then just graphical effects. The ships are, for instance, not lit. If you go into a dark tunnel, it's not reflected on the ship. And sparks flying when you hit the wall or stuff like that. 

But, yeah, it's playable and it's complete. There might be a few more physics bugs because I rewrote all the physics code. And it's probably not completely frame rate independent in some places. But if you play with 60 FPS, it should be fine. Yeah. Mostly done, I would say. But as always, the last 10% or 90% of the work. Who knows? If Sony would really approach me to ask me to do a full port of this and polish it up, that would probably be a lot more work still.

[00:11:41] JN: Perfect. Yeah. I really love that you mentioned the backporting mechanics. We'll come back to that later because I have a whole bit heap of questions about how you feel about I guess the historical archival purposes of a project like this. But first, I want to get into the rewrite itself and how it came about. And I guess the best place to start is the state of the leaked source code as you found it. I think it's fair to say from your blog post that you weren't super impressed. I believe you used the word abysmal, which I imagine was slightly tongue-in-cheek. But can you tell us a little bit about the state of the source code, ASM, when this particular version of the game that was released? 

[00:12:15] DS: Yeah. I guess I was pretty harsh in my blog post. You can look at it from two ways. The one way to look at it, it is just to see the source code and see that's a whole mess. And that, I don't know, the global variables declared in one file I used in another file and it all doesn't make sense. It's all over the place. And then you can look at it from the other way and say that, "Hey, it was a really cool game. And a lot of people enjoyed it. And it works." And it never crashed on the PSX. It's perfectly playable. It justifies the means maybe to have a working game in the end. Maybe the source code is all bad. But the game is playable. Yeah. 

Yeah. And I guess how it all came together is if you really dig into the source and try to figure out what was coming first, you can see that maybe the track rendering, the racetrack rendering and the physics for the ships was being implemented first. And then everything else is kind of piled on top of that. And what made the source code really bad in the end is that they also piled on top the PC version. And there's a lot of IF DIVS. That if this is on PC, do this. If it's on PlayStation, do that. And even for the PlayStation version, they had a lot of IF DIVS for different type of controllers and it's all very ad hoc and all piled on top of the previous version. 

And then, as I mentioned, this game was developed in the UK. They built the PAL version first and then they had to do the NTSC version. And because the game wasn't frame rate independent, it had a fixed tick rate. It advances the same time step every frame. They had to change it in a bunch of places. And, again, they did this with a bunch of IF DIVS. It's like, "Hey, if this is NTSC, do the time step this and this much." And, again, the PC version on top. And then there came a GPU-accelerated version for the ATI Rage. And it's all cobbled together in the same source code that was leaked. I guess the whole rewrite would have been a lot easier if I just got the clean PAL version PlayStation source. 

[00:14:18] JN: Yeah. I mean, it must be really interesting to get to see that kind of layers of archaeology of the game's history as it's ported and moved from platform, and region, and that kind of thing. It was really interesting as well how you just described features going missing. I think the track - was it the vertex shade? Vertex lighting renderer or something on the track went missing between versions? 

[00:14:37] DS: Yeah. The original PlayStation version, they had textured tracks that were also vertex-lit. Every vertex of the scene could have a distinct color. And they all baked this into the models themselves. I don't know how they did it. I guess they painted it by hand. I don't think they had a light calculation. For modern games, you have this light map step or something. I don't think they had that. 

And all these vertex colors are missing in the PC DOS version. Actually, one of the programmers that was working on this approached me on Twitter and said that, "Hey, yeah, we tried our best. But it was just too slow. We couldn't do the vertex lighting on top of the textured tracks to make it run fast enough." And then I guess the ATI Rage version, that was just like a promo thing. That was really the pinnacle of the garbage - you can see it's just slapped together really quickly and not much care taken. It's interestingly also by different set of programmers each time. PC DOS version was handled by other people than the PlayStation version. And the ATI Rage version was handled by different people still. And they all had to make sense of what came before. I guess they had a really tough job too.

[00:15:49] JN: Yeah. That ATI Rage one especially really fascinates me. Just the economics of that. I remember back in the day when you'd get like a new computer or a new computer component, it would come with CDs of free games or whatever. And I imagine that's what this setup was. And so, the idea of porting a game to give out under those conditions, whatever porting house was given that was probably given a miserable budget. It's kind of understandable. 

Okay. Going back to some of these layers. One of the things you mentioned just now and also in the blog post was the difference between NTSC and PAL. And this was a thing that I guess I hadn't thought about for many, many years basically since - but growing up, I always had this like vague understanding that these regions existed because sometimes you end up with a PlayStation game from the wrong region and whatever. But I've never really looked into the fact there's a technical difference. What actually is the difference between NTSC and PAL? And how does that come through in porting a game? 

[00:16:39] DS: Well, the main difference for Wipeout was that NTSC was 60 Hertz. And PAL is 50 Hertz. Yeah, that was complicated for all platforms that came before. Super Nintendo games also had the same problems. And, often, the developers were kind of lazy. And the Super Nintendo version just runs a little bit slower. And none of us in Europe knew. So, nobody cared. 

But, yeah, the main difference comes down to the frame rate. Well, nowadays, everyone has a 60 Hertz monitor at least or even a variable refresh rate. And the way that games deal with this today is that you have a variable time step. At least that's my understanding. I'm not in the AAA game development sphere. But you just measure how much time has elapsed since the last frame was rendered. 

For 60 Hertz, that's 16 milliseconds usually if you hit your frame rate. And then you just multiply all physics that you do with this time step. If you have your speed, multiply it with the tick rate, you get a smooth physics integration that is mostly the same on all kinds of different frame rates. But, again, back in the day, nobody did that. Because you were sure. If you order a game for the Super Nintendo or PlayStation, you knew you were going to hit 30 FPS or 60 FPS. You knew what your time step was going to be. And it made development a lot easier because you never had to deal with variable time steps. And I guess you were also quite limited on these old consoles. Multiplying with a time step for every object that you want to move is kind of prohibitive. I guess it was okay on the PlayStation but not so much on the consoles that came before.

[00:18:18] JN: Fascinating. Yeah, I never really thought about the cost of frame rate independence. That's a good point actually, especially the extra [inaudible 00:18:24]. Yeah, that's got to add up. Awesome. Speaking of old consoles and the cost and the hardware. Any game, even modern ones, are very much a product of the architecture they were built for. And that's increasingly true. Well, more true for console games. And especially for Wipeout, which you touched on kind of the origin of Wipeout a little bit. But as far as I understood it, not only was it a launch title. But the developer or the publisher was very much involved with making the PlayStation a usable dev platform. It was all tangled together in a big mess. Are there any interesting places like in the source code where you really see the PlayStation architecture come through? Are there any things that you're just like, "No one would write this way for any other console or any other environment? This is purely a PlayStation artifact." 

[00:19:11] DS: Oh, yeah. For sure. Especially in the rendering code, it is very specific to the PlayStation console. Usually, these days when you write a game, you have your game objects and you have your renderer kind of like an abstract thing on the side. You can maybe switch out your rendering code. Like you want to switch from OpenGL to Vulkan and you just switch out a module in your code. And it mostly works without you having to touch the source code all over in the game. 

But, again, back then, you didn't have this freedom. All this abstraction obviously cost a little bit of compute time. And you were writing stuff very close to the Metal. You were trying to deal with the things as immediate as you could. All the rendering code that is in the Wipeout source is very specific to the PlayStation. And it's very ad hoc. There's no renderer module that just accepts all the triangles and then tries to figure out how to best submit it to the hardware or something like that. Yeah, that's probably the part that is closest to the PlayStation. 

But then there's all kinds of different things too. The controllers, for instance. There's also no abstraction of controller input. Whether you have a PC keyboard attached, or a game controller, or, I don't know, a racing wheel. All these controllers were also in the source code with IF statements. Like, "Hey, if this is the PC version and a mouse is attached, then check the mouse coordinates now." It's not like abstracted the way that you have an input module that says, "Hey, when the mouse moves left, give the input to the game. Move left." Yeah, very ad hoc. But, also, I guess it's kind of because the game was so successful and they didn't anticipate they had to port it to so many different platforms that it was just all piled in in the end.

[00:20:57] JN: Yeah. The renderer sounds nightmarish. 

[00:21:00] JN: That is an especially interesting topic I found. Actually, when I was doing the rewrite, I looked into how the PlayStation produced polygons on the screen. And the most interesting thing to me is that the PlayStation doesn't have a Z-buffer. If you do 3D rendering and you submit two triangles to the GPU to render and it gets rasterized, the CPU figures out which triangle is in front of the other one with a help of the Z-buffer. 

If you draw triangle, it gets drawn to the color buffer and you have the Z-buffer that just stores the depth value, like the distance to the camera. And if you draw another triangle, it is compared to the stored depth value. If you have a depth value that is closer to the camera than the one you want to write, then your object is obscured at least on this pixel by the previously drawn object. 

The GPU doesn't try it. And you as a programmer, you don't have to care that much about it. You just set up your death buffer and the GPU who does it. But, again, the PlayStation didn't have that. And you had to draw all the polygons in the order that they should appear on the screen. The furthest back triangles need to be drawn first. And then the closer you get through the camera, it's piled on top. 

And the development library that came with the PlayStation, they had some kind of cool functions to make that a bit more ergonomic. They had this ordering table where you could set it up and say, "I want to have 8,000 different depth values." And for each polygon that you want to draw, you figure out how far it is from the camera. And then you put it into the ordering table at that distance. And if you do that for all polygons, you have the ordering just right in the end. Because, see, it is drawn, well, back to front again. You put everything into the ordering table just like a big ass array. The implementation details are a bit more interesting than that though. And it gets drawn in the order from back to front. 

[00:23:01] JN: The implications of that are interesting.

[00:23:04] DS: Yeah. You have some visual artifacts, for instance. There's a few cases where you have three triangles on the screen, for instance. And one triangle overlaps the other one like layered on top. And no triangle is in front of all the other triangles. Each triangle is overlapped by some other triangle. You can't draw that accurately on the PlayStation. Because you can only draw triangles at one death value. And you get around on this problem with modern GPUs with the Z-buffer. What you would have to do on the PlayStation if you wanted to have this accurately, you would need to subdivide your polygons basically. It gets very complicated. 

And you can see a lot of these issues pop up in the PlayStation games. If you look closely, play a PlayStation game, you can see that there's some polygons peeking through where they shouldn't be. But most developers did a very good job of hiding that. Or the resolution was so bad that you didn't notice or didn't care.

[00:23:58] JN: Right. Yeah. I was also immediately just thinking about is 8,000 depth values enough? But I guess for most games of the era, it definitely would be. And I guess it's not opinionated on how you define a depth. That depends on the scale of your game.

[00:24:14] DS: Yes. Exactly. You as the developer, you were responsible for putting it into the right position. So you can say, "Oh, it's 5 kilometers away from the camera. I'll put it at position 6,000 or something. The scale is up to you.

[00:24:28] JN: Interesting. Okay. I guess to start with a question we kind of teased that earlier when you were talking about backporting mechanics. To what extent were you aiming for a recreation of this code that's like accurate to how the game worked or how the code was versus like the mechanics of the game? Were you just trying to make the game as good as possible? Or was there some effort to preserve the spirit of the source code, if that makes sense? 

[00:24:52] DS: Well, I started out by just looking at the source code. And all I wanted to do is to make it run again. To make it compile and run again on a modern computer. But the more I read into it and the more things I changed, the more I noticed that there's a lot of room for code quality improvements. And for some reason, I really like refactoring code. I guess most programmers do. And one thing led to the other. Like, "I changed this. Now I need to change that." 

I didn't set out to make a full rewrite. But in the end, it just happened because I felt it was the best way to approach is to make the game live on for many more years. Because if you have to scabble the original source code, making it run on every platform on every new platform that comes along is very time-consuming. Very difficult. But if you have a clean slate kind of and a clean source code that in this case even abstracts the renderer away, so you can plug in another rendering module. Make it run on different platforms. That makes it so much easier to keep the game alive too. Yeah, it was all by accident basically.

[00:26:01] JN: Awesome. Yeah, you mentioned a new renderer module. My next question was going to be how do you deal all these architectural oddities of the PlayStation? I guess you've changed it to a more modern rendering approach? Is that accurate? 

[00:26:11] DS: Yeah. The first thing I did was, yeah, trying to get the thing to compile and run, which was pretty difficult to begin with. Well, the first step, trying to make it compile was already very challenging because it relies on so many different things that weren't there anymore, for instance, for the ATI Rage version. All kinds of Windows, headers that I didn't have or GPUs that don't exist anymore. And for the PlayStation version, same thing. I don't have a PlayStation to compile this for. And the PlayStation libraries are missing. 

I just ripped out everything that wasn't really essential to start the game. Commenting out all the places where polygons are rendered. Commenting out all the places where controller input is checked. Commenting out places where something PlayStation-specific happened. And then, finally, I got it to compile. 

And then I started to slowly adding things back. Again, the PlayStation version was using this ordering table and transforming polygons on the co-processor. But the DOS version was doing the transformation on the CPU and they had all the routines to do that there. But they were still using this ordering table because it was so ingrained into the source code. 

And I started using this ordering table too. All the transformation of the polygons that runs on every CPU, you can run it on a modern computer. And just then, the last step when these polygons are handed over to the GPU, I exchanged that. How it goes through the ordering table and gets it to the display. 

Yeah, the first thing I had was this flat-shaded version of Wipeout where it just had something on the screen that runs. And from there on, I started to clean things up more. Getting rid of this ordering table and having a proper triangle function. And using that instead of sticking stuff into the ordering table all over the place. 

Yeah, step-by-step. Very slow progress. At times, very tedious. Because, also, you tried to get rid of something that was in there and rewrite it. And then you were working for five, six hours on it and you could not compile in between to see if it works because you were changing so much to facilitate that. Yeah, often quite adventurous. But a lot of fun too.

[00:28:26] JN: A question I realized I didn't ask that I should have done is do you have an idea - sorry. This is like a hard numbers question on top of your head. How big was the original source leak in terms of lines of code? And how big was it ended up being in the rewrite? 

[00:28:41] DS: I think I actually have the statistics in my blog post. 

[00:28:44] JN: Oh, really? 

[00:28:46] DS: But the way that you count it is kind of complicated by the fact that there were three versions of the game in the source code league. But none of these were working independently. If you wanted to compile the PC DOS version, it pulled in some source code from the PlayStation version too. I don't know how to calculate that accurately. Again, it would have been nice to get the source code for the original PlayStation version. Because then you would have the more accurate number on that. 

[00:29:13] JN: Okay. I found it. 40,000 lines of code in the leak versus about 8,000 is what you ended up with. 

[00:29:20] DS: Yeah. Again, yeah, a lot of things where just you saw the same IF statements all over the place. Like, "Hey, if it is this controller, do that. If it is this other controller, do that." And if you just abstract that away into an input module, you get rid of a lot of repetition and a lot of source code, a lot of source lines.

[00:29:40] JN: Awesome. You mentioned there that you abstracted some things away so you could use different renderers, different backends, et cetera. You've got the game running on both SDL2 and Sokol? Is that correct? 

[00:29:53] DS: That is correct. Yes. I started out with SDL2. I'm doing this on Linux. And I just had OpenGL here. And so, I tried to get that running first. Well, there's two things you can swap out. The rewritten source code is built in a way that you can swap out the what I call platform. And that is SDL or the Sokol app. And then you can swap out the renderer. Currently, there's the official OpenGL version. And I have a Viaframe software rendered version. And other people have written parts to Metal for macOS. And trying to remember if I saw something else. Maybe someone ported it to some newer console again. I'm not sure. 

Yeah. I started out with the SDL platform because I knew that I wanted to have the possibility to have different platforms. Adding then the Sokol backend was quite straightforward. There's only very few functions that the platform needs to implement, like setting up the window, sound output, and stuff like that. 

And Sokol is actually very cool. Lib SDL is a big library. And you get the header files so that you can compile your code. But then you also have this library that you either need to also link to your binary or just dynamically link. And I think it's like 3 megabytes or something. And Sokol on the other hand is you are expected to include the whole source code. And it comes all in one file. And you just include it in your C source and it just works. 

And I was actually very surprised when I got this working on my desktop. And I could open a window with Sokol and play the game and input works and whatever. I just had to switch out the compiler from the usual GCC to Emscripten. And it compiled the web version and it just works. I could play the game and sound output worked. Graphics via WebGL worked. It was kind of amazing. I expected a lot more struggling to make it work on the web. 

[00:31:58] JN: Yeah. I hadn't heard of it before your project. But, yeah, that's pretty nifty. And that does lead me to my next question was you're targeting Wasm. You're targeting web platform. I guess you've kind of just answered it, which is you didn't really have to do anything special because Sokol handed it for you. But was there anything during the rewrite where you had to keep it in mind that you were targeting Wasm? 

[00:32:15] DS: Well, other than that I wanted to target different platforms. Not really. Because I was using OpenGL anyway. And the new WebGL is pretty close to that. You have this GLES2. And I didn't need any fancy shade up code. I I don't have any shadow calculations or whatever. It's just textured triangles with a color. As basic as it gets. And WebGL can do that just fine. In that regard, I didn't need to think about any changes. 

In the end, I had to do a little bit of work for the Wasm version to make it work on mobile. Especially, I needed to have some buttons on the screen that are then forwarded to the C code. And that was a little bit of work. And it's not really fun to play. Because these on-screen buttons are not very responsive and positioned wrong. And it's more like a proof of concept. It works on mobile and it renders just fine on your iPhone or something.

[00:33:16] JN: Yeah. I am surprised that works on - I can't imagine playing Wipeout on iPhone with buttons in the way. I already feel like it's just like too fast-paced for that small screen. I guess to rewind a little bit and go back to rewriting stuff, there was a couple of interesting parts in your blog post where you mentioned not even necessarily looking at the original source code because it was just like too spaghetti-ish. And, instead, just looking at videos of the game being played or playing games on the emulator. Can you talk through some of those areas and why you took that approach to it? 

[00:33:48] DS: Well, one of the areas was the sound code. Again, very specific to what was happening on the PlayStation. And this was actually fairly abstracted away. In the game, there were calls to just play a sound at a certain position. And I knew what the game wanted to do. And I just thought that, "Okay, instead of digging through all this sound code that is there, I just reimplemented." Because I know what they want to achieve. There's music playing. There's sounds playing at different positions. And I know where they get called. And it was a pretty good decision, I would say. Because, again, the original code was so specific to the PlayStation that it would have taken a lot of time to figure everything out. And just rewriting it was the faster way. There's one thing missing though. The original PlayStation had this hall effect. If you go into a tunnel, you could hear like a reverb of your engine sound and also a reverb of the music that is playing. And that is still missing from the rewrite. 

[00:34:48] JN: Interesting. Reverb of the music that's playing is also an interesting one. Because that implies it's coming from the ship and isn't just background music, which I'd never noticed before. One thing you said in the podcast really interested me, because I had heard the term before. At one point, you describe that the original code followed a "you call the platform approach". And you want today platform calls you approach. What do you mean by that? 

[00:35:11] DS: Typically, the way you wrote games is like you start your program, you load your graphics and your sound files, and everything that you need to run the game. And then you go into an infinite loop that just runs forever. And in this infinite loop, you check if any buttons are pressed. You advance your physics calculator. Advance the world state. And then you put everything onto the screen. Then it goes into the next iteration. You call the platform. You call everything that you need to do by yourself. 

You wait in your own code for the next until the renderer is done. And you submit everything to the renderer. And you can do that on the web and in WebAssemly because you would basically crash the whole page or stall the page. You cannot go into an infinite loop. You have to give control back to the browser. 

In JavaScript, if you just write a loop in JavaScript that runs forever, the browser, after 15 seconds, will say, "Hey, this page is not responding anymore. And you can't interact with this page in the meantime." Because JavaScript is single-threaded, there's nothing running in the background if you don't use web work or something like that. And if you want to render a game and put something on through the screen, you do your physics calculations all for input and put it on the screen. And then you give control back to the browser and wait until your code is getting called again. 

What you do is you just set up an interval or a request animation frame these days where you just say, "I want to get this call back called every 16 milliseconds." And in these callbacks, you do all the things that you need to do and then you return. And that's the only way you can do it on the web. And, interestingly, the original Wipeout code didn't have just one infinite loop. Even if you implement the game cleanly, you would have just one loop that handles all kinds of different scenes. You have your infinite loop that pulls for input. And then if you are in the menu scene, you show the menu and handle the menu buttons and whatever. And if you're in the game, you advance the physics and you have the this very outermost infinite loop. 

What Wipeout does is it has this infinite loop on the title screen. It just shows an image and says press start. And there's an infinite loop. It just links the press start button. And as soon as you press start, it jumps to another part of the code where there is another infinite loop. 

[00:37:49] JN: Oh, I see.

[00:37:51] DS: And you have this infinite loop for the menu. And then if you go into the game, you had another infinite loop in the race functions. Lots of different infinite loops that you have to untangle. Yeah, there was quite some work to figure all this out and where you switch between those loops. And how you maintain all the state and all the things that were loaded. Like, which kind of graphics do you still need? Which kind of graphics can you throw away? Because they are from a different racetrack or something. There was quite a bit of work.

[00:38:22] JN: Yeah. That sounds nightmarish. Yes, you've just reminded me. Speaking of which graphics you retained, you had an interesting approach to the memory management in the rewrite, right? Which is you did away with allocating memory and just said I will have this much memory. And that's all I need forever. Can you talk a little bit about that? 

[00:38:38] DS: Yeah. It's actually pretty standard approach in a lot of game development that you have a bump allocator. That's a big area of memory that you allocate first. And then you say I start at the index zero. And if I want to have, I don't know, 1,000 bytes of memory, you just advance this index to 1,000 and give back the memory address that was at zero. And then next time, you want 20 bytes. You advance the index by 20 and just give back what was at the previous position. 

And so, it's just like a linear memory that just grows and grows and grows. And everything grows on top of the previously allocated thing. And then if you don't need your memory anymore, you just reset your index to zero. And you don't have to free anything. You just know that all the memory that I allocated here is free now. And a lot of games these days do this for - they have this bump allocator or frame. At the start of the frame, they start at zero. And some things in the game need to allocate some memory to do some calculations or whatever. And the allocator grows and grows and grows. 

And at the end of the frame, it's reset to zero again. You as the developer, you as the game developer, you never have to care about memory allocations. As long as your buffer in total is big enough to handle one frame, you don't have to free anything ever again because it's automatically freed at the end of the frame. And you can use that concept. You can further that by just saying, "Hey, I don't only have one of these bump allocators. But I have multiple ones." One that is per frame and another one that I do, I don't know, per level. Each time a level gets loaded, it's reset. 

And, yeah, the way I did this in Wipeout is there's actually just one bump allocator but it remembers different levels. First, when the game starts up, it's at zero. And then I load some graphics that the whole game needs. For instance, the graphics for the font. And the ships are needed in all races and the textures for the ships. And these are put into the bump allocator. 

And then when you start a race, the position of the bump allocator is recorded. And then I load the racetrack into this bump allocator. And when the race finishes, it's just reset to this position again. And the racetrack is basically thrown away and makes room for the next racetrack to load. That's a very, very simple approach to memory management. And it works - I have to say, it worked really well for this game because you have these very distinct scenes that all have their own graphics and own models. And, yeah, you have some models that you just load before you load the first scene. The ships and whatever. And they just persist all the time. Yeah, you never have to free anything. And you know that you cannot leak memory because it's reset to the previous level again. 

[00:41:41] JN: I think you answered the main question I had. I wasn't familiar with that concept. It's really interesting. Thank you for diving into it. But I guess the main thing you have to do here is logically group what you're loading because you couldn't, for example, free something in the middle of a block. Right? You're just resetting the point back to certain things. You've got no scope to remove things within an area, right? Okay.

[00:42:06] DS: Yes. Exactly. Yeah, you cannot free something from the middle and make room again. Everything that is in there is in there until you reset the pointer. Yes. 

[00:42:16] JN: Which then is ideal for, as you said, something with very discreet. Obvious scenes like a racetrack basically. 

[00:42:21] DS: It's actually a tiny bit more complicated in Wipeout because I needed some of this memory that I can re out of order again. For instance, when you load a racetrack from the disk from a file, the whole file is loaded first. And then I go through this file and look for all the data that I need for all the vertices and whatever. And I put them into another structure that is more efficient for rendering. And this is the final data that I use in the game is put into the bump allocator. 

But the file that I load, I can free again later. I needed to have what I call the temporary allocator for these very short lift objects that you have to explicitly free again. And, yeah, this is mostly used for loading files and transforming them in some way. And fun thing about that, I think the whole game allocates 16 megabytes at the start of the game for this bump allocator. And the bump allocator grows from zero to 16 megabytes. And the temp allocator actually lives in the same 16 megabyte space. But it grows from the end. It grows downwards. If those two allocators ever meet you out of memory.

[00:43:32] JN: Playing with fire. But then I guess, as you said, when you're building these kind of games or building for the constraint consoles, you often knew exactly what you needed at any point, right? 

[00:43:41] DS: Yeah. And, also, I can be sure that everything fits into memory because I tested it. There's no edge case where something is loaded that I didn't foresee to be loaded. These are very distinct scenes. And as long as all the scenes, all the racetracks load just fine, I know the memory level will be reset to a known value. And if the game fits, it fits.

[00:44:02] JN: It's one of those things I guess I always struggle with as high-level programming is you've always got that temptation to make the thing work for every case and to make it as maximally abstract, and maximally generic, and maximally fault tolerant. But sometimes you actually do just know exactly how much memory you're putting in the data structure and you can just rely on that. And it makes me itchy accepting that. But it works and it makes the game work. And that's fine. 

[00:44:25] DS: Yeah. Realistically, yeah, if you develop for the PlayStation, you know you only have - I think it was 4 megabytes or maybe even 2 megabytes of RAM. You know the room that you have to work with. Yeah, there's no advantage to using very dynamic memory allocation and freeing objects all over the place. 

[00:44:44] JN: Perfect. I guess moving on to future-looking questions. You mentioned a lot of the motivation has gone out now that it's released. But is there anything you still want to tackle for the rewrite? Is there anything you hope to see happen with it? 

[00:44:55] DS: Well, I still want to investigate this. There's probably a physics bug you can crash into the racetrack when your frame rate is too high. And I figured that out by - I implemented this very crude version of motion blur. Because the game runs with 5,000 frames per second on my computer anyway. I only have a 60 HZ monitor. I thought, "Okay, let's just - you know I have 16 milliseconds between each frame. Why not divide 16 by 8 and just advance the game 2 milliseconds at a time and render a frame?" 

And I take eight of these frames together and blend between them. And that is the final output frame that is sent to the display. This is how the motion blur is implemented. It's like the real version of motion blur, it's very computationally expensive. But with this game, it's trivial to do because it runs so fast. And I basically had eight times the number of frames that are being processed. And the physics step was getting very, very tiny. Like just these 2 milliseconds. And there's some backend there somewhere that makes you crash into the crowd. And I want to fix that so that it's truly frame rate independent. 

And, yeah, if I find the motivation, I want to do some of the graphical things like lighting on the ship when you go into a tunnel that it gets a bit darker and stuff like that. And maybe, also, the more forgiving collision. Yeah, I lined this out in the blog post too. My dream would be to be paid to make a very polished version of that. It would be very cool if Sony says like, "Hey, now it's the 38th anniversary of Wipeout." It will be actually next year, I guess? 

[00:46:35] JN: It will be next year. Yeah. Yeah, we all are in remaster season. We've done Tomb Raider. It's time for Wipeout, right? 

[00:46:41] DS: Yeah. Good timing then.

[00:46:42] JN: Sony, if you're listening to this, you know where Dominic is. Yeah, that makes total sense. I hope that happens. And, yeah, I hope the big corporation is nice about it. That would be lovely as well. Outside of Wipeout, do you have any upcoming game projects you're excited about? Any other rewrites of random source code? I saw you were making a C version of Impact as well. Is that just dabbling? 

[00:47:04] DS: That is true. Yeah, I got it into this rewriting, I guess. ImpactJS was one of the very first JavaScript game engines. Maybe the first one. I'm not exactly sure. And that's from 2010. And, yeah, I got a lot of experience writing C by doing this Wipeout stuff and a few projects before. And I thought that, "Hey, it might be fun to revisit the game engine and see if I could reimplement this elegantly in C code again." 

And I've gotten pretty far now. The first game that I developed with my own game engine, Biolab Disaster. It's still playable on the web. You can now play. It's now rewritten in C and you can compile it for your desktop. And also, again, compile it with WebAssembly and play it on the web again.

[00:47:55] JN: Amazing. Love to go full circle and rewrite your web game engine to C to compile to Wasm. That's incredible.

[00:48:01] DS: Yeah. The plan for that is to just release it as open source. Maybe write a bit of documentation for it and see what people are doing with it. Yeah. Just a side project.

[00:48:11] JN: Nice. It sounds like a very cool side project. It's fun to catch the C bug. I'm glad that this is an outcome of the Wipeout project is going back and writing more C. That's fun, Perfect. Well, in that case, thank you so much for chatting to us about Wipeout. You are PhobosLabs everywhere on the internet. People want to read about your work, the upcoming engine, the Wipeout rewrite, it's on GitHub as well underneath that handle. We'll include it in the show notes. Anywhere else where people can find you that I've missed? 

[00:48:37] DS: PhobosLabs everywhere. Well, GitHub, the blog, and Twitter mainly. 

[00:48:41] JN: Perfect. Awesome. Well, Dominic, thank you so much for joining us today.

[00:48:44] DS: Thanks for having me. 

[END]