Sometimes it takes a revolutionary from humble beginnings to spark a movement against an opposing force considered too powerful to overcome… Spartacus, Joan of Arc, Andrew Jackson.., XL2..?
Okay, Okay..! I admit that comparing a somewhat imposing games console to an oppressive religious/political regime is laughable, but nonetheless, the Saturn’s complicated architecture and lack of available tools & documentation has long stood in the way of many who have come before, hoping to achieve ‘victory’ over such a convoluted yet monolithic machine… Yet this guy.., a self-taught programmer, came along and showed many of us what could be…
As a Saturn fan going all the way back to 1996, I’ve been waiting a good 20+ years for a proper Saturn homebrew scene to emerge… Sure, there were the Dezaemon 2 guys, building their own unique and inventive shooters, which is kind of like homebrew… Then you had your Game Basic folks creating fairly rudimentary 3D demos in the mid-2000’s and Rockin’B with the 2007 SEGA Saturn Coding Contest. But aside from that, it’s been a fairly barren landscape in terms of anything that would constitute an original “homebrew game”.
That is.., until 2015, when Johannes Fetz released an open source 2D/3D game engine for Saturn, written in C and allowing relative beginners to develop games easily, without extensive knowledge in embedded development. This inspired several folks and got the ball rolling by removing the steep barrier to entry that had stood for 20 years…
Fast forward to 2021, and we see a steadily growing number of developers out there working on new and original projects for a hardware once thought to be too complex with ‘limitless untapped potential’… Tools have been written. Open source libraries have been shared and utilized, and we are really just at the beginning of a story that is presently unfolding…
I was fortunate to catch up with XL2 regarding his beginnings into Saturn game development and his thoughts on where the scene stands today and where he sees it headed…
SHIRO! INTERVIEW:
SHIRO!: “Let’s start with the name, shall we? What does XL2 stand for, and how did you come by that name?”
XL2: “I was basically a kid trying to open an email account, but everything I tried was already taken… So I got frustrated and looked around my room…
I had a game magazine laying out with a feature on “Wipeout XL” for PS1…
-Me: ‘Okay, let’s try XL.’
-PC: ‘Already taken..!
-Me: ‘Arg!!!!. Ok, XL… 2’
-PC: ‘OK.’
So that’s it.., the story of my stupid name! 😛”
SHIRO!: “Where are you from, by the way?”
XL2: “Montréal, Québec.”
SHIRO!: “When and how did you become interested in game design?”
XL2: “I was always interested in game design from a young age, but I just never tried it… In Cégep (which is in between high school and university here) I had some coding classes with Visual Basic, but it was super limited, and I couldn’t code a game with that. So it’s something I gave up on for the next 15 years or so…”
SHIRO!: “Why Saturn, then? What led you to develop for this particular console?”
XL2: “I saw an article talking about Jo Engine, showing a 2D Sonic demo. It was quite nice, so I opened the website, I downloaded Jo Engine but I didn’t touch it for a while…
Then one day, in March 2017, I tried to compile my own demo. I just double clicked on compile.bat, used the yabause.bat file and there you go… my own “game”. It was super simple and beginner friendly. I just played with the code a bit, trying to add sprites and other stuff. I didn’t know C at all, and I forgot pretty much everything I had learned during Cégep (I didn’t even know that an int32_t didn’t keep decimals), but it was still fairly easy to just change a few numbers in order to have a sprite appear elsewhere.
So I tried the Jo Engine demos. I tried adding a shitty Sonic model that I made to the 2D Jo Engine demo, and then I tried to animate it. Slowly, I learned how to code, learned how C works and how 3D works, and I managed to animate that 3D model (even if it was very rudimentary). So while the Saturn is super complicated, for doing basic things with SGL/Jo Engine, it was easy to get started, thanks to Johannes Fetz aiming for simplicity. It might be even easier than trying to setup OpenGL on a PC… Even today I can code on PC, but I’m quite limited compared to what I can do on the Saturn.”
SHIRO!: “What developers and games have been your biggest inspiration or had the greatest impact on your work?”
XL2: “I’ve really enjoyed FPS games over the years, and the Saturn was my first ‘3D’ console, but I also had a 486 PC, so I also got to play games like Doom and Duke 3D there. These games obviously had a great impact, but aside from Doom, I remember getting pretty bad framerates on my PC… I also got a Nintendo 64 near launch, and the Saturn started to collect dust after that… A key reason for this was the lack of split-screen multiplayer games.
I remember buying Duke Nukem 3D on the Saturn and hoping to play split-screen matches with my friends, only to be disappointed when finding the multiplayer was NetLink only. I still played a ton of Duke 3D on the Saturn, though, thanks in part to the much better framerate than what I was getting on my 486 PC…
I also played tried Quake on PC, and the framerates were truly awful (obviously). So the first proper version of Quake I played was also on the Saturn (as a rental), but I can’t say I really enjoyed it… However, replaying the game now on PC with proper framerates, I do enjoy it a lot! Later on I tried those same games on N64 (as they had multiplayer), but compared to Goldeneye 64, they were not as good…
Another game that really inspired me was Unreal. My brother had a Pentium 166, and he bought a shiny new 3dfx card that came with a copy of Unreal. That game was truly amazing for 1998! While the Saturn will never match a Pentium with a 3dfx card, I think I managed to mimic it in several areas.
I wouldn’t say that I’m against the modern style FPS.., but I don’t feel they have much replay value, and they are often bloated with boring cutscenes and ultra linear gameplay. Old school shooters certainly had flaws, but I never mind opening one up and playing for 30 minutes, while I never come back to the Call of Duty games, for example.
So long story short.., with HellSlave, I aim for an old-school shooter with deathmatch and co-op.”
SHIRO!: “What philosophies of game design are most important to you or most prevalent in your work?”
XL2: “I try to maintain realistic short-term goals in order to keep myself motivated. I’m not going for perfectly optimized code. Instead, I try to get results quickly. Take the real time lighting in HellSlave, for example… I wrote it in one hour. I did later improve it to allow for 8 (now 9, including fog) dynamic light passes per vertex, but the base implementation was written very quickly…
Very few original homebrew games get far, because I think most people treat it like work.., trying to optimize every single function and losing their motivation along the way…
Sure.., lots of things could be improved, but since I do this for a hobby, the number one rule should be to enjoy doing it. So typically, if it’s not broken, I don’t bother fixing it…
Adding features is one way to keep myself motivated, kind of like a tech demo on an actual game. Light flares, additive transparency, fog, real time lighting, unlimited draw distance, etc… I do need to improve functions (and my engine is insanely complicated), but I try to make those changes in small chunks over a long period of time.”
SHIRO!: “Can you tell us about Sonic Z-Treme? How did it come about, and what are your future plans (if any) for the project?”
XL2: “Ah, Sonic Z-Treme… I had started playing around with Jo Engine, as I mentioned previously. I learned a lot about programming, but around two months into learning to code, I started trying to add a 3D world around my 3D Sonic model. First, I tried with Peach Castle from Mario 64, but I knew nothing about collision detection, so I just wrote a very basic bounding box system.
I needed a ‘blocky’ world to test collision, and since I was already playing around with a 3D Sonic model (to test 3D and 3D animation), I figured I could just try doing some Sonic X-Treme style levels to match the collision detection system (which only worked with blocks). I thought I would just create a ‘cheap game’, with a few worlds & truly awful code and just call it a day… All I had was a few 3D models, and I created a world by joining together blocks. Everything was hardcoded.
I gave it the name Sonic Z-Treme, as the camera (Z axis) could move around, like a ‘real 3D’ version of Sonic X-Treme. It was also a super cheesy name for a cheap project that wasn’t taking itself too seriously. However, after uploading a video of this project to YouTube, Andrew75 (the guy behind a Sonic X-Treme recreation project called AXSX) reached out to me and sent me his Jade Gully map, which was a 3D model. So I actually needed to write a model converter, get the Saturn to load the maps from a disc, implement proper spatial partition using a uniform grid, etc…
In November, 2017, I had a first ‘public’ demo that ran at 60 fps, but it had a really bad draw distance. I was able to improve it a lot by using an octree and playing with palette code to have a smooth fade in/out system like Sonic R. I also promised to write a model converter for Ponut64, as he was trying to load models on the Saturn at that time, and while I also needed an animation system, I had very little time. So I quickly implemented a vertex animation system that I’ve been using ever since…
I released a demo for SAGE (Sonic Amateur Games Expo) 2018, which got a lot of attention for what started as a cheap FPS project that was actually written in only 2 months (the majority of the time was spent on tools and experimenting different things, like spatial partition, collision, etc…).
As for the future of Sonic Z-Treme, I don’t really have any plans to finish it.
I did recreate the Metal Sonic boss fight, which was mostly for testing sprite compression/decompression and VDP2 stuff (reusing VDP2 stuff ripped from the Sonic X-Treme 718 leaked demo). Andrew75 and other people from the Sonic X-Treme Unity discord helped me with texture assets and the small ring. That was a very quick and simple project, and I did enjoy it. I might create other boss fights someday, but I can’t really make any promises…
SHIRO!: “How did the project shift from Z-Treme over to HellSlave?”
XL2: “I never really planned to make a proper Sonic X-Treme remake…
(I didn’t even think I could get as far as I did when I started), but I really wanted to make a first person shooter. As I created Sonic Z-Treme, I experimented on a 3D shooter using SGL (Sega Graphics Library). Before releasing the Sage 2018 Sonic Z-Treme demo, I had already moved on from Jo Engine to SGL exclusively, to gain better performance and more flexibility. But SGL was not suitable for a shooter, so that project was dropped.
I later used what I had from Sonic Z-Treme and wrote a Binary space partition (BSP) compiler on PC to allow pre-calculated visibility. Over the course of 2019 I fully dropped SGL’s rendering code in favor of my own, which included my own polygon transformation code, which offered huge leaps in graphics by having almost full control over the pipeline.
I made a public version of that demo for SAGE 2019 simply named ‘Project Z-Treme’, as it built upon what I wrote for Sonic Z-Treme… Very little remains from Sonic Z-Treme now, but I still kept the engine name, because… why not? I kept improving the engine, now allowing support for Trenchbroom (a mapping program for Quake/Half-Life) to create brushes, while my compiler takes those brushes to generate polygons, BSP tree, sectors and portals, etc… The SAGE 2020 demo showed off those improvements, including extra details like decals, reflections, etc…
And as of now, I’m still adding features, like far away polygons being rendered as a huge textured polygon, to allow N64-style draw distances or pseudo-volumetric fog. My time spent on this project is now more limited, so improvements have slowed down a bit, but there are still a ton of things I would like to add. As it stands the engine is good enough to create a full game, I suppose.., but I think it still needs some additional improvements before I can focus entirely on the gameplay and finish it up. I may soon also drop SGL completely in favor of Yaul (an open source library), which will take some time…”
SHIRO!: “HellSlave takes clear inspiration from Lobotomy’s FPS games (as you mentioned), so in what ways will you seek to differentiate the project from those games?”
XL2: “Yeah, it does take inspiration from Lobotomy’s games… (after all, I did name my fake company ‘Vasectomy Software’). Their SlaveDriver was such an impressive engine! Fully 3D worlds with real time lighting in 1996? On the Sega Saturn..?! That was great! Sadly, I don’t think Lobotomy got the full recognition and appreciation it deserved back then, even if PowerSlave could have been a better game… (I don’t think anyone likes fighting spiders, bees or birds!).
One key difference between my engine and the Slavedriver engine is the split-screen multiplayer. I make sure that the full campaign can be played in co-op split-screen, which is an extra challenge when designing the levels and engine to make sure it’s playable. Split-screen co-op was very rare back then, so I’m quite happy with it (even if, to be honest, the amount of people who will sit with someone else and play this can likely be counted on one hand…). Also, 4 player split-screen deathmatch is another nice thing to have. I would like to add proper bots someday or perhaps some kind of online play, but I’ve never coded either of these so we’ll see…
As for the gameplay, I have most of the things needed for a PowerSlave type game, but I’m not yet sure if I’ll go that direction as opposed to standard linear progression… I feel that linear level progression is better for replay value, as no tedious backtracking is involved, but that might be just me…
Another thing that sets HellSlave apart is, of course, technical features, such as real time lighting on 3D entities (enemies), 3D weapons, real additive transparency, transparency+reflection+vdp2 layers, pseudo-volumetric fog, huge draw distances, etc… These things are mostly cosmetic, but it definitely adds to the experience in my opinion.”
SHIRO!: “What types of features and improvements do you plan to incorporate?”
XL2: “I want to simplify the level making process so more people can create levels for the game. I want to add under-the-hood improvements, like better collision detection, and I also want to implement a sound driver that will enable different sound effects per map. I’d also like to pack different 3D entity models per map (weapons, enemies, etc.) in order to allow mappers the ability to create completely different experiences. I don’t know if I’ll add a scripting system for things like weapons or AI, but I do want to add more features to the map compiler to allow for more in-game interactions.
For example, now you can turn off/on lights, open doors, shoot a switch to bring down an elevator, etc., but I want to expand upon those to allow more variety in gameplay. I’ve already shared (to a limited number of people) the files needed to create maps. There’s a huge learning process involved, but people can already create their own maps and compile an ISO image, so technically, someone could create a different game once I allow per-map 3D models/sounds. Without AI/weapons scripting, it may not feel different from what already exists, but I’m working very hard on additional flexibility and simplicity.
I’d also like to add multiplayer bots and/or online support at some point. I can’t even play my own game in deathmatch mode presently (I doubt my 10 months old son would be a great challenge), so that’s something I would like to experience. 😉”
SHIRO!: “From your personal perspective, what can you tell us about Saturn development?”
XL2: “From my point of entry, it’s been brutal in some ways, as I stared learning to code in my own free time, but it always feels great to see things I’ve created working on my TV! The hardest part, really, is the fact that you need to create all your own tools, write all your own collision detection routines, all your own occlusion culling functions, etc… (I probably spent 80-90% of my time on my BSP/map compiler and other tools).
Like, if you were to start writing a game today, you would probably have to write all the necessary tools yourself, as there is no ‘one-size-fits-all’ solution for the Saturn...
Another hard thing, when it comes to homebrew development, is the lack of time… I can often spend one or two months on something that might take less than a day if I was simply able to focus full-time on it. So progress is slow, and everything takes a long time. Sometimes you pick up something you started months ago and try to make it work, only to have forgotten exactly how everything holds together internally, because it’s been so long…
It’s quite hard to make significant progress in short 30 minutes bursts! It certainly results in ‘ugly code’ (I never shared my BSP/map compiler for good reasons!) and the feeling that everything is holding together with cheap glue, tape and prayers.., but it’s either that or no game from my point of view.
Since this is just a hobby after all, these games don’t make you money, so you need some sense of progression in order to keep your motivation… I’ve seen so many people arrive in the forums, promising grandiose games fully written in assembly, and (as usual) nothing ever materializes, as they often spend six months writing a useless function in the most optimal way but at the cost of completely losing motivation… Meanwhile, others like me simply focus on getting things working as quickly as possible.
Of course, there are more experienced programmers out there who could do it both faster and better, but at my level of skill, that’s my current mindset… focusing on engine optimizations instead of micro-optimizations.”
SHIRO!: “What have been your greatest challenges working on this (and previous games) on this hardware?”
XL2: The engine (and mostly the BSP compiler!) is my biggest challenge. It’s very complex! Sonic Z-Treme had such a simple system by comparison, but, of course, it couldn’t push the hardware nearly as much… With my current engine, I try to keep overdraw to a minimum, while also keeping CPU usage low, on a BSP-based engine. I also allow multiple lighting passes per vertex plus additive transparency using both the VDP1 and VDP2.
Several people warned me (before I started) that a BSP-based engine (which is what Quake used on PC) wouldn’t work on the Saturn, but it works just fine thanks to the SH-2 being good at multiplications…
The Saturn is always challenging… The lack of texture (UV) coordinates is super annoying! Since all my levels are ‘generated’ by my BSP compiler from simple brushes, you can’t hand correct the individual polygons, which results in squished textures wherever there are triangles. It also makes dynamic subdivision more tricky than it should be.
I also hate the lack of support for additive transparency on VDP1. It can do half-transparency (sum of color 1 and 2 divided by 2), but for whatever reason, it cannot do additive transparency (color 1 + color 2). And even the half-transparency is broken, once you distort the sprites… So I had to make a complicated workaround for additive transparency using a technique very similar to what Burning Rangers did, by drawing the elements that are to be transparent on the outside area of my framebuffer (coordinates X: 352 to 511, and Y: 0 to 111) then doing a DMA transfer of that area to the system’s main RAM… and then doing another DMA transfer to VDP2 RAM, because you can’t do direct DMA transfers between the two!
And that brings about even more problems, as those transparent polygons aren’t overdrawn by other polygons, so I need to render black polygons in order to have some occlusion (and the resolution is fairly low).
SHIRO!: “If you could change anything about the Saturn’s hardware, what would you change?”
XL2: “The VDP1. I would make it have UV coordinates, fix the half-transparency issue and make it support additive transparency. Having a Z-buffer, perspective-correct texturing and 24 bpp support would also have been nice, but in the context of 1994, that would not have been realistic…”
SHIRO!: “What are your thoughts regarding the current Saturn homebrew scene and the future of homebrew development on Saturn?”
XL2: “I think it’s picking up. When I started, I was pretty much the only one doing 3D on it, but now we see more and more projects. ‘Noah‘ from Misscelan, ‘Cubecat‘ and Ponut64‘s game… Those are just a few examples of very promising projects currently being worked on.
I think it’s only going to get better with more projects. One person wrote a new sound driver that allows up to 8 ADPCM sounds on the SCSP using its DSP, while Ponut64 is also writing a new driver supporting PCM and 1 or 2 ADPCM sounds using the 68k. Many people are trying to make good use of the SCU DSP.
I think we’ll see many new amazing projects in the near future, so it’s quite exciting!”
A massive Saturn fan since Christmas ’96, Dave is enthusiastic about growing the community and spreading Saturn love and knowledge to fans old and new. Co-founding the SEGA SATURN, SHIRO! podcast back in 2017 and creating the SHIRO! SHOW in 2020, he seeks to create interesting and engaging Saturn-related content for the community. Dave’s interests circle around game preservation, and he is a huge fan of game magazines and developer interviews.
Your best interview so far. Thanks so much for this
incredible work, much respect. Please keep developing