Wonderful. As the slide says, this is about games. This is about the games, or the real games should be written about games libraries, games middleware, and with respect to open source, obviously, because this is FOSDEM. Because most commercial games will not or won't, for some reason, use open source.

There are several reasons for this. One of them is that the libraries aren't written the way that games programmers use libraries. It's slightly different when you're doing a game to, you know, a web server or a word processing app. So what we're going to do is we're going to look at why the badness happens, how it happens, how we can correct that,

and obviously, since I wrote this thing, we're going to be promoting SGX for whatever reason. But first, the obligatory ego slide that tells you all about me and why you should listen to anything I have to say. Yeah, I did a book a few years ago on cross-platform programming, so how do you write a game on PlayStation and make it work on the Xbox?

Not quite as easy as it sounds. I then wrote another book on open source and game development, about the libraries, about the way they're used. I then did a show on the internet, a little podcast about beer, where I review beer. Guess which one of the three people genuinely want to talk about?

Today I'm going to talk about games. So, the first thing we're going to do, if we're going to do a library, we're going to have some common ground. You've got to start from somewhere. So, obviously, this slide says, where is it? Well, obviously, integers. They're completely common everywhere, except on the PlayStation 2 where they change, Xbox is a little bit different, so we can't rely on integers being the same.

We've got no common ground there. The standard library, as it says, is standard, but there are so many standards to choose from. They aren't the same. In the C library, which is what all professional games programmers use, there's a little function called Qsort. You're probably aware of this from the C standard library.

Qsort does not do a quicksort, even though it suggests it. All it does is a sort, which means if you've got two keys which are the same, which is legitimate and loud, they could be swapped if your library happens to do a non-Qsort. This will cause you bugs, and you won't know about it, because it's a different standard. Sorry, can't use it.

And the GNU compiler isn't actually available everywhere. It's not available in the Wii. Amongst other things. So, I was wondering, what do I put here? Are we going to start? We need some common ground. What's that base level? Language is the invention that makes all others possible. I thought that was quite a good quote myself.

I should have put it there. So, we're geeks. We deal with languages every day. Scripting languages, programming languages, functional way, everything. What does that mean? Is that object? Is that object? What is an object? Is it a variable? Is it a container for data?

A container for instructions. Data and instructions. Data but not instructions. A procedure, a function, a specification, an instance. We're not really good at this common ground language thing in reality. And when it comes to engine, what's an engine? Most people say, oh, I've written an engine. No, you've written a graphics library that wrappers OpenGL. There's a difference.

We need to have some kind of common ground that we can all understand. And the two we've got left, we can't even move on. The next thing, we all rely on everything else. Open source is very good at this. We rely on other components. That's not so good in games. All of a sudden, your standard little renderer needs 27 other things to build. Half of which aren't available on the Xbox or the PS3.

See, no games program is ever going to touch it. So, what sort of components? Well, this is a fairly easy example. A GUI library. You've got a mouse. You move the pointer on screen and you click on a button. That's fairly easy. But you go and get your mouse position and, no, you can't, because it's not cross-platform.

Mouse on X is quite different to mouse on Windows, which is different to the way the Wii pointer works. So let's abstract it. Well, you can, and you can create this nice little get cursor position, but it doesn't work. Who says you're using the left mouse button the whole time? Are you using a joypad? Are you using a joystick and a button?

Which button? If you've got three players all joining a multiplayer game, and any of them can join in, you can't even say, is button pressed? It's not going to work. And games have to handle this. There are so much pieces of source code out there that if your thing doesn't slot in and work, no one's going to use it. There's enough source there, you say, well, that doesn't work, I'll try this one.

Does this work? I'll try this one. And when you find out they don't work, you write it yourself. It's going to be quicker. So we've got to solve these problems. I have this problem as well. Everyone has this problem of display and processing. Web developers, bless their cotton socks, are the worst at this. They'll write a little chunk of PHP processing. They'll output some stuff.

They'll write some stuff. They'll process output. You can't mix them. Games, we have a few benefits. Because let's face it, all graphics are visual. So we can mix in the processing and the output, the display, the nice funky stuff. Because graphics are always visual. In every single game, we're always working with graphics. Oh, no we're not. As soon as you suddenly realise your game engine is meant to be running on a server,

there's a little game called World of Warcraft that some of you may have heard of. Some of you are probably World of Warcraft spouses as well, have been lost to the game. Sometimes graphics engines do not run on graphics hardware. If you've got a character mesh that walks through a door,

and your graphics engine is saying, can I walk through that door? All of a sudden, you run it on a piece of hardware that doesn't have the graphics. Your game doesn't work. So you can't just what you would normally do and run on the graphics engine to do stuff for you. I said in the notes to the slide, by the way, that I would talk about the human aspects. And this is it.

Humans are awful. If you could write software about humans, it would be much easier. Because basically, they're not going to change their code. If it doesn't work, they're going, well, if I change it and I make your stuff work, if it breaks for someone else, I'm responsible. That's understandable. I don't want to be responsible for breaking people's code. But humans are problems as well as the code. So we're going to solve this problem as well.

I feel like we should actually give up at this point. Fear not. There are three steps to the problems that happen with games and games libraries. There's the human-human thing. How do we arrange for humans to do work and not make everything break? There's the human-computer thing. How do we have common terminology?

How do we make sure that we convey our ideas correctly? And we have computer-computer things. Making sure APIs are okay, program by contract, things like that. So, where we'll start. Where we'll start at the beginning. The engine means everything. It doesn't mean a graphics renderer, where the maths library is hidden in the middle somewhere. It means everything.

Components. These are completely independent things. If the audio component relies on the collision system, or the graphics relies on the collision system to get a mesh moving through a door, it's wrong. You don't need that amount of interplay. You then need the drivers.

These are common. You can have a collision system which works on every platform. You don't need a graphics driver to tell you that. And you can then write your drivers that just say, okay, now push some polygons. Now make some sound. This can work on any platform, and you just write, probably a thousand lines of code, if that,

to make it work on any of these other platforms. Something obviously which I can't release is the Wii code and the DS code, which also does it in less than a thousand lines. Same engine, just separate driver code. Separate the driver code with the main abstractions. Base everything around a core. Obviously, since SGX is something that I'm involved in,

the SGX core is the way to go. This is the language quote from earlier. Language makes all other inventions possible. The core makes everything else possible. If we say, let's have a common set of types, and this is one of the really important ones, unfortunately. Right at the bottom. Everyone says, oh, I will pass an integer to this function, and it will do stuff.

What sort of integer? Two byte? Four byte? Side? Unsigned? Create a common set of types, and if everything uses these set of types, we all know what we're doing. No one can be saying, oh, no, I thought you were going to be unsigned. Oh, no, I thought I had 32 bits here to play with. Common set around everything. Abstract things.

If you're doing cross-platform work, the key word is abstraction. Just hide everything else away from the lower. The entire standard library, Qsort, everything else, hidden away by a little lower. Functions happen to begin with SGX, because that's the engine. But just hide them away a little bit, so if there is a problem and Qsort doesn't sort that way, at least it will on all the other platforms,

because you've abstracted it. I learned how to do green about halfway through doing these slides. It's good for me. I didn't do this gooey stuff. Uncouple your code. When we talk about, oh, a mesh could move through a door, yes, that is a physics type of problem,

and it is a bit of a graphics problem, but actually, in reality, it's geometry. Separate away. Have a common set of geometry code that processes polygons, processes meshes, processes a square versus a line. All this sort of stuff doesn't rely on graphics. It doesn't rely on anything.

It can be used by graphics. It can also be used by the sound code. If you're trying to work out, can I hear this noise, and can the AI run after you, you can use exactly the same geometry code, but it's not in the graphics engine. It's in a domain which is separate and relies on nothing other than a core set of types. Create a skeleton library, which is just the sheer basic bones

that says, this is how you access information. And templates are always good, so you can basically take something and compile it, and it just works. One of my pet gripes in a lot of things is source code on lyrics. If it's not on the disk, it has an issue sometimes. Single terms are a wonderful thing. I know a lot of people hate them, but in engines, it's really quite cool.

You start by creating an engine. This creates a global pointer inside its memory, so your initialization routine calls this, and that's platform-specific. It generates the platform-specific pointer, but then everything else in the entire engine uses this generic.

Very, very simple. And this stuff, it may go through to platform-specific, but it can also go through to the basic driver, which means you can share the code for four or five different drivers without changing anything. Something a lot of people think, oh, but it's just a global, so why don't we just call it graphics-apply-texture?

Well, that means as soon as you go to another platform, you need to copy graphics-apply-texture to every single platform. Or if you change the interface, or you add functionality, you've got to go back and add it to everything. Whereas if you're doing a class hierarchy, and this is all C++, obviously, you can tell from the syntax, if you do the class hierarchy thing, then you can write stuff that's common,

and all the drivers can use it. Create nice interfaces, obviously. Giving to the rich, taking from the poor. Go back to the GUI example. We can't just go in and take a mouse pointer. We can't just say, oh, give me the joystick position, but I'll work out which of the three joysticks want to say OK at this point.

Take it from somewhere. Your game is the only thing in the world that knows if two joysticks can hit OK on this screen. Your game is the only thing that understands how it should work. So get the game to say, OK, give me the joystick position, give me the buttons. And then send that message back down to the GUI system.

Because that way you can have a nice layer up here, and it can talk this way. Somebody will go, oh, that's a lot of processing. No. When you realize you're pushing thousands of polygons out of the screen, you're pushing megabytes and megabytes of data through your pipelines, it's an extra two bytes to take an XY position from this library and give it over here, actually a process.

It's not a block. And it means that the libraries will fit in with everything else. And that's the key point. Libraries want to play together. When it's open source, you can just take and you can recompile and you can build and you can shuffle around. Very easy. When you're in a game, people generally aren't going to be doing that. They'll take, they'll run it through, and if it doesn't work, they'll move on and rewrite it.

So, punctuation's wrong. Nope. Yeah, that's the way. So, if we have about a minute and a half left, I can do questions on games or VR since I know which one most people want to talk about. Yeah, including Frank. Unless I've actually covered everything

and we're about to run out of time. No, we've got about a minute. I talk quick. Yes. The NDA's actually forbidden me from mentioning them at the moment. There's one which is meant to be out on iPhone in the middle of March.

But because it hasn't been announced, I'm not allowed to say what that one is. There's a TV, a children's TV show. There's a Wii game coming out, which will be in the Argos catalogue for August, I think. Again, which you can't quote me on because it hasn't been announced formally. It's in that as well. I thought there's another couple of educational games that it's being used in.

Plus, portions of the engine have been used in previous games. I've been writing games for about 14, 15 years now, including this guy called Die Hard Vendetta based on Bruce Willis' character who goes around in a vest. We did a game on that. There's portions of this code from there because it's the engine. I thought I could write it in work

or I could just copy the code I've written. And I don't like rewriting things. So, several of them. Complete next year. I can tell you all about it next year. They're actually all cross-platform.

The Die Hard game was out on GameCube, was on PS2 and on Xbox, and there was also a PC platform that we used internally for development. This is much cheaper to have a PC running the game than it is to buy an Xbox dev kit or a PS2 dev kit. So they're all cross-platform. One of my tenants is development.

15 minutes is an awful long time. You don't realise it until you get up here. If there's anything else, I'm going to... Oh, sorry.

Perfect timing. Thank you to us.