The Modern .NET Show

From Zero to 3D: Ben Bowen on TinyFFR's Rapid .NET Rendering

Sponsors

Support for this episode of The Modern .NET Show comes from the following sponsors. Please take a moment to learn more about their products and services:

Please also see the full sponsor message(s) in the episode transcription for more details of their products and services, and offers exclusive to listeners of The Modern .NET Show.

Thank you to the sponsors for supporting the show.

Embedded Player

From Zero to 3D: Ben Bowen on TinyFFR’s Rapid .NET Rendering
The Modern .NET Show

From Zero to 3D: Ben Bowen on TinyFFR's Rapid .NET Rendering

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

This week on The Modern .NET Show, Jamie Taylor welcomed Ben Bowen to discuss TinyFFR, a passion project born from a desire for a more accessible approach to 3D rendering in C#. Ben, a software engineer with experience in both enterprise and game development, explained that TinyFFR aims to fill a gap in the market – providing a lightweight, modern .NET library that allows developers to quickly create and experiment with 3D scenes without the overwhelming complexity of full-blown game engines like Unity or Unreal. He highlighted the appeal of a ‘software-first’ approach, enabling developers to build up scenes from a blank C# project and retain complete control over the rendering process.

The conversation delved into the importance of side projects for developers. Both Jamie and Ben emphasised the need for creative outlets outside of daily work, describing these projects as sources of enjoyment and a vital means of preventing burnout. Jamie drew a parallel to the concept of ‘play’ as a recreational activity with no specific end goal, allowing for relaxation and a refreshing change of pace. Ben shared how building TinyFFR has been a consistently engaging experience, contrasting it with the potential slog of working on large, pre-existing codebases.

A significant portion of the discussion revolved around the exceptional documentation for TinyFFR. Jamie praised its clarity and design, noting the inclusion of collapsible sections which cater to users of varying levels of expertise, allowing them to delve deeper into the underlying theory as desired. Ben explained that this approach stemmed from a belief that good documentation is crucial for the success of any library, and a conscious decision to prioritise user experience, particularly for hobbyists with limited time. He also attributed the quality of the documentation to the freedom afforded by working on a personal project, allowing him to invest the necessary time and effort.

The pair explored the challenges of cross-platform development, with Ben detailing his experiences supporting Linux alongside Windows and macOS. He highlighted the complexities of catering to the fragmented Linux landscape and acknowledged Apple’s restrictions regarding virtualisation, requiring him to rent Mac hardware for testing. However, he remained committed to cross-platform compatibility, recognising the benefits of .NET’s versatility and the growing popularity of platforms like SteamOS. Both agreed that while cross-platform is hard, the modern .NET ecosystem makes it significantly more manageable.

Episode Transcription

For me it’s born out of, I mean the old phrase right, that necessity is the mother of invention. And I want to make games actually, but I think there’s a missing middleware in the industry at the moment for certain types of game developers.

- Ben Bowen

Hey everyone, and welcome back to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. I’m your host Jamie Taylor, bringing you conversations with the brightest minds in the .NET ecosystem.

Today, we’re joined by Ben Bowen to talk about TinyFFR - a cross-platform library for .NET which allows developers to render 3D models. TinyFFR came from Ben spotting that there is a gap in the Games Development tools market: somewhere between 3D modelling software and a full-blown game engine.

I, personally, believe that a library or software middleware is only really as good as the documentation that comes with it. You probably drive away 90% of the potentially interested parties if you’re just saying to them, ‘hey, if you want to learn how to use this, you’d better go spelunking through the source code or looking at examples.

- Ben Bowen

Along the way, we talked about the importance of really good quality documentation. And it should come as no surprise to you that we talked about this because the documentation for TinyFFR is fantastic. Seriously folks, when you’re done listening to this episode, go check out Ben’s Hello Cube tutorial for TinyFFR and you’ll see what I mean.

So let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

Jamie : So Ben, welcome to the show.

Ben : Hi Jamie. Thanks for having me.

Jamie : Very welcome on the show. We’re going to have a conversation about something that I think is super important for developers, and I feel like everyone’s ears have pricked up. They’re thinking, he’s going to talk about mental health. Maybe I am in a roundabout way, but we’re going to talk about a personal project of yours that is something fun that you like to do, right?

Because it is so easy, and we’ll get into this later, to fall into the trap of ‘I do the thing for work and therefore I will only do this one very specific part of the thing.’ Whereas I actually think that having some fun project to work on outside of all of that makes life worth living, right? Variety is the spice of life, as they say.

Ben : Absolutely, yes.

Jamie : So we’ll talk about that in a moment, but I wonder if you would mind giving the folks a little bit of an intro to you—a little bit of a taste of who’s Ben, what’s he do, you know, that sort of thing. I know that we were chatting offline about how we’re both in the enterprise. So, you know, that’s the boring day job. If you want to talk about that, you can. If you want to talk about all the cool fun projects you’ve got going on that you like working on in your own time, that’s also cool too.

Ben : Sure. You’ve had some very esteemed guests on here, so it’s hard to live up to some of the competition, but I’m just a software engineer. I’ve worked mostly in science and technology industries like green energy and the defence sector. I’ve done a lot of C#, cloud work, and also control surfaces—a lot of WPF, Avalonia, that sort of thing.

Like quite a lot of programmers, I’m a hobbyist game dev as well, which is where perhaps TinyFFR comes in. I do have a game on Steam I wrote about 10 years ago. It was on a custom game engine. It took me like two and a half years, and I sold about a hundred copies, so in terms of commercial success, not a success. But I did learn a lot, so that’s something.

Most recently, I’m an author of TinyFFR, which is my C# real-time rendering library and very much a passion project at the moment.

Jamie : Nice. I wouldn’t put a hundred sales of a game down as a failure. That’s a complete success from my perspective. You know, you set out to achieve something, you achieved it, and then other people wanted it as well. That to me is fantastic.

Ben : That’s kind of you.

Jamie : No, it’s the truth though, right? Just think of all the other titles that are on Steam or anywhere else that don’t get anywhere, right? Somebody puts years and years of effort into it and nobody hears about it. Nobody wants it, right? So you’ve done loads better than everybody else, right? That’s something.

Ben : Thank you. Yeah, that’s something.

Jamie : As you said, we’re going to talk about TinyFFR. We’ll come on to why you had the idea of writing this library in a moment, but I think it’s worth just reiterating what I said earlier on about having something that you like doing that is not just your job, right?

It doesn’t have to be related to computers. There’s this wonderful—I want to say it’s McEwan has this book out called Play—and they describe play as an activity which doesn’t necessarily have a means to an end, right? Anything which doesn’t necessarily have a means to an end can be seen as play and therefore is recreational and just chills us out.

Even though with this particular project you’ve spent lots of time building it and writing software and writing documentation, which we’ll get onto in a moment—because the documentation is ace, spoiler alert—you’ve put all this effort in, but I have a feeling from the way that it’s been built up, it’s not been like a slog. It’s not something that you’re like, ‘Oh God, no, I’ve got to work on TinyFFR again.’ You know, it’s not that. It’s like, ‘Oh my goodness, the day has ended and I have half an hour—let’s do this thing with TinyFFR,’ right?

Ben : Yes, pretty much. I mean, I don’t want to oversell it. There have been days where I’ve had to push myself, especially when dealing with perhaps some cross-platform issues—like macOS doesn’t want to disable v-sync or something like that. There are hard days. But overall, absolutely right, yeah. It’s something that I always wish I had more time to do. I’m waiting for the end of the day. I’m planning to have time to work on it. So yeah, you’re absolutely right there.

Jamie : Yeah, ace. I feel the same way about an open source library that I wrote that aims to try and make it easier for ASP.NET Core devs to inject OWASP-recommended security headers. When I get the chance to work on it, I’m like, yes, this is something I’m super passionate about. I want to do this now. Even if it’s just I want to read through the code for five minutes because I’ve just got five minutes. So, you know, I totally get where that’s coming from.

I also fully appreciate that, ‘Oh no, I’ve got to do this PR because I promised someone that this would get out there.’ You know, past me is the worst because past me made the promise, but present me has to deal with it, you know?

Ben : Absolutely, yeah. I completely agree. Also, I don’t know about you, but I find a lot of my spare time when I’m just—if I’m driving to work or I’m in the shower—I’m often thinking about it. If I’m not working on it, I’m thinking about it.

Jamie : Yep, yep. It’s the curse of having that one project on the brain. How I’m sure that I can figure that out. Then the worst thing is you’re doing something, you’re miles away from a computer, and then your brain goes, ‘Hey, you know that thing you were thinking about? Yeah. Here’s the answer.’

Ben : I hope you’ve got a pen and paper ready.

Jamie : Oh, the worst ones for me are at 2 a.m. in bed, and I’ve got to decide am I going to remember this if I don’t write it down? It’s anxiety-inducing, you know?

Ben : Absolutely.

Jamie : Let’s talk about TinyFFR then. So what is it, right? I mean, I know what it is. I’ve been playing with it for the past few weeks, but what is it?

Ben : Sure, so it’s—in a nutshell—a real-time 3D rendering library aimed at C#, modern C#. I’m targeting .NET 9 plus at the moment. For me, it’s really born out of—I mean, it’s like that old phrase, right?—that necessity is the mother of all invention. I want to make games, actually, but I think there’s a missing middleware in the industry at the moment for certain types of game developers.

Obviously, you’ve got your game engines. Everyone knows that—you’ve got Unreal, Unity, Godot, and others. They’re great. I mean, obviously for certain types of games, if you’re like a AAA studio or you’re perhaps primarily art-driven as a studio or developer indie, then these tools—they’re massive, they’re behemothic. They have a lot of tweaking, a lot of functionality, you know. They cater not just to the game development industry often, but also like movies, film, TV. So they have a huge suite of tools for building up these really amazing scenes, if you like.

I have tried to use these engines. So, for example, imagine something like Minecraft, right? Imagine you wanted to make Minecraft today. The creator of Minecraft when he did that, he wrote it in raw Java, and there’s a reason for that. He could have done it in a game engine. There’s absolutely no reason he couldn’t have. But I think that there’s a certain type of approach that some more systems-driven designers maybe want to go with. For me, that’s the software-first approach. I think a lot of software engineers like to approach a project from the ground up rather than trying to integrate something into an already existing huge project like a game engine, right?

For me, when I want to think about making a game, I’m often thinking, I just wish in the industry, in the world out there, there was a library—I could just tell it, ‘Hey, render—I want to load a tree asset or I want to load like a gun or whatever it is, right?’ Just render it here. I want to build up my scene and my rendering and my game logic from a blank C# project. It’s not for everyone. I don’t think it’s ever going to replace a game engine. I don’t think it’s for everyone. But that for me was actually what I’ve always wished existed. That’s why I started building it.

Yeah, it is a passion project. I’m probably a better software engineer than I am a game designer, so it’s probably a good place to be. But yeah, for me, it’s delivering a need of something that we don’t currently have in the ecosystem.

Jamie : Here’s what I love about that, right? You saw a thing where you were like—I’m not using your words exactly, but—if only I could load this 3D model into a scene, and then I can play around with it and I can see what I can create with that, right? Almost like a toy box, a sandbox to just draw some 3D models, some assets around, some textures, a little bit of light mapping. Hey, look at that—I’ve created something, right?

Because otherwise, what you’re going to end up doing is—I don’t know if you’ve seen them, but there’s a wonderful series, and I think it’s still going, and it has been going for I want to say ten years, and it’s called Handmade Hero.

Ben : Yes, of course, yes.

Jamie : Yeah. Every single line of code in that engine is handwritten.

Ben : That’s right, yeah.

Jamie : Casey spends—at least at the beginning, I’ve not kept up with it, but at the beginning he spent hours just talking to camera about, ‘Okay, so we’re going to write a line of code that does this, and then we’re going to write a line of code that does that,’ and then slowly building everything up, right? Maybe using libraries to draw to screen or whatever, but other than those types of libraries, every single line of code was handwritten. That is awesome. But also it’s ten years. It’s probably longer than that, right?

Ben : Yes, absolutely. Like I said, I don’t think that this approach is for everyone. I don’t see big studios switching to TinyFFR. I don’t think it’s appropriate for that. But I think that there’s a certain type of software—even if it’s all just hobbyists—and nothing ever happens. They never, you know, finish something. That’s fine. I still think there’s a place for it there.

But yeah, I think that there’s a space. I mean, there’s other advantages too, actually, of having a library like TinyFFR. If we broaden our scope out of perhaps game dev a little and look at maybe the wider industry, like scientific and industrial applications or 3D modelling and perhaps even tools that are built for games or game engines. I think that there’s probably a really nice space there.

For example, let’s say you wanted to build like a 3D model viewer into your tool chain, right? You could build a little Avalonia app—TinyFFR integrates with Avalonia or WPF—and you could write some tool that could inspect your exported models from Blender before you put it into your engine within, you know, that would be like a night’s work. Whereas before you would have to have some expert in OpenGL or DirectX to write all of that rendering scene for you. So I think there’s that portability of the library, which I also think is quite useful. But as a game dev, me, I’m always envisioning using it for making games as well. But yeah.

Jamie : But it also gets you from either ‘I have 3D modelled something’ or just ‘I am playing around with code’—from either of those two perspectives, you go from zero to ‘I have something on screen’ like very, very quickly, like rapidly, almost as quickly as how we used to build apps with WinForms, right? The reason that WinForms was huge was because it was literally drag a button, let go, double-click it, and you have your button, right?

Whilst it isn’t maybe as rapid as that, if you have a 3D asset and you have the right lines of code, you write maybe 20, 30, 50 lines of code, hit run, and there’s your thing with some lighting applied to it and maybe if you’ve got one, a texture as well, right? You’ve gone from zero to that rapidly, very rapidly.

For me, regardless of whether you’re from the 3D modelling space or just a dev trying something out on your machine, that ‘go from zero to that that quickly’ is the dream, right? Because then I’ve gone past the point of the toil and the setup.

We were talking offline about how the last time that I did stuff with 3D was back at university and we did it with OpenGL. At that point, we were pulling in a DLL and dynamically loading it, right? We had to do P/Invoke to get to it. This particular library wasn’t—this was .NET Framework, right? .NET Framework 2.0. This was, I think, before NuGet as well, right? So you had to put the DLL in the same directory as your EXE and hope that it worked. But then there was loads of setup required. You had to P/Invoke a bunch of stuff. You had to create a window handle. You had to do all this stuff.

Once you had the 200 lines of requisite code—not including all the other cruft that came with it, like all the namespace declarations and the braces and all that—once you had the 200-plus lines of code, you’ve got a black screen. Then you started working, right?

Whereas this, it’s like dotnet new, copy-paste 10 lines of code, boom, you’re in.

Ben : Right. I’m really over the moon that you found that was your experience with it. That’s basically exactly what I’m trying to capture.

Yeah, that’s basically it. The nice thing about where you start from there is you have a lot less out of the box than maybe you would with a game engine or something. But you’re in full control of what you’ve got. You know everything that’s happening. You’re rendering everything as you’ve written out in C# in those 20 lines, and you can build on top of that. For me, that helps me keep that context window of what’s going on a bit lower, which I quite like as well. But yeah, I’m really, really pleased to hear that you had such a smooth and rapid experience with it. That’s definitely part of the point for sure.

Jamie : Yeah. Oh yeah, definitely. I completely understand where you’re coming from with that—keeping the context in your head and, you didn’t say it, but the reduction of scope of what this thing is going to do whilst I’m playing with it is so important, especially with anything to do with graphics. I’ve noticed that like, ‘Oh, but if I add this, it’ll look—and then I’ll add this. Oh, and maybe I’ll add this really cool funky effect that if you push these four keys, it does it.’ That’s totally fine. But also it’s distracting from you reaching the goal.

Ben : I think so. I think there’s an allegory there with—so I used to make music. I don’t anymore, but you know, I used to. At one point I went through this phase—I bought all these VSTs, so these effects essentially for my DAW, and I had, I had at one point about like 200 different effects processors, right? For my music.

I went through about a year of just playing with the effects processors rather than making any music. I think actually once I sold a lot of my gear and reduced it down, I actually became quite a lot more productive. I think that’s probably similar to what you’re saying there, I think.

Jamie : Oh, a hundred percent. A hundred percent. I know quite a few musicians who have gone through what they call their minimalist phase. Where they do exactly that. They’re like, right, I have 12 guitars and three amps, and you know, two laptops with completely different setups for my digital audio workstation DAW. I’ve got all these effects pedals. I never use them, you know, all this stuff, and I haven’t played anything in a year. Maybe the reason for that is because I’ve got all of these things, right?

Ben : Yeah, it’s choice paralysis ultimately, you know, it’s overwhelming, yeah, for sure. Absolutely.

Jamie : So what I’d love to talk about is there are two really big parts about TinyFFR that I would love to cover because I think that a lot of people can take some inspiration from what you’ve done with at least one of these.

The big one for me is the documentation. So when it comes to reading through documentation for libraries, for me it’s always a big thing about how do I get started quickly? But also—and you can tell where I’m coming from with this—how do I get started securely? Now we don’t have to worry about the secure thing with TinyFFR, because it’s a fun 3D application—you don’t have to worry about, ‘Wow, this is going to steal my credit card numbers and stuff,’ right?

Ben : Hopefully not, yeah.

Jamie : But my biggest thing has always been how do I go from zero to not just having something on screen that I can interact with, but understanding how it’s working. I have to say, genuinely, the documentation for this library is outstanding. It really is. For those who haven’t seen it, and you should definitely go and check it out, there’s a getting started like with everything, and then there’s a ‘Hey, do you want to learn how this stuff works? Well, check this out,’ right?

We were saying—I was saying offline—how you can read through the documentation and there are sections that are collapsed. If you don’t expand them, you don’t necessarily need to know what’s in the collapsed sections because it’s like, ‘Here’s some of the theory behind how it works,’ or ‘Here’s what we’re actually doing,’ right? So if you expand them, your knowledge increases a whole bunch, right?

I feel like a lot of library maintainers and documenters don’t do that. I feel like they should. Rather than just going, ‘Oh yeah, just put the number three there and it’ll be fine,’ it’s like, well, why am I doing that, right? What’s going on here, right? Oh, this is our default. Right. Why is it your default?

I genuinely feel like the documentation there is designed. I mean, you said yourself, right? You’ve come from a games development background, a games design background, a musical background as well. So all of that will be mixing in as well. This is why I always say to people, have an interest outside of development, because you can bring it back to your own practice.

So I just want to talk to you about and ask you some questions about the documentation, right? I can imagine if you’re elbow deep in something, taking the metaphorical step away so that you can see where a new user is coming from is actually quite difficult, especially with a topic that is—mathematics and 3D rendering go hand in hand.

I suck at maths and I used to teach it, right?

Ben : Wow, okay, cool. I say cool only because I actually wanted to be a maths teacher for a small period. I went and did a little stint in a secondary school. What level did you teach?

Jamie : Yeah, secondary school.

Ben : Yeah, yeah. Oh, cool.

Jamie : For international listeners, that’s age eleven through to sixteen.

Ben : Yes. High school, I guess. Oh, they have middle school as well in America, right? So middle school and high school, is that right? I think so. Yeah. Were you a maths teacher for long?

Jamie : Oh yeah, just under two years. I can’t tell you the exact dates, but it was like—if you’ll remember the name, the volcano in Iceland that went up that almost no one can pronounce the name of.

Ben : Yes. I’m not going to try.

Jamie : That was like the end of my teaching stint. Because I’d actually at the time gotten an offer for a job somewhere else in the world. Then, like, literally the day that I was due to fly out there, the volcano exploded. They said, ‘Well, if you can get here in the next 48 hours, the job is yours.’

Ben : Oh my god. Oh my god. Did you?

Jamie : I did not.

Ben : Oh, I’m sorry.

Jamie : Hey, it’s all good. It’s all good. But, like, if that hadn’t have happened, I wouldn’t have gotten back into software dev, right? So my degree and my passion from being a kid was all software dev and that stuff. Then it was like, ‘Well, I’ll try this teaching stuff for a little while,’ and I enjoyed it. Then, yeah, I got this offer of a job elsewhere in the world and that fell through and I was like, ‘Well, I’d better go back to being a dev then, hadn’t I?’

Ben : Well, what’s—like, all paths lead to Rome, is it? All paths lead to software dev. It’s inescapable.

Jamie : A thousand percent. All paths lead to the compiler.

Ben : Yes. Well, first of all, thank you for your very, very complimentary comments about the documentation. I think, you know, first of all, I personally believe that a library or software middleware is only really as good as the documentation that comes with it. You probably drive away 90% of the potentially interested parties if you’re just saying to them, ‘Hey, if you want to learn how to use this, you better go spelunking through the source code or looking at examples.’

I mean, I think we all do it to some extent in our day-to-day work. You need to have that skill. But I think if you’re trying to appeal to the evening hobbyist who’s got an hour after they’ve put the kids to bed and cooked dinner and, you know, I think you need to go a little extra for that.

Yeah, in terms of taking a step back and putting yourself in the eyes of someone who maybe isn’t au fait with what you’re working on, I—yeah. It’s almost like a form of empathy, I suppose, but for me, the reason you don’t see it as much is probably not because people aren’t capable of that or want to do that. I think probably the reason most documentation out there is poor is because software engineers just aren’t given enough time to make it good, right? I mean, management don’t really care, they don’t see the tangible benefits, so yeah, that’s typically the way these things go, right?

But again, with a hobby project I get to be my own manager. Frankly, it’s taken me an awful long time to get to this point, so maybe there’s a reason people don’t do it this extensively. But yeah, it’s one of the benefits of it being completely under my own control, I suppose. Yeah.

Jamie : So you’ve tapped into something there that I’ve been chasing after for a long time, and that’s this idea of getting devs to have empathy for the user of the software that they create, right? I’ve given a whole bunch of talks on this subject over the last two or three years about having that empathy—really trying to see it from the other person’s perspective. What are they trying to achieve? How are they going to achieve it? How can I set them up for success?

Whether that is an end user of the software, you know, your grandma or the butcher or someone like that, right? Or your best mate using an app, right? Or whether that’s another dev or anywhere in between, right?

The idea of taking a step back and trying to empathise with what is it that they’re trying to achieve. I’ve said to them, right, and this is an implicit thing that is provided throughout all of open source software is: I’ll make this easier for you if you just do this, right?

I don’t think many people realise that that’s the contract you’re giving out to the consumer of your library or the consumer of your API is: I will make this easier for you if you just do this. Putting yourself—reversing the roles and saying, if I was in that position, what would I want? What help would I need? How would I get started? That to me is like—that’s the pinnacle, I think, of how to come up with helpful documentation. So I think you’ve hit the nail right on the head there.

Ben : Sure, yeah, and I definitely hear you, and I’d even go as far as to say I think it goes deeper into even the way you design your API, right? So I’ve spent a lot of time actually just looking at the way my API is laid out and even the naming of everything, and I’ve gone through a few different iterations before it even went public of how everything should be named and trying to make the API surface as plain English as possible and also consistent, self-consistent.

I think that’s—it’s almost like another form of documentation when thinking out loud, but it is another huge part of that for me. But yeah, I do—yeah, it’s definitely an empathy thing. It’s being able to step outside and put yourself in the shoes of someone else.

I think, you know, what you were saying about why WinForms was so popular. I can’t remember if we spoke about that offline or online, but you mentioned how one of the reasons why WinForms took massive hold when C# first came out was because it was so easy, right?

Even if we look at it now from a technical—we put our technical hat on and we say, well, actually there’s a lot of problems with WinForms, you know. You really should be using WPF or something like that. You know, it’s far superior in the way it’s built both in the back end and the way it forces you to structure your programs. That doesn’t stop people still in 2026. People will be making new WinForms apps, I guarantee it. Because it’s just—it prevents that initial intellectual hurdle that something like WPF, which is definitely a better technology, but you need to put in the effort and the work to learn XAML and the way that WPF does things and arguably it’s not that well communicated. So I definitely think there’s value in something being designed with empathy.

Jamie : Oh, I mean, a thousand percent. To your point, .NET 8, 9, and 10 all shipped with ‘Here are the improvements we made to WinForms.’

Ben : Exactly. Yeah.

Jamie : Just like you said, the reason that people will build stuff with that is because I don’t want to have to learn a whole GUI framework just to be able to do the thing that I want, to produce the report that I want, or maybe I pick a file—like maybe I need to do some processing on a file, right? I’ve got this text file and I need to do some processing on it, but I want to do it in a visual way because maybe I prefer to work in a visual way.

Well, okay. I can grab Tkinter or Tk or I can grab WinForms or I can, you know—I’m going to upset some people, maybe not modern Angular or React because I feel like they’ve gotten way too complex. But you can grab something like that, right? There is a file picker component. That glues in with the UI component. Then that can be glued together with the ‘here is where my block of custom code in perhaps a thread exists,’ right? All of these things are taken care of. Just give me the ability to select a file from—because maybe I’m not building it for me. Maybe I’m building it for, you know, my mum. Or maybe I’m building it for someone who is—you know, my neighbour or someone like that who isn’t really technically au fait. They just—they’re never going to want to see a command-line interface, but they’re going to want to see a window, right? They know what to do with a window, right?

Even the youngest people in my extended family, they know what to do with windows, icons, menus, and pointers. But if I give them a black screen with a blinking cursor…

Ben : They’re lost, right?

Jamie : Of course, yeah.

Ben : I—yeah, and even I think even for people that do have expertise as well, you know, not every single one of your audience are going to be experts in your tools’ ecosystem, right? So, for example, where I’ve worked before in the green energy sector, we—you know, I’d have embedded engineers that needed to write a control surface, a controller window for their embedded devices, and it was just running on a Windows laptop talking over a serial port or an Ethernet port to something like a motor.

They reach for WinForms every time. It’s not a failing. They’re very, you know, extremely competent, accomplished, intelligent, educated people. It so it’s not a problem that they couldn’t learn WPF. It’s just they’re going to ask, well, why should I, right? When there’s something that works so much easier. Not every application needs to be that complex.

Circling back to TinyFFR, I think it’s analogous to that perhaps where, you know, not everything needs a game engine, perhaps, to render stuff in 3D. Or the alternative is that, you know, if you want to take your command-line example, right? You’ve got your raw DirectX or Vulkan or OpenGL or whatever. That’s like your command line, and then you’ve got your game engine, that’s like your WPF or something like that. Then there’s this missing—there’s no WinForms in the 3D world. So that’s, you know, perhaps where TinyFFR maybe is aiming at.

Jamie : I like that. Yeah, it’s—you know what it’s like? It’s like there are Ferraris and there is a kit to build a car, right? It’s almost like a non-tech, I’m hoping for a non-tech metaphor of basically what you said, right? You can have a Ferrari, which is your game engine, or you can have an SUV, which is your game engine, with a million things that it does, and it will do what you want it to do, but maybe it’s not tailored specifically to exactly what you want to do.

All those—the compiler and all of the language that you have to learn and all of the raw APIs. Like you said, yeah, there’s a space in the middle for: I just want to draw something on screen that looks really cool, and then I can start applying different lighting effects to it or figuring out what a camera is.

Because I can imagine that something like TinyFFR would be really good in an education setting, right? Because you’re not having to leap directly towards a game engine and go, ‘Right, cool. Here’s a camera that you don’t need to know about yet. Here is a projection map, which you don’t need to know about yet. Here is a rotation matrix you don’t need to know about yet. Here’s a shader that you don’t need to know about. Here’s a million things that you don’t need to know about yet. We’re going to change this one tiny thing and then draw a person on screen.’

Whereas if you dial it back far enough that you get to TinyFFR or something similar, you can be like, ‘Cool, here’s 20 lines of code that sets everything up, and here’s a model. Guess what? It’s on screen,’ right? Now I can talk to you about how a camera works and now I can talk to you about what a scene is. You know, by stripping things back—like we said about your example with your journey recently with being a musician, right? Stripping things back actually opens things back out for more creativity sometimes than actually ‘Here’s a million billion squillion buttons that all do something different.’ Well, actually, like you said, I’m going to be distracted by the choice.

Ben : Yeah, I mean, absolutely. I—you know, I try not to talk for everyone because everyone’s different and there are probably very well people listening to this thinking, ‘Well, I, you know, I don’t get distracted, you know. I just open up my project in Unreal or whatever and I just get on with it.’ That’s absolutely fine, of course.

But you know, for me definitely, I get overwhelmed by all of that configuration. I also find that large game engines, because they are catering to all—they tend to have multiple ways of doing the same thing and I find it very frustrating to try and work out, you know, I get stuck a bit, you know, trying to work out well what’s the right way. You know, they’ll often have documentation that’s a few years old and you start going down that road and you realise, ‘Oh, actually, we—you know, they’ve completely changed their scene graph since then and you should be using this new method,’ right? So that’s like DOTS in Unity.

Ben : Which is still a work in progress. But yeah, there’s a lot of stuff like that, which for me personally I find stifling. I don’t think that’s universal. But yeah, and also, you know, you’re right about the educational aspect. I fostered my interest in game dev when I was a young teenager playing around with XNA—very similar to TinyFFR actually. It stripped away a lot of the complexity and just let you—I mean, it was a 2D framework pretty much only at that point, but I didn’t care. I was having fun making little games with spaceships and stuff, you know, and that’s probably what made me go into computer science when I grew up a few years later. So yeah, I think there’s definitely a need for something like that.

Jamie : Oh definitely. From the sounds of things, I’ll say a little bit older than you. So like I grew up playing Nintendo Entertainment System, the original NES. With that, part of the game was your imagination, right? Because the hardware was so constrained, but because of that, I genuinely—I was thinking about this today actually—I genuinely feel like I connect more with those older games because I had to put more effort into the experience, not just—I mean the older games were more difficult to play, but also there was the, you know, it’s not as well rendered on screen. I think, you know, the experience isn’t as whizz-bang and Hollywood as it is now, right?

So I was playing Clair Obscur: Expedition 33 or whatever earlier today. That is like—it is gorgeous. If I could have shown my six-year-old self that and said, ‘Guess what you’ll be doing in 30-odd years?’ it’d have blown his tiny little mind, right? Right. But also that six-year-old is also looking at Super Mario Bros. 3 and seeing almost the same—they’re interpreting it as almost the same graphical quality, right? Because your brain’s doing part of the work too.

Ben : Well, so I was—exactly. I was actually going to say that I don’t know about you, but sometimes I’ll have this thing where I’ll see a game that I played when I was a child and haven’t seen it in 20 years. So this might be like—for me recently this was Final Fantasy VIII, I think.

Jamie : Oh nice.

Ben : Played it when I was a kid. In my head the graphics were amazing. I looked at screenshots of it again like a couple of months ago and I was like, ‘No way.’ I was like, ‘This is going to be a low-res screenshot someone’s captured or something,’ right? So it—yeah, definitely I think your brain fills in those gaps for sure. Like, yeah, you remember it as much better than it was.

Jamie : Yeah, and that fits really well with—that’s why when people come to me and say, ‘I want to get into game dev and I want to make a game,’ and they’re like, ‘But I’m going to build an engine first. So how do I build the engine?’ I’m like, ‘No, no, no, no, no. Go get RPG Maker or go get, you know, something that is equally’—I hate to use the phrase, but it’s reductive, that is not productive, that is very specifically designed to achieve one very specific thing, right? See if you can get on with that and then build something with that.

No one starts out their life of being really into cars by buying spanners or wrenches, right? Nobody starts there. They start with, ‘I’m going to buy the car and then I’m going to look into what I like about it, what I can improve on it, what I can modify with it.’ You don’t start by buying the ratchet set that you will eventually use to modify your car, right?

That’s where people I think fall over when they start with, ‘I’ll start with an engine, build my own and build up.’ Whereas actually what you want to do is start with something like an XNA, like you did. Build up from there. Because then all of the fundamentals are taken care of. You get to do the fun bit, which is make a game, right? That bit is fun.

Building an engine, and I’m sure there are people out there who absolutely love building video game engines. But building video game engines is like enterprise software development, right. There’s loads of boring bits and there’s loads of bits that are really tough and loads of bits that just—it gets you down and you can’t figure it out and then suddenly you figure it out. But in games dev, you’re moving pixels around on screen immediately, right? You can actually feel the sense of enjoyment while you’re doing it. Then you throw it to someone to play and they’re like, ‘Oh my goodness, you made this, this is awesome,’ right?

Ben : Yeah, I mean, completely agree. Also, I just want to add that your description of enterprise dev there, that soothed my impostor syndrome. I’m glad to hear you say that there are days when you’re just like, ‘I can’t get this to work.’

Jamie : Yeah, my—just real quick, my thoughts on—I fully agree with you a hundred percent. There are days where I’ll be sat there not being able to do anything just because it just does not make sense and it’s supposed to work and it doesn’t. I’m contemplating throwing my laptop into the river, you know, that sort of thing, right? Then it just suddenly works, right?

What I always tell myself at that point is that when the impostor syndrome starts to come out, I always tell myself, you’re only feeling it because you care. You don’t—what was it? I once read an article about this chap who said these words exactly. He says, ‘You only get impostor syndrome about things that you care about. If you are making a microwave pizza at 2 o’clock in the morning because you’re hungry, you don’t get impostor syndrome. But whatever you do for work matters to you. Or whatever you do with, like if you have children in your life, in your family, or whatever, right? You’re looking after them, maybe you feel a sense of impostor syndrome, but that’s because you care about what you’re doing, right? You don’t feel impostor syndrome about stuff you don’t care about.’

Ever since I read that, I was like, ‘Wow, that has completely changed my attitude on that whole thing, that whole oeuvre of modern pop psychology.’

Ben : I’m going to have to show my partner—she suffers sometimes too with impostor syndrome. So I’m going to have to show her this podcast when it comes out, just for this bit.

Jamie : So without going into the details of the documentation, we talked a little bit about how I absolutely love it and why you decided to write the documentation in that way. My worry is this is an audio podcast and I’m just about to ask you, how do I actually get started with TinyFFR? Because talking to someone about how to build a 3D scene in a programming language on an audio podcast isn’t really going to work. But it is just a case of, ‘Hey, here’s a NuGet package. Here’s ten lines of code to get you started. Guess what? You’ve got a 3D scene,’ right?

Ben : Yeah. Yeah. So I mean, if anyone’s listening and they want to kill an hour in an evening and just give it a go. I mean, you can go to tinyfr.dev, which is the documentation site, or if you just go on GitHub and search for TinyFFR, you’ll find that it’s open source.

Yeah, both the README on the source and the documentation site—if you don’t even want to read the Hello Cube tutorial, if you scroll to the bottom of the page there’s literally a condensed example of the whole thing and you can just copy and paste it into your IDE or your editor. You just need one NuGet dependency and you can copy-paste those 20 lines, hit run, and all being well, you should see a cube that you can spin around by holding the spacebar, I think. So yeah, I mean, go for it. If it doesn’t work, please raise a bug and call me an idiot, but let me know and I’ll try and fix it.

Jamie : Don’t call Ben an idiot. I appreciate that’s what he said, but don’t call him an idiot. That’s not nice. But also cross-platform, right? Because .NET’s cross-platform.

Ben : Yeah, cross-platform is hard. It was hard. Actually, so I’m going to mini-rant here, but—can I say screw Apple? I mean, you know, it’s obnoxious to me that I can’t develop for their platform without buying into it. So for maybe for any listeners that don’t know, you can’t run an Apple VM, they don’t let you. So the only way to develop for macOS is to either buy some Apple hardware or what I do is rent a Mac on the cloud. You can actually rent one and remote desktop in. So yeah, but you know, it—that’s probably the most obnoxious part of cross-platform and the ultimate result is in feature lag, you know.

If you’re angry about that—there’s no v-sync support, for example, in TinyFFR on macOS at the moment. It’ll come one day, but if you’re mad that it’s not there now, point your fingers at Apple because I don’t want to spend another 90 quid to rent a Mac for a month until someone really, really needs it. So that’s the way it is, I’m afraid.

But yeah, the Linux support was probably the more technically challenging, but only because—and I’m not the first developer to ever say this, but Linux is more fragmented, so when we talk about Linux support, that’s not really a thing. You’re actually asking which distros am I supporting, which desktop environments am I supporting? You know, the compositor, Wayland versus Xorg or things like that. So it’s more like supporting three or four different additional environments to some extent.

Jamie : Yeah, I have to say if you’ve only ever written software for Windows or for macOS, I don’t want to sound pretentious, but you’ve got it easy, right?

Ben : Yes.

Jamie : You know, a lot of people say, ‘Oh, Linux,’ but what they mean is, like you said, a distribution of Linux, right? So that’s just built up from the bottom, right? Somebody—and you know this as well, Ben, but just for the listeners who maybe are Linux-adjacent, right? Or Linux-agnostic. Linux itself isn’t an operating system. Linux is the kernel of the operating system. It’s the bit that does all the time-slicing and the memory allocation and stuff like that and talks to your devices through drivers, right?

Then on top of that, you have a whole distribution of software, which is why it’s called a distribution of Linux, right? You might have Debian, which has a whole bunch of software built on top of the Linux kernel to give you a desktop that you can interact with. The problem with that is that every single person who could possibly ever come up with a desktop idea, an idea of a desktop, has created it, right?

There are desktop environments that map onto Windows, desktop environments that map onto macOS, desktop environments. One of my favourites was from Compiz, which was a cube. So on macOS with the trackpad, you can move three fingers up and you’ll get what used to be called Mission Control. I don’t know if it’s called that, where everything zooms out and you can see your whole desktop all at once with all of the different apps. Well, you could do something similar to that, but what would happen on Compiz is your screen would zoom out and you’d see the side of a cube and you could rotate the cube and that’s where your other desktops were.

Which was really cool, but really hardware-intensive. The problem is that because each one of these acts differently, they all have their own set of libraries that they use. Some of them use the same libraries but different versions, and those different versions are only available for certain types of machines, right?

When you say ‘support Linux,’ what you really mean is ‘support absolutely everything that’s ever been built ever,’ including the one person who lives in their house and never leaves their house and has built their own distro that is specific to them with their specific choices. Because they’re going to find your library and they’re going to say ‘doesn’t work on my machine and therefore it sucks.’ That’s not very nice. So ‘supports Linux’ is a whole world of things.

Ben : Yeah, I—and as much as I’d love to support your theoretical person there who I’m sure is on Arch, by the way. But yes, I think you have to—for me it’s about drawing probably sensible defaults. So at the moment I’m supporting Debian and Debian-based distros. I would like to support Arch, and that is in the future, especially as perhaps one of the most important distros that I will need to support is SteamOS, which I believe is Arch-derived. Need to double-check that, but yeah, so I do need to support Arch actually.

But yeah, I’m also moving on to Wayland and I currently support X11. I probably will backseat X11 for the foreseeable future, just because it seems like things are slowly finally moving onto Wayland across most of the distros, but yeah, it’s not an ideological decision for me, just a practical one.

Jamie : For those previously mentioned Windows and macOS devs, they’ve got no idea what X11 and Wayland is and that’s fine. That is totally fine. We don’t have to get into that just because it’s so complex.

You know that moment when a technical concept finally clicks? That's what we're all about here at The Modern .NET Show.

We can stay independent thanks to listeners like you. If you've learned something valuable from the show, please consider joining our Patreon or BuyMeACoffee. You'll find links in the show notes.

We're a listener supported and (at times) ad supported production. So every bit of support that you can give makes a difference.

Thank you.

Jamie : Like, I’m currently talking to you via my Mac, right? On here I have Finder, which is my desktop, essentially. It’s not exactly that, but it’s like the Windows Explorer, right? On macOS and Windows, you don’t have to worry about any of that, right? It’s all one big monolithic lump of code that runs on your computer. Because Linux distributions are so modular, that’s why they’re so fragmented. You can literally swap out a component for anything, right? There’s nothing wrong with that, except for when it comes to ‘how am I going to support this?’

Ben : Yeah, in fact you’re right, there’s nothing wrong with it. It’s even its biggest strength and it is why I—I’m not sure if we mentioned this already earlier in the podcast, but having been a Windows user for, I don’t know, 20 years probably at this point, I have just over Christmas this last Christmas switched over to Kubuntu, so that’s Ubuntu with KDE as the desktop environment.

So far I’ve no desire to go back. But yeah, one of the biggest strengths is I get to choose. So for me, KDE—I should mention, so for again for the Windows and Mac users here, so obviously I think probably most of them will know of Ubuntu, but Ubuntu ships by default with a desktop environment called GNOME or Unity, depending on how far back you go.

It’s very bare-bones to me. It’s actually a little bit Mac-like, which maybe, you know, probably why it’s the default, because that’s probably the preference for a lot of users, but I prefer a little bit more configuration and power, so I’ve configured a Kubuntu distro with KDE. So even if someone who was previously 20 years a Windows user and has just switched onto Linux, I’m already off the default path. So yeah, which is great. But yeah, it just shows that how fragmented things have become very quickly. Yeah.

Jamie : Yeah. So I applaud you for wanting to—so for again for the Windows and macOS users, and there’s nothing wrong with this, but for the Windows and macOS users, installing Arch Linux used to be a bit of a brag. Like if you could get that to install, because the way it used to work is you run the installer and it drops you out to the terminal. You literally have to compile and build everything yourself for your machine.

The idea was, if you built and sourced all of the pieces of software for your machine, it would, A, be tailored to you, but also it would be optimised for your hardware, right? Which is fantastic. But also, you know, you need to be Zen Monk level of computer science to be able to do that.

Ben : Yeah, Zen Monk or having a lot of spare time, you know.

Jamie : Yes. Or both, probably, yeah.

Ben : But that did mean that for the longest time, the Arch Wiki was the best place to learn about how all of the different pieces of software that sit on top of the Linux kernel worked because they had to document everything. I think it still is this way. I mean, please correct me if I’m wrong, folks, by writing in or Ben if you know, but the Arch Wiki used to be the best place for any information. It would even go down to individual components sometimes on sound cards because that made a difference, right? ‘Oh, you’ve got a 32-ohm resistor there. That means it’s not going to work on Linux.’ I’m sorry, what?

Ben : Yeah, yeah, that’s—as far as I know it’s still a pretty good—I mean, a self-confessed Linux debutant, I’m probably not qualified, but yeah, as far as I know Arch Linux and the Arch Wiki is still a great source of information. Yeah.

Jamie : Yeah, so being able to support a distribution of Linux where literally everything is tailored custom to the individual, there’s a very tall order and I applaud you for having that goal.

Ben : Well, we’ll see. Maybe a year from now I’ll tone my hair out.

Jamie : Well, I mean, I do have a device that runs SteamOS. So maybe I should give it a try and see what happens, right?

Ben : Yeah, yeah. I tell you what, I’ll send you a message when I’ve got the Arch Linux support going and maybe you can tell me all the different ways in which it breaks and we’ll go from there.

Jamie : Every single way. Amazing. Cool. Well, Ben, this has been a wonderful conversation, I have to say. I genuinely feel like even if you’re not into computer graphics, folks, if you’re into .NET, go get TinyFFR and just run through the Hello Cube tutorial and then start playing around with ‘what can I do with this wonderful 3D scene on my computer?’ and then like—okay, so maybe I’m betraying my age here, right? Back when I started working with .NET, it was the early .NET Framework days.

Everybody was saying it will never catch on, but also it will never be fast enough to do anything useful, right? I love to turn to people and go, ‘Look at what you can do,’ right? We’ve got TinyFFR on one side, we’ve got Blazor on the other. We’ve got Unity and Unreal, which both have .NET-y things built into them. You’ve got Godot, which also has .NET-y things built into them, right? Look at where we are, folks. This is amazing.

Ben : Go try it. Yeah, absolutely, absolutely. On that note, so when I first built that game I was talking about earlier, that’s 10 years ago on Steam. That was also .NET Framework and back then you had to do so much work to work around the garbage collector and work around the various non-optimising aspects of the compiler. But these days writing TinyFFR, I find more often than not, I just write things the simplest way because if I try to do anything smarter, I’m actually working against the most optimised path. So that is testament to how far .NET and C# has come in terms of performance.

Jamie : Yeah, a hundred percent. Yeah, just go check it out, folks. If you do .NET in the enterprise, think about what you’re able to do, right? You’re building an enterprise on top of—I won’t say the engine of a Ferrari, but of a very powerful car, right? A very, very powerful vehicle that can go—that has the ability to go fast if you let it. But we’ll just poodle along at a leisurely pace because most people just use it for enterprise stuff. That’s why I love .NET. I’m so enamoured by just—this thing that is super easy to get started with, but that can stretch from your standard ‘in quotes’ boring enterprisey things all the way to things like TinyFFR, right?

Ben : It does everything. Couldn’t agree more. Yeah. I’m also a big .NET fanboy for exactly that reason.

Jamie : It’s so versatile. Well, I’ve had an absolute blast chatting with you, Ben, and I hope that more people check out TinyFFR. You said earlier on there is a website. I’ll get the URL from you and put it into the show notes anyway. I say that to everybody. But are there any other resources you recommend or places you recommend people check out? Either about TinyFFR or about specific things that you love about .NET or in games dev or anything like that. How can folks connect with you best? I guess Bluesky is one of the ways.

Ben : Yeah, yeah. I mean, the only other information that I put out there is my blog. I haven’t updated it in a little hot minute now, but benbowen.blog. That’s my more software-y blog, not so much to do with TinyFFR. You can go and check that out. I’ve got a pretty nice write-up on how the scoped and ref field stuff works in C# 11, which is quite tricky, so if you’re into the more advanced side of things, maybe that could be worth a look.

Then yeah, if you want to talk to me, I am probably easiest to reach these days on Bluesky. I’m trying to stay off some of the other social media sites. So yeah, Bluesky and at—I think at XenoPrimate is my current name. I’m sure Jamie, you could put it in the link there somewhere.

Jamie : Awesome. Well, yeah, I’ll get the link for TinyFFR in the show notes as well, folks. Definitely go through the Hello Cube and then stick around for lots more, right? Because there’s a whole bunch of stuff there that you can do. I genuinely, I absolutely love—I’m not saying this just because you’re on the show. I had the conversation with you offline as well. I genuinely love this library because it’s rekindled the joy that I had back at uni in the second year when we started playing with OpenGL and I was like, ‘This is cool, I can make a cube.’ I sent something on to one of my family members and they were like, ‘And?’ Like, you don’t understand. You don’t understand. I made this.

Ben : They’re like, ‘And?’ Yeah, no, I mean, you know, maybe you need to be a software engineer to get it, but no, I’m really pleased, really, really pleased to hear you say it and that’s exactly the effect I’m going for and it’s been a real pleasure, Jamie. So thank you. Thank you so much for having me on.

Jamie : No worries, it was an absolute pleasure to have you.

Ben : Thank you very much, man.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest for graciously sharing their time, expertise, and knowledge.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice—head over to dotnetcore.show/review for ways to do that—reach out via our contact page, or join our discord server at dotnetcore.show/discord—all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places