Huh? Oh, he'll come back. He'll come back. Okay, thank you so much. So, hello everyone. I would like to present you a game framework for the beatbox. So this presentation will be a little nerdy, maybe, and it has been fun to do.

I don't know if it will be fun to use or to watch, but anyway, it's the occasion to present it. So first was the beatbox. The beatbox is a small console that has been made for fun, of course. Well, I will pass it to you.

It's a tiny console, do-it-yourself, open source, open hardware. And the idea was to have a side project for fun, to build a console, because I like electronics, so what could I do? Well, game console, of course. And the aim is to do it yourself, so that other people could read you it themselves.

So availability of the components, so you don't have to buy hundreds of thousands of the same chip to actually have the chance to have one. So it's a very simple way to do that. You can do that in your basement, which I did, with no particular skills or hardware.

So it's a kind of retro game console project, because do-it-yourself generally means limited power, and it matches very well with the retro game concepts, and it's fun to build some games. And in a way, it's really retro coding also, because I'll show you it's very low level.

So the characteristics of... You can't see. You can't see? Okay. It's single board computer, or console. There is one chip on it only, that was one of the simplicity of the design decisions. The output is on VGA. There is a 15-bit output VGA. You've got two USB, one microSD input,

so that you can load the games. The CPU itself is a microcontroller, so you're getting it 168 MHz. One mega flash, so one game should make one maximum. And 192K of RAM, which means that at a typical resolution, 640x480,

you don't have enough room to store a single screen on RAM. So you have to generate it, and you have to raise the BIM, meaning that at the beginning, you have to generate line by line very quickly, and at the end of the screen, you get a top, so you move your game and your advances twice,

and go back and generate on the fly. By example, if you want to output a movie, you cannot remember what was the preceding frame to compress, for example, because you don't have enough memory. But that makes it fun. It's basically the limitations that make it fun, because Raspberry Pi 3 has, I don't know how many times the power of this.

It's very tiny. And since it was too powerful, I did also a bitbox micro, which is basically half the bitbox in every possible element, so the size is roughly half.

The number of USB ports is half. The number of microSD is half, meaning there is none. The CPU speed, the memory, the resolution, everything is in half. So that's basically it. The development...

If you want to have a look. The development on this is basically a retro-coding. You direct on the bare metal. You don't have the room to have an operating system. No driver, no leaps. You have your game, and you run directly on the console, and you have to code everything by hand,

which is fun for some kind of people. CD development is easy. Generally, those are modern interfaces in a retro console. Compared to a retro console, you have USB, you have etc. And the toolchain is a standard GCC. You download that on Ubuntu, by example, or Debian.

After you get GCC embedded, you can develop for it. So it's quite simple to develop. There are people who have developed with this on Ubuntu, Windows, MacOS, and Haiku, of course. Thanks to some people here.

So there is a PC backend. It's not really an emulator. It's basically a re-implementation of the basic API, your kernel API. It's basically a kind of a leap to initialize everything to simplify the development. And there is a re-implementation of this higher-level API with SDL. So basically, you make all of your game high-level stuff,

and you code it on the PC, and then you port it on the bitbox. There are some people who developed completely a game developed with the API and with the emulator. Let's call it like this. And they send it to me, and just with a re-implementation,

it runs on the bitbox, which was nice for me. There is some generation. One generation is basically you write a byte on memory, and it outputs to the speaker. That's the kind of level of hardware you have, so basically none. But there are existing libraries, very nice libraries,

for chiptunes, also made by somebody. Thanks, Adrian. With a tracker to compose your songs and to help you having chiptunes. Let's enter. USB handling is particularly nice and simple to write yourself in C, so there are libraries because it's really painful, in fact.

Handling a USB gamepad, et cetera, because it's difficult to make a gamepad that is pleasing to do, so I didn't want to do that myself. So I'm reusing USB's download gamepad that you can find for very cheap. And the graphics generation, they are kind of library also,

valuable to avoid you for doing routine stuff. But you can do it yourself, and the basic thing about this console is not invented here. The thing is to redo everything yourself, so it's perfectly understandable to drop everything,

every library, et cetera, and recreate on your own. That's what's interesting for certain people. Games and community, there are a few bitboxes around the world, a few dozen. There are small active core developers for making games or libraries. There are custom extensions, hardware extensions,

and VLO are kind of video output. You can output on a TV, not using SCART and Perital. There is some output to this that has been in after the fact, that has been hacked from the console itself.

There is an external port, a gig port, so you can plug whatever you want and have external funny controllers or physical buttons or what you want. And you have to do the driver yourself, of course, et cetera, et cetera, et cetera.

There is software index with, so far, I think, 26 entries for different software. So you can see there is a full motion video game, so decoding live from the SD card, directly outputs and decompress to live. There is a port of Buddha Dash. There is, I don't know, you can recognize some old games over there.

Jumper games, Polarity, Rapid Ball, which is kind of a mobile game, Snake, of course, Tetris, some alter-ego, it's a port of Super NES. And there are emulators, also, and 8-bit emulators.

It's a 32-bit console, playing 16-bit games and emulating 8-bit systems. So the systems are those Game Boy emulator, ZX PICTRA emulator, and, of course, Elmo 5, which is a Tom Sonvery, it's a French computer, nobody knows, but I had it in school,

so I didn't honestly write the emulator. It's just a port of existing emulators, and axing to the code to remove mostly everything that is not, so that it could fit on the memory. There is a graphical drum loop sequencer.

There is a tracker, for which there is no... And some, sorry? There is a switch on the link, I think. And the link. If I can follow the link, yup.

I should have gone, I should have gone. No, there isn't, if it were. It should be, okay, so it's a tracker to compose your sound directly on the beatbox. It's for some work in progress, a bitcaster, Bomberman clone, which is not finished, and many, many, many prototypes of games which I didn't finish, of course.

Let's get back to this. So making games, how do you make games for the beatbox? Well, let's make a little survey quickly. Who knows game development in C? Quite a lot of people. So, making simple games,

generating light-based graphics, sprite size with collision, so making a small 2D, making pixel graphics with game 2D level design, with tile, by example, and cross-compiling everything for another M-Cortex M4. And compose music with a tracker for this.

It seems a little complicated, it is not, every single task is quite not complicated, but if you don't know several of them, it can be a little intimidating. So the idea was to lower the perceived barrier to entry to build, program, and design some simple games for the beatbox. So let's make a new survey. Who can draw a BMP5 with GIMP?

So the idea was to simplify the process and having a complete simple game on a unique image. So you put it on the RSD card, you put the RSD card on the console, and there is an interpreter who loads the image in RAM and runs from this. And you then play the game. It's a Mario Maker for the beatbox, except you can redraw it yourself.

Restricted to certain kind of 2D games, but there can be several kind of gameplays. Of course, it's very limited, and that's the idea, of course, to limit it. The general workflow there, the reference MD, you saw a kind of documentation, you can read it, you saw your BMP5 on the SD card,

and the reference generates some definitions, the program reads them, and plays it on the PC emulator. So what do you need to do a full level 2D platformer, and how do you put that in an image? So basically, to make a 2D game,

platformer, side shooter, infinity runner. You need to have world physics, how do you scroll, how do you jump, is there any gravity or not. You need to have tileset graphics, so little pictures that will repeat to make your level. You have to have your level tile maps, how do you order the different levels.

The sprite frames graphic, of course, different frames, different behaviors and movements. There are different ways to do that. You can have a full programming language, it exists, there is Mondrian, by example, it's a graphical programming language, but it doesn't really fit well on the limited image.

So you can also use presets, so you just have one sprite, is always such kind of enemy. The idea was to mix a little bit, those to be versatile enough, and to fit in one. And you need to have music and sound effects. So how do you encode it? First you start with a blank canvas. The canvas is 256 colors,

so you can index it by number from 0 to 0xFF. And this number will be repeated quite a bit of time, so hence the name. 256 color pixels by pixels on the bitmap. It's divided in 16x16 squares, or 16x16 pixels,

which means that with your color, tiles, and pixel per tiles, you see that there is a mapping between the number of the tiles, if you number the tiles themselves on your drawing. One pixel in a tile, you can have the top left pixel, which represents the top left tile on the whole image,

and a color. So you can give a color and reference, and there is a relationship with the tile, with the color, because the color has an index from 0 to 0xFF. So it can represent a tile, a pixel in the tile maybe, so let's use this. So this is by example a simple raw canvas, but you can start from a blank one.

It's just to show you how it's ordered. You see there is a color represented for each tile, so if you say color EB, it represents this tile, and if you say color 0, it's the other one, you don't have to start with that. You just have to start with a single palette, which is ordered like this, and you can see that on your palette,

the position of the color represents the position on your picture. It's easier to draw. Now, how do you do the different drawings, the tiles while you draw it on the canvas? The sprites frame, you draw them on the canvas, but you can't have several tiles to draw them. And the tile map,

the tile map meaning your levels, well, you will draw with a color, referencing the tile that you precedingly drew on the canvas. Let's make an example. The top left tile is number 00, so you draw black on your level. For now we have no behaviors. We didn't say that this is some sky,

this is something that blocks the player, etc. So, for example, here we have some tiles on the top left, so we have nine tiles in plus one, and a level under it. The sky over there is black, meaning that it will reference this small here.

And you see here the terrain, maybe you don't show it, but it corresponds to the color of this tile here, 16 by 16, etc., etc. So you can draw your level like that. You can put some sprites. There are some sprites over there, so there are, for example, five elements, and you can see the green points,

meaning that these points will be the hitbox of the sprites. You can have bigger sprites, so the hitbox will be separated on several sprites, or you will scan after that where it is. How do you represent that on your level? That's easy. The first frame of the animation

is the number 40, so you put color number 40 on your level. You still cannot play it. It's just display. You can have another sprite, a bigger one with another hitbox, by example. This one has only two frames. We didn't see how to animate it. There are five tiles, special tiles at the bottom,

which are here to define all of the behaviors. There is a mini-map on the bottom left. Maybe you've seen that in the presentation. The mini-map shows you that each pixel here represents a tile on your whole drawing, and there are preset colors for saying,

well, this is the ground, this is the sky, this will kill you if you go into it, et cetera, et cetera. And this color here is the color of the first level, so the program needs to find the first level here. The number of levels, objects, info.

There is one tile where you can reference how your objects will behave. You can specify three things with three pixels, basically, per line, per object. First one, well, for where is positioned your object. The first is the physics. How does it work?

Is it standing, is it working, does it chase the player, does it, et cetera? The second one is what does it do when you collide with the player? Does it give a bonus? Does it kill you? Does it make you end the level, et cetera? And another one meaning what do I do after be killed? Do I spawn another sprite?

So you can have interaction. For example, if you jump on a mushroom by example, it spawns another one that is a coin, and it spawns another one with an animation for giving you points, by example. So you can have some combinations between your different behavior. There are lots and lots of different behavior. I will show you, maybe, if I got time in the reference,

you can see that. But you can mix and match different way too. For the movement, yeah, you have static, move once and then disappear, bullet, so it go fast through the screen, left, right, walk, walk and fall if the enemy walk and jump sometimes. The sign pattern by example is collision.

Does it kill the player? Does it switch sometimes from one level to from one identity to the next one if you jump to it? For example, you can have keys to open some doors, by example, with that kind of behavior. And what does it do when you're killed? You can spawn another sprite.

So you can see there, the mini-map and the different sprites. And quickly, you can finish it with some titles. Here you have four titles for four levels. You have some titles also for another level. You have some pixels defined here at the beginning

to give you per level to remember what is the world physics of your game. And I didn't add the music. I'll show you. You can also use a real map editor. I just created something to use a real map editor and then output to an image. Let me show you the images that you can do with that.

Can I do it better? So this one is a finished game. I will show you how it works. This one maybe you've heard about. So you can do that like that.

It's basically auto scroll with infinite jumps and you die when you touch anything. Maybe you've heard of this one also. This is basically a four level Mario Bros. Not everything is finished. Not everything is...

But you can compose everything with the different elements I've told you. You can see how are positioned, the different levels, what are the different types and what are the different sprites. There is also this one which is absolutely not finished but it could be done maybe. This one is a space shooter. A tiny space shooter.

This one is... Well, I'm a little bit ashamed of the graphics but it should be kind of ghosts and goblins. Would you like to have a small demo? Maybe. So does it work?

Can you see something? This one is bad. So basically this is the demo I've shown you. Maybe let's start with the... So this one is the one that I've shown you as a graphic. So it's a very simple title but it's directly right from the bitmap graphics.

I didn't define numbers on the demo. So you have the guy. You can jump. You can see that the gravity is off because you can jump very high. There are some coins over there.

So it's a sprite that doesn't move except that has one frame moves a little bit and then just if you touch it, it's killed. There is no output. And you can... And if you got one, you have some... So let's just take another one. This one is a demo game. Maybe a little more graphically less advanced but...

And you can... There are letters. So... I'm bad. And if you can go through the second level, you can... The second level is a shooter on this game. Let's show you maybe a shooter, how you can space force.

I don't know if it works actually, this one. Yes, it does. You cannot shoot in fact because... Well, because I didn't call the shooter. So you have to... Okay, so... Okay, I have failed.

Okay, maybe the Mario... It was just a simple... So the first level... There is sound actually for this one with the first level of Mario. The first level of Mario but you cannot see that. And I'm bad, okay? But it's playable. It's basically playable. So it's really a work in progress.

But you can try yourself to build on another one. You can draw... All you need is GIMP and the emulator which is running and run on the PC. And... Yeah, that basically hit. And you can use your same drawing to run it on the big box directly.

That's it. Okay? So it's only platform games? Or are there plans to allow like top-down games maybe?

There are too many ideas. But yes, you can do... Well, you could do top-down games with the gravity because you fall. You have a maximum vertical. So you could do that with it, with vertical... With no jumps, vertical levels. And the gravity, it could be...

Yeah, you could add a top-down. Growing up would mean that you can have a negative gravity. It could be done, of course. The idea is that we will add some world physics and expanding what the number of games you can do.

Sorry. So is the framework interpreting the image? Or are you translating it into something, compiling it, combining it? No, because the big box... Sorry, the question is either transpiling or recompilation of the image in RAM.

No, because the big box is too constrained for that. And so it directly reads the content of the game in memory. It dumps, basically a dump of your image in memory and interpreting and generating the graphics on the fly. Is it possible to create multiplayer games?

No. No, not for now. I don't know. Well, of course, if you have got a compiler. Sorry, the question was, can you make multiplayer games? Well, if you've got a good compiler and you have enough time, you could. For now, it's a little bit far-fetched from this. Yeah, why not?

There are two USBs. You should...