multidimensional code

VCL: a new open source VirtIO-GPU OpenCL driver leveraging hardware acceleration

Antonio Caggiano — Tue, 15 Oct 2024 00:00:00 +0000

Computer Graphics: Follow The Light

Antonio Caggiano — Tue, 03 Sep 2024 00:00:00 +0000

Note: This blog post is a transcript of my talk at the Archaeological Park of Paestum</a> for Paestum Tech Days</a>. The conversational tone and simplified explanations reflect the original presentation style, aimed at making computer graphics concepts accessible to everyone, regardless of their technical background. </blockquote>

</iframe> </div> </div>
Okay, let's start with a nice question: How do we see? With the eyes. The eyes are a marvel of nature. They are light sensors. They capture light and send a signal to the brain, which we interpret as our internal representation of the reality around us. Wonderful.
What is light? This second question is a bit more difficult. A didactic definition would be: a collection of photons</a>. It is electromagnetic radiation</a> — a variation of the electric and magnetic fields in space and time. It is a flow of particles and waves. The particles are photons. It has a dual nature</a>: it has both a particle nature and a wave nature. Let's say it bounces like a ball, but it waves like the sea. It is energy that travels, so much so that we can capture it with solar panels to power our homes.
Yes, it's difficult. In fact, you need to be Einstein</a> to have the genius idea to define light as a flow of photons, which are packets of energy. For example, a 60-watt light bulb emits 800 billion photons per second. And that's a lot. But what is the main source of photons that reaches planet Earth? The sun. How many photons does the sun emit per second? Many. It's such a large number that it's unimaginable.
How Does Light Work?</a></h2>
Okay, but if we want to simulate light with a computer, we need to understand it a bit more. It behaves like particles, so we can use the concepts of particle and wave physics, but we should also observe some phenomena that are typical of light.
For example, the phenomenon of transmission. Light passes from one medium to another, for instance, from space into the Earth's atmosphere. It arrives with a certain direction, intensity, and frequency, and continues in the same direction, with the same intensity and frequency.
There's the phenomenon of reflection</a>, which happens with a mirror; a ray is reflected by the mirror and changes direction.
The phenomenon of refraction</a> is typical of water when a ray changes direction making it seem like a straw is broken, but it is not. It's just the optical effect of light refraction changing direction.

 </center>
The phenomenon of diffraction</a>. Here we have a ray that splits into many other rays of different intensities or frequencies. A clear example is a prism, which is also a beautiful album by a musical group</a>. The ray enters the left side of the prism and is split into other rays of different intensities. It exits on the right side but at different frequencies, and different frequencies correspond to different colors. We perceive a different color if the frequency changes, and our eye can capture certain frequencies of electromagnetic radiation. There is a range that we see, but outside this range, there are frequencies we cannot see, such as infrared</a> and ultraviolet</a>.
The phenomenon of absorption. Light is completely captured by an object and disappears, but it cannot disappear. No, because we know from the principle of conservation of energy</a> that "Nothing is created, nothing is destroyed, but everything is transformed", so this ray becomes something else, presumably it could become heat.
The phenomenon of scattering</a> happens in clouds. The ray splits into many other rays and goes everywhere. It also happens in fog. I don't know if you've ever seen streetlights in the fog; you see this halo.
In reality, all these light phenomena do not occur distinctly and separately but all happen together, everywhere, simultaneously. For example, there are materials that can reflect more, absorb more, or transmit/refract light more. But the other phenomena still occur, even if only to a small extent.

 </center>
Light Simulation</a></h2>
Finally, we get hands-on. Let's delve into the technical issue of real-time light simulation.
What does real-time mean? I looked it up in the dictionary because I didn't know either. So, it means a duration corresponding to the real one, thus very quickly, almost immediately. Well, at least to give us the optical illusion of continuity. Our eye can perceive something as continuous if I update it every 16 milliseconds. Every 16 milliseconds a new image, so we perceive it as continuous. 16 milliseconds allow us to make 60 images per second.
Okay, so 16 milliseconds, but we have to do a lot of calculations here. I talked about billions and billions of photons. I can't simulate all these photons because I only have 16 milliseconds. So, are we interested in all the photons? No, maybe I can focus on a reduced number of photons. Okay, and which ones interest me? Those that hit the eye. These are the ones that contribute to the image. These are the ones that actually interest me.
In computer graphics, we use the term viewpoint or the term camera, from camera or video camera. So I will use camera and eye interchangeably. How can photons reach the eye? They can arrive directly. They start from a point source and reach our eye. Or they can also be emitted by objects that have a certain volume, like LED panels. They can bounce and reach our eye. In this case, it is called indirect light. And they can bounce more and more times, an indefinite number of times.
So how do I know which photons reach my eye? This is an important question because there are photons that do not reach the eye that I want to ignore. So, it's time to talk about practical methodologies. In computer science, we call these algorithms, which in the world of cooking are called recipes.
Whitted-style Raytracing</a></h2>
Step number one: what do I see? I know where I am, I want to understand what is in front of me. I trace a ray, what do I hit? Maybe I hit something. Yes, I found something. Okay, let's trace more rays. Maybe I continue along this path. I trace a ray in the reflected direction and then trace other rays to reach the lights in my scene. How many lights are there? I trace as many rays as there are lights.
Okay, so I trace a reverse path. This way, I make sure to trace paths that reach the camera, so I focus only on those photons, right? Clearly, it doesn't end here, because light bounces, so the reflected ray bounces on a new object. For the new object, I can trace other rays: a reflected ray and other rays to find the light recursively, repetitively.
Great, this algorithm was created in 1980 by Turner Whitted</a>. It's called Whitted-Style Ray Tracing</a>. Turner Whitted was a scientist at Bell Labs</a>. According to Americans, Bell is the inventor of the telephone, but according to us, it's Meucci</a>. At that time, Bell Labs was part of the American Telephone and Telegraph Company.
I hope that's clear. For each bounce of light, a reflected ray and other rays towards the lights in the scene. But there's a small flaw in this algorithm. What happens if my scene has thousands and thousands of lights? My electrician went crazy and created a lot of LEDs in my room. Can I simulate them all? I could spend a lot of time tracing rays for all these lights, so I need to find a better solution. I need an algorithm that scales better with the complexity of the scene.
So, let's try a new algorithm.
Path Tracing</a></h2>
Let's start from scratch. What do I see? I trace a ray. This remains common, alright? I found something, but at this point, I don't trace a ray following the previous steps; instead, I trace only one, but randomly. I find something. Okay, I continue. I trace another ray in a random direction. Oh, I was lucky. I found a light along the way. But I was very lucky. This is a path, let's remember that.
However, there are rays that I choose randomly that might not hit anything in my scene; they might get lost in the void, they might miss the light. The ray is sad.
I mentioned Path, in fact, this algorithm is called Path Tracing</a>. It was created in 1986 by Jim Kajiya</a>. At that time, he was a professor at the California Institute of Technology</a>, and since 1994, he is a researcher at Microsoft</a>.

 </center>
How beautiful. This is an image created with the Path Tracing algorithm. It is a scene called Cornell Box</a>. Cornell Boxes are a family of 3D scenes that can vary in wall color or objects in the scene. I can vary them a bit as I like, but fundamentally they are 3D scenes created by academics at Cornell University</a>. Cornell University is located in Ithaca, which is a college town in the state of New York.

 </center>
These are examples of paths that light can take. Let's look at path number one. A bounce on the metal sphere and then it reaches the camera. Path number three bounces on the wall, the ceiling, and then reaches the camera. But path number two is more interesting because of the glass sphere, so we have the phenomenon of refraction. The ray is bent, passes through the sphere, and then reaches the camera.

 </center>
In this image, we can see how the final result improves as the number of paths I consider increases. Let's focus on image number one. You see, it's very noisy. There are many black pixels. Here, for each pixel, I made only one path, but some pixels are black. Why are they black?

 </center>
I'll tell you: because, as I mentioned before, there are random paths that do not find any light along the way, so it's as if it's dark. That's why. But I can do something: maybe, for each pixel, I don't make just one path but try to make another one, and I might be luckier. This way, I increase the chances of finding the light.
In mathematics, we call these "samples", using the technical term "samples per pixel". I increase the number of samples per pixel to 2, 4, 8, 16, 32, 64, 128, and I get a more beautiful, more defined, clearer image. I found the light with a higher probability.
However, I have to consider more paths, so I have to do more calculations, which means I might exceed the budget of 16 milliseconds. I always have to be careful not to overdo it. Maybe I can focus only on some paths; I can use some techniques. Indeed, Turner Whitted had somewhat guessed right in trying to find the light as soon as possible in order to reduce the number of samples to obtain a well-defined image.

 </center>
From 1986 onwards, however, algorithms have been improved, and I can achieve better results with fewer samples compared to naive ray tracing.
Maths</a></h2>
In short, I talked about Whitted-Style Ray Tracing, I talked about Path Tracing, which are algorithms in the Ray Tracing family. What I really mean is: Maths.
Maths. In fact, I can represent a ray with a point and a vector. The point is the origin, the vector is the direction of my ray. I represent geometries with points and indices to connect these points, like that puzzle game. For transformations, I can use matrix multiplications to enlarge, resize, rotate, and translate objects. I solve intersections between rays and geometries with systems of equations, the ray equation and the triangle equation, in this case.
Light is simulated and calculated with integrals, and here it gets a bit more complicated. But speaking of integrals, let me show you my favorite formula: the rendering equation</a>.
$L_o(x, \omega_o) = L_e(x, \omega_o) + \int_{\Omega} f_r(x, \omega_i, \omega_o) L_i(x, \omega_i) (\omega_i \cdot n) d\omega_i$ </big></center>
How beautiful, look how beautiful it is. Okay, I'll read it to you, I'll read it simply. The light that arrives in my direction is equal to the light emitted by a certain surface, maybe a LED, and all the light that arrives on this surface and is reflected in my direction. They should teach mathematics like this in school.
Raytracing Algorithm</a></h2>
This is roughly how a ray tracing algorithm works. Don't worry because I'll read it to you, line by line.
for y in range(0..screen.height): for x in range(0..screen.width): ray = Ray(origin = [x, y, 0], direction = [0, 0, 1]) for geometry in scene: intersection.color = intersect(ray, geometry) if intersection is not None: screen.pixels[y][x] = intersection.color </code></pre> For y that goes from zero to the height of the screen, so I can do one row at a time, okay? 0, 1, 2, 3, 4, 5, 6, 7, up to the height of the screen. Simple. The second line, another loop, for x that goes from 0 to the width of the screen, and I do this for each row. So for the first row, all the pixels of the row. 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15. Okay, I'll explain the rest in words. In simple terms, for each pixel, I do this: I trace a ray, see what is in front of me, if I hit something it's an intersection and I have to calculate the color. The color varies based on the material I hit and all the lights in the scene.
 </center>
This is an example of the result. Up close, you can't understand anything, but from a distance you can see that it's a Cornell box. There's a red wall on the left, a green wall on the right, and there are two objects in the scene.
This algorithm is computationally expensive because you have to check for each ray if it intersects an object in the scene, and I have to check all the objects to see which one is closest, so if the complexity of the scene increases, the time I spend doing all these checks also increases. It requires a lot of memory because the entire scene has to be available in memory, because for each bounce I have to check again if I hit all the objects in my scene, and let's say a scene can weigh several MBs if not GBs, and here we are in 1986 and memory isn't like it is today.
Do I have a reasonable alternative? Maybe an algorithm that allows me to focus on one geometry at a time? Yes, I do! It's called rasterization</a>.
So, what it actually does is focus on one geometry at a time. It loads the geometry into the graphics card, performs the necessary calculations, checks if each pixel is within the geometry, and calculates the color.
Rasterization Algorithm</a></h2>
Then, it unloads the geometry and loads another one, so I can focus on just one small triangle at a time, which is only a few bytes. Computationally, okay. I've already mentioned this part: it checks if a point is within a geometry and has low memory usage because it focuses on one geometry at a time.
However, the rasterization technique loses some of the phenomena that light gives us, and the trade-offs are these: I lose reflections, I lose refraction, I lose indirect light because I don't do the bounces, I lose shadows, and I also lose this beautiful phenomenon called caustics</a>.

 </center>
Caustics are those light phenomena concentrated in certain points due to the curvature of geometries, in this case, the glass.
I can achieve all these techniques with rasterization, but I have to use tricks, I have to approximate them, and they are not as faithful as ray tracing because ray tracing actually simulates the behavior of light and is very precise, giving us all these things for free.
We are approaching the conclusion because a few decades later, after the 80s, the 90s, the 2000s, the 2010s, we reach 2020 and, along with the pandemic, the first hardware products that accelerate ray tracing come to market. What these beautiful, powerful graphics cards do is calculate the intersections between rays and geometries for us.
Hardware Accelerated Raytracing</a></h2>
They are incredibly fast, orders of magnitude faster than the normal processor we have in our computers. So, with the latest generation smartphones, we can do amazing things.
Let me make this cameo: 'What a Time To Be Alive'!

Venus on QEMU: Enabling the new virtual Vukan driver

Antonio Caggiano — Fri, 26 Nov 2021 00:00:00 +0000

Direct Link</a>

Profiling virtualized GPU acceleration with Perfetto

Antonio Caggiano — Thu, 22 Apr 2021 00:00:00 +0000

Direct link</a>

NcJump devlogs

Antonio Caggiano — Thu, 31 Dec 2020 00:00:00 +0000

NcJump</a> is a platform game project developed with a relatively new engine: nCine</a>, an open-source C++ framework for 2D games developed by @encelo</a>.

</iframe> </div> </div>
Some time ago, a bunch of members of the GameLoop</a> community followed CS50's introduction to game development</a>, and I thought the sequence of games presented in this course could give me a good insight into what kind of game to create.
A couple of developers have already made or started to make the first few games listed by that course. There is a Pong clone</a> made by @encelo, a Flappy Bird clone made by @Vasile-Peste, and a Breakout clone under development by @mat3</a>. I opted for a Super Mario Bros clone.
The idea was to follow the steps of CS50's lecture 4</a> by using nCine instead of Love2D</a>.
Some steps are required in order to start developing a game, but luckily everything you need to know is documented on the nCine download web-page</a>. I installed nCine, cloned ncTemplate</a>, and started working on top of it.
Writing down some code</a></h1>
The main thing to consider from a software design perspective is that I renamed the main class of the template, MyEventHandler</code>, to JumpHandler</code> and introduced a Game</code> class. While JumpHandler</code> acts as a bridge between the game and the engine, Game</code> is the nucleus of the project and is responsible for the lifetimes of its objects and the logic of the application.
Then I proceeded to implement an Entity</code> class, following the idea of an Entity component system</a>. The entity can have components like a graphics sprite, a finite state machine, or a body for physics and collisions.
A GUI is mandatory to quickly iterate on new elements as they are added to the game, both to have visual feedback when debugging is needed and to tweak all sorts of values and configurations at run time. For this, I introduced an Editor</code> class, which makes heavy use of @ocornut's Dear ImGui</a>, also provided directly by nCine.
Box2D</a> is my choice for 2D physics and collisions. It is made by @erincatto and it is very easy to use.
Everything is entity</a></h1> I implemented some key Entity states: idle, move, jump, and fall. In my opinion they are the foundations of the whole gameplay and I believe the result is good enough to move on to the next steps. Then I spent some time refactoring the Entity source code that was becoming too monolithic, and improving the tileset and tilemap by using entities instead of raw sprites for both tile prototypes and concrete tiles. </iframe> </div> </div> An important consideration is that everything is an entity</a>. Characters are entities, tiles are entities, triggers are entities, and so on. So how do you distinguish between them? Every entity can have multiple components, whether it is an image or a state machine</a> or a physics body, therefore different set of components will determine all the different kinds of entities which will populate a game scene. component</th> optional</th></tr></thead> Transform</td> no</td></tr> Graphics</td> yes</td></tr> Physics</td> yes</td></tr> State</td> yes</td></tr> </tbody></table> Transform</a></h2> The transform</a> component is simply a wrapper around a ncine::SceneNode</code>. Everything else is supposed to be related to this node, so if we want to move the overall entity, we can just update the node of the transform component. It is worth mentioning that we use a unique pointer to store the node on the heap to make sure its memory would not move. This is needed as the nCine scene graph works with pointers. Physics</a></h2> The physics component as well acts as an abstraction layer between the game and Box2D</a>; it holds values like the maximum velocity, jumping strength, and so on. Most importantly, it keeps track of a handle to a b2Body</a>, which is the means to query the current physical state of the entity. Graphics and State</a></h2> At the base level, we have a graphics component with a single image or animation, and a state component with a single state which never changes. These are possibly the most common among the entities of a game. Now we need to consider the concept of a moving character with states like idle, move, jump, and fall. This set of states is also very common, so we implement it directly in C++. The result is the following class hierarchy. Subclass</th> states</th></tr></thead> SingleState</td> IDLE</td></tr> CharacterState</td> IDLE, MOVE, JUMP, FALL</td></tr> </tbody></table> It follows that a CharacterState</code> class is closely coupled to its related graphics component, which we define as CharacterGraphics</code>, so the graphics components class hierarchy is quite similar to the previous one. Subclass</th> graphics</th></tr></thead> SingleGraphics</td> IDLE</td></tr> CharacterGraphics</td> IDLE, MOVE, JUMP, FALL</td></tr> </tbody></table> As a final consideration, while a state component should be unique for each entity, a graphics component could be shared between multiple entities to avoid duplicating these kinds of heavy objects. The smooth</a></h1> I introduced a camera component and serialization to load and save to file the state of the game. While the former was pretty easy and straightforward to implement, the latter required introducing a new dependency and various scattered refactorings to pay some technical debt accumulated from previous development iterations. </iframe> </div> </div> That was easy. The camera component has two main attributes: the scene root node and the target node. The scene root node is needed because we need to simulate the camera, which means that what we actually transform is the scene root node. In other words, to move the camera in one direction, we translate the scene root node to the opposite of such a direction. The target node is the one the camera should follow. As the target node moves around the scene, the camera is updated to match its coordinates. The quickest way to implement a following camera is to just write down something like camera.position = target.position</code>, and while it works, it is not the best we could do. A better and nicer approach, which might also prevent motion sickness, is to implement a camera with smooth movement. This can be done by linearly interpolating the camera and the target position by a small factor at every update of the game. void Camera::update() { float smooth_factor = 0.125f; Vec2f smoothed_position = lerp(this->position, target->position, smooth_factor); this->position = smoothed_position; } </code></pre> The file</a></h1> Conversely, this feature required a bit more work. I started by adding @nlohmann</a>'s json</a> as a new dependency of the project for reading and writing to json files. I find it very easy to use in addition to the fact that I already used it for previous projects, like Jamspot: Sokoban</a>. The second step was implementing functions to save certain objects to and load them from file. void to_json(json& j, const T& t); void from_json(const json& j, T& t); </code></pre> The trickiest part was to make sure that all the serializable classes of objects could be default constructed. That means avoiding references as class members and preferring pointers, hence allowing semi-initialized objects while making sure they stay in this state for the shortest period possible to avoid logic errors or even crashes. Once all this has been taken care of, I was able to edit the game configuration, the tileset, and the tilemap at runtime, close the game, and re-open it to find everything as I set it before. That is key to work on the levels of the game. Jump higher</a></h1> From a gameplay perspective, the player gains confidence with the elements of interactivity of the game. First it moves, then jumps, then jumps higher. The implementation is straightforward thanks to Box2D</a>. If the jump button is still down, keep applying a small force upwards. Keep in mind that the force should be weaker than gravity, otherwise the character would take off into space. void can_jump_higher(Input& input, Entity& entity) { if (input.jump.down) { auto force = b2Vec2(0.0f, small_amount); entity.physics->body->ApplyForceToCenter(force, true); } } </code></pre> </iframe> </div> </div> Resizing the tilemap</a></h1> This was less straightforward. I am starting to believe the more something is boring, the more difficult it is to implement. Resizing is not trivial; many things should be considered. For simplicity, here I will focus on the concrete tiles grid only. At the beginning, I used a simple vector to store all concrete tiles of the map and with a simple formula (y + x * height</code>) I was able to index a cell of the grid. Then I realized that resizing this vector was not convenient as the order of the tiles in the cells would not be preserved. As a solution, I changed the structure from a simple vector to a vector of vectors, so we could say a list of columns. That simplified indexing as you could just use the subscript operator</a> to access the right tile (tiles[x][y]</code>). It also simplified resizing. If you want to change the width of the tilemap, you just modify the number of columns by calling tiles.resize(new_width)</code>. As you can imagine, if the width shrinks, you lose those columns, while if the width grows, you get new columns with a default concrete tile. I can not overstate the importance of default values</a>. Changing the height is slightly different, as you need to resize all the columns. for (uint32_t i = 0; i < width; ++i) { tiles[i].resize(new_height); } </code></pre> The easy stuff</a></h1> While a static entity is not affected by physical forces and thus does not move, a dynamic entity is affected by forces, so it can fall and can be pushed and pulled around. Thanks again to Box2D</a>, implementing this was just a matter of setting the type of physics bodies to either b2_dynamicBody</code> or b2_staticBody</code>. </iframe> </div> </div> Another easy but important thing to add was a proper background to give to players' eyes something more interesting to see than a boring solid color. I just added a static sprite, but I guess it would be nice to implement a fancy parallax scrolling effect</a> in the future. At this point, I realized that something was missing. Tiles and entities could be added and positioned freely in the scene and, as all normal people who like symmetry, I started wanting to destroy them, not by interacting through the editor, but as Mario does by punching (or hitting with his head?)! Appetite for Destruction</a></h1> Well, not every tile should be destructible, but some of them certainly could, and I supposed it could be a good idea to give this ability to the player. I started by introducing a flag to determine whether a tile is destructible or not. Then I implemented a destruction listener, which is a Box2D contact listener</a>, responsible for checking impulses generated from collisions between entities. When this impulse is big enough, both flags of the entities involved in a collision are checked and, if destructible, added to a list. This list is processed later when the actual destruction happens. It is important to note that this should not be done in the previous step if you want to avoid errors while Box2D is still processing its update. After tweaking the threshold for the impulse triggering destructions, last thing to do was to increase manually impulses when the collision involved a character punching. In technical words, when one of the entities is a character and the normal of the collision is close to (0, -1)</code> destruction is triggered for the other entity. The result is really cool because not only do entities get destroyed after a collision with the main character, but they also get destroyed when heavy collisions happen between each other. </iframe> </div> </div> Push and pull</a></h1> Dynamic entities have been added to the game, and they can be pushed and pulled around the scene. This meant that new states should be added to characters, push and pull indeed. The push state is enabled when a character is trying to move and finds an obstacle either on its left or its right, quite easy to implement. Obstacles in the four directions (up, right, down, left) are collected after the physics system update by checking for physics body collisions and the normal of contact points. In addition, some bitflags</a> are set which tell whether there are obstacles in any of the four directions. </iframe> </div> </div> The pull state is enabled when the player presses the x</code> button and there is a dynamic obstacle, which is checked by querying the type of the obstacle's physics body. When the conditions are met, a distance joint</a> is created between the character and the dynamic entity to make sure that, when the character moves, the distance between the two bodies remains the same, effectively giving the character the ability to carry around the entity. Of course, the joint is destroyed when exiting from the pull state. Data submodule</a></h1> A git submodule</a> has been added to the repository under the data/</code> directory, pointing to Fahien/ncJump-data</a>. There you could find the latest assets of the game: configurations, game maps, tile sets, and animations. A better editor</a></h1> Many improvements have been added to the in-game editor: a main menu bar at the top for choosing a placing mode between tile and entity, changing the opacity of certain elements of the scene according to the current mode for immediate visual feedback; a config window to tweak all sorts of values not directly related to the gameplay, like the size of the window, the scale of the scene or the UI, the offset of the camera to move around the scene without necessarily moving the character. </iframe> </div> </div> Factories</a></h1> The time to add enemies to the game</a> has finally come, and that translates to factories</a>! An enemy is just another kind of entity, which is the reason that pushed me towards implementing a class which sole responsibility is to create entities: the EntityFactory</code>. This factory contains a list of entity prototypes which can be selected from the editor and placed into the scene. Under the hood, the prototype is cloned, the clone is moved at mouse position, and it is added to the list of entities of the scene. </iframe> </div> </div> At this point I realized that every clone was duplicating textures, which is something that could and should be avoided, so I introduced another factory: the GraphicsFactory</code>. The responsibility of this class is to maintain a list of textures which can be referenced by multiple graphics components, as well as to create any kind of sprite that makes use of one of those textures. Commands</a></h1> Once I had enemies in the scene, I began wondering how to make them move. Reusing the state component of the main character sounded OK to me, but there was a problem. The movement logic within the state component was directly checking the gamepad and the keyboard, which meant that player's input would move both the main character and all the enemies. Decoupling</a> to the rescue. Input → MoveCommand → StateComponent </code></pre> I removed the dependency to the input from the state component, and I introduced the concept of commands. For simplicity, I will just focus on the MoveCommand</code>. The state component now is just listening for move commands and, when they are issued, the component inspects the values in a move command and updates its state accordingly. Move commands, and possibly other kinds of commands, can be issued by any source: player input, in-game console, scripts, and so on. Scripts</a></h1> Other engines may use terms like behaviors, but I prefer to stick with the technical term: script. With this you can indeed model behaviors of entities, like a wandering behavior that I had in mind for my first class of enemies. Ideally it might also be written with a scripting language, like LUA</a> which is supported by nCine, but that is something I may explore in the future. I wrote down a couple of line for the wandering behavior which should just move the entity to the right or to the left until an obstacle is encountered, and then it should turn back and continue in a loop. The result is quite interesting, but I believe it can be further improved. </iframe> </div> </div> Dying state</a></h1> Definitely one of the fundamental states. Any living entity should die at some point, and this state represents that period of time where an animation should play, telling the player an enemy is defeated or that the game is over. The update method</a> of this state is super easy and it looks like this. void DyingState::update(Entity& entity) { if (entity.animation.has_finished()) { entity.set_enabled(false); // just reuse this entity for something else } } </code></pre> </iframe> </div> </div> Enabled flag</a></h1> Of course this explains the Entity::set_enabled()</code> method just introduced in the previous section. By calling it, we can effectively disable an entity and all its components without destroying it or freeing its memory, so that it can be recycled to be reused later when we, for example, need to spawn another entity. Array of states</a></h1> This was an important optimization. Before this, every state transition triggered the destruction of the old state and creation of an instance of the new state, which is not really needed and does not scale nicely as a scene grows. Now, a state component keeps track of an array of all the possible state objects, together with a pointer telling us which one is the current state. Initial position</a></h1> Another requirement for the scene is to define where the player should start. This initial position is a pair of coordinates which tells us just this. When a scene starts, we put the player there. Definitions and factories</a></h1> I love this pattern and I think I will use it from now on for all of my game projects. Basically, we have to deal with big and heavy objects which are not easily serializable. Think of wrappers around third party components like Box2D bodies or nCine sprites. I tried to find a way to serialize those objects and I believe I found a very nice solution which is anyway something widely used, so I possibly just reinvented the wheel here, but that is ok. I do not serialize those objects. I do serialize their definitions. A definition is a collection of all the parameters needed to construct an object. Let us take a ncJump graphics component as an example. // Very simplified auto def = GraphicsDef(GraphicsType::TILE); def.path = String("image.png"); def.layer = 2; auto gfx = GraphicsComponent(def); </code></pre> As you can see, the graphics component constructor takes a graphics definition as a parameter. A graphics definition, like all other definitions, is a Plain Old Data</a> (POD) structure, which enables us to use nlohmann macros</a> to quickly define all the functions needed to serialize it. Done. Awesome. // That's it NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE(GraphicsDef, type, path, layer); </code></pre> CI and automatic deploy</a></h1> The project builds automatically through GitHub actions, for Linux, Window, MacOS, Android</a>, and believe it or not for the web. Indeed, click here</a> and be prepared to say wow. All the credits for this go to the brilliant nCine author: @encelo</a>! All the updates can be found on the NcJump GitHub repository</a>. Rust+Wasm+WebGL: Create interesting interactive 3D content for the web Antonio Caggiano — Thu, 17 Dec 2020 00:00:00 +0000 Direct Link</a> Panfrost performance counters with Perfetto Antonio Caggiano — Fri, 21 Aug 2020 00:00:00 +0000 Direct link</a> An exercise with boost::asio Antonio Caggiano — Fri, 03 Apr 2020 00:00:00 +0000 If you are new to boost::asio</code>, you can find a good introduction on boost.org</a>. This post describes an exercise built upon the asynchronous daytime server presented in the boost tutorial. List of clients</a></h2> The first thing we are going to implement is a way to ask the server for the list of clients currently connected. We need to keep track of incoming connections, therefore we add the following field to the server: std::vector<std::unique_ptr<Connection>> Server::connections; </code></pre> Since we use references to connection objects in other parts of the program, connections should not move from their position in memory. New connections may come in while other connections are still being handled. If the vector resizes, its objects might move. This is why we allocate connections on the heap and use smart pointers as elements of the vector. </blockquote> Once we have a field to store incoming connections, Server::accept()</code> can be improved. We do not need to create new connections all the time, as we can recycle old connections that were closed. std::unique_ptr<Connection>* new_con = nullptr; for (auto& old_con : connections) { if (!old_con->get_socket().is_open()) { // Recycle old connection new_con = &old_con; break; } } if (!new_con) { // No old connections found, so we create a new one new_con = &connections.emplace_back(std::make_unique<Connection>(ctx)); } </code></pre> What happens if a large number of clients try to connect to the server at the same time? </blockquote> Communication protocol</a></h2> When either the server or the client wants to wait for incoming packets, it uses the following asynchronous function: asio::async_read( socket, asio::buffer(&message, sizeof(message)), std::bind(&Connection::handle_read, this, std::placeholders::_1) ); </code></pre> This function will call handle_read</code> only when exactly sizeof(message)</code> bytes have been received. Data received will be stored in message</code>, an instance of Message</code>, which is defined like this: enum class Command : uint16_t { NOP, HI, LIST, STR, // and more... }; struct Message { Command command; uint16_t version; std::array<char, 28> data; }; </code></pre> Here are a few examples of messages that can be created using this design: This is a command message. It is used by a client to ask the server for the list of all connected clients. LIST (2 bytes) </td> VERSION (2 bytes) </td> - (28 bytes) </td> </tr> </tbody> </table> </li> This command sends a human-readable message. STR (2 bytes) </td> VERSION (2 bytes) </td> STR (28 bytes) </td> </tr> </tbody> </table> </li> </ul> Server</a></h2> When a new connection comes in, the server introduces itself with a HI</code> message. This message contains the name and version of the server: HI (2 bytes) </td> VERSION (2 bytes) </td> NAME (28 bytes) </td> </tr> </tbody> </table> Then it waits for incoming packets via async_read</code>, as previously mentioned. By reading data directly into message</code>, the handle_read</code> callback becomes straightforward: void handle_read(const boost::system::error_code& error) { // Error handling [...] switch (message.command) { case Command::NOP: break; // nothing to do case Command::LIST: { // @todo Send a message with the list of all clients break; } } // switch // [...] } </code></pre> Client</a></h2> The client should run two different threads: A network thread to handle incoming messages from the server.</li> A main thread to read user input, update its logic, etc.</li> </ul> For this purpose, before the main loop, we spawn a thread to run the IO context: auto con = Connection(io, endpoints); auto thread = std::thread([&io] () { io.run(); }); while (true) { // main loop } </code></pre> Vulkan Samples: Subpasses Antonio Caggiano — Wed, 30 Oct 2019 00:00:00 +0000 Direct Link</a> Vulkan Samples: Appropriate use of render pass attachments Antonio Caggiano — Tue, 29 Oct 2019 00:00:00 +0000 Direct Link</a> Computer network notes Antonio Caggiano — Mon, 21 Dec 2015 00:00:00 +0000 Line coding</a></h2> With line coding</a>, it is possible to represent sequences of bits using digital signals. Among the line codings we have: unipolar</a>, polar</a>, bipolar</a>, multilevel</a>, and multiline</a>. Nyquist theorem In a channel without noise, this theorem gives us the maximum velocity at which we can send bits: N_{max = 2 × B × log_{2 L where B is the bandwidth and L is the number of signal levels used to represent the data. </blockquote>}}Unipolar code NRZ</a></h3> The NRZ (Non-Return-to-Zero) code represents 1</code> as a positive voltage and 0</code> as a null voltage. It is called NRZ because the signal does not return to zero while coding each bit. Polar code NRZ</a></h3> In a polar code, two levels of voltage are used: positive and negative. In NRZ-L (Level) a positive voltage represents 0</code> and a negative voltage represents 1</code>. In NRZ-I (Invert) the bit is determined by a change in the voltage level: absence of change means 0</code>, change means 1</code>. Bipolar code AMI</a></h3> The AMI (Alternate Mark Inversion) code represents 0</code> as a null voltage and 1</code> as switches between positive and negative voltages. Switching</a></h2> Switching is a convenient method to connect nodes in a very large network where special nodes, called switches, are connected together and can create connections between two or more stations connected to the switches. There are three categories of switching networks: circuit switching</a>, packet switching</a>, and message switching</a>. Circuit switching networks</a></h3> A circuit switching network has a collection of switches connected together with links divided into multiple channels thanks to multiplexing</a>. The communication between two stations requires three steps: Connection setup, where a path is found on the links between the switches and a channel is reserved for each link.</li> Data transfer, where all the channels dedicated to the connection remain unavailable to other connections.</li> Connection teardown, where a station sends a signal to every switch to free their resources.</li> </ul> Using a circuit switching network is not the best for efficiency: we could have long periods of inactivity with no data transfers, which means wasting those resources dedicated to the connection. On the other hand, the delay is minimal: since a path is dedicated when establishing a connection, data flow without stopping at each switch. Packet switching networks</a></h3> In this network, data need to be split into packets independent from each other, namely datagrams, with variable or fixed length depending on the protocol. Switches here are also called routers. A message can be subdivided into more datagrams which can travel on different paths and reach their destination in a different order, or they can get lost, or get eliminated due to a shortage of resources on the network. Datagram networks have no connection, meaning that switches do not keep track of connection states. There is no connection setup nor teardown. In order to know how to send a datagram, switches maintain dynamic routing tables</a> periodically updated. From an efficiency perspective, packet switching networks are better than circuit switching networks: resources are allocated only when there are packets to transfer. The delay however can be higher: each packet could follow longer paths or need to wait in switches before being forwarded. Multiple access protocols</a></h2> With random access protocols, stations do not have control over the medium and its usage is competed for. Stations can check the state of the medium at any time and there is no access order. There could be cases where two or more stations try sending simultaneously, causing a collision which destroys or modifies the frames. Among random access protocols we have: ALOHA</a>; CSMA</a>; CSMA/CA</a>; CSMA/CD</a>. Aloha</a></h3> In the original ALOHA protocol, each station sends a frame whenever it wants, therefore there are chances of collisions. We rely on feedback from the recipient and, if it does not come, the recipient will send the frame again. Before resending a frame destroyed by a collision, stations need to wait a random amount of time, namely backoff time or T_{b. After a maximum number of transmission attempts, K_{max, stations must desist and retry later.}}CSMA</a></h3> The Carrier Sense Multiple Access method tries to improve network performance by minimizing collision probabilities by making stations check the state of the medium before sending data. If two stations check the medium and find it free at the same time, a collision can still happen if both stations choose to transmit. There are three methods which can determine the behavior of the stations: 1-persistent: if the medium is busy, the station continues to check the state until it becomes free to send data.</li> non-persistent: if the medium is free, the station sends data, otherwise it waits a random time before repeating the same operation.</li> p-persistent: if the medium is busy, the station continuously checks the state until it becomes free, then: it sends the frame with probability p</code>.</li> it waits, with probability 1-p</code>, for at least the maximum propagation time before checking the medium again. At this point, if the medium is free it restarts from 1, otherwise it performs a backoff operation.</li> </ol> </li> </ul> CSMA/CD</a></h3> The CSMA/CD (collision detection) method adds an algorithm to detect and handle collisions. A station, while sending a frame, continuously checks the medium and if it detects a collision, stops transmitting immediately. In order to be effective, it is important that the minimum transmission time of any frame is at least twice the maximum propagation time. Otherwise, stations could not detect all collisions. T_{fr ≥ 2·T_{p </blockquote>}}CSMA/CA</a></h3> The CSMA/CD method is not effective in a wireless network, where signal energy loss during transmission could negatively affect collision detection. The CSMA/CA (collision avoidance) protocol avoids collisions with three strategies: spacing between frames: when a station finds the medium available, before transmitting, it waits for a period of time, namely interframe spacing (IFS).</li> collision window: a station that has just finished waiting for IFS waits again for a random number of intervals. After each interval, it checks the state of the medium and if it is busy, pauses this process and restarts it later when the medium is free again.</li> controls: guarantee that the receiver has received the frame and no collisions have happened.</li> </ul> Controlled access</a></h3> With controlled access protocols, stations agree on the usage of the medium. There are three methods: Reservation: stations need to reserve a time interval during which they can transmit.</li> Polling: one of the stations controls the medium and the other stations follow its instructions.</li> Token passing: stations are organized as a logic ring</a> and access to the medium is allowed only when a station has the token, a special frame, which circulates among the stations.</li> </ul> Channelization</a></h3> In channelization the bandwidth is shared between the stations. Among channelization protocols we have: FDMA</a>, where the bandwidth is subdivided into non-contiguous sections assigned to the stations.</li> TDMA</a>, where the channel is used by one station at a time.</li> CDMA</a>, where the medium carries all transmissions simultaneously, isolated thanks to an encoding system.</li> </ul> Spread Spectrum</a></h2> In Spread Spectrum</a> techniques, signals of various sources are combined to prevent detection and interference. Those techniques are based on redundancy, increasing the width of the original bandwidth. Frequency Hopping Spread Spectrum</a></h3> Frequency Hopping Spread Spectrum</a> (FHSS) selects carrier frequencies pseudo-randomly, modulated by the original signal. A third-party does not know on which frequencies data are transmitted and impeding the transmission is difficult since it would require generating interference on multiple frequencies. Direct Sequence Spread Spectrum</a></h3> Direct Sequence Spread Spectrum</a> (DSSS) maps every bit of the original signal to a wordcode of n bits through a hopping code. Wireless LANs use Barker code</a>, where n is 11, which means that the required bandwidth is 11 times larger. Error Control in Data Link Layer</a></h2> Stop-and-wait ARQ</a></h3> The Stop-and-wait ARQ</a> protocol is an improvement to the stop-and-wait. After transmitting a frame, the sender waits for an acknowledgement (ACK) from the recipient. At this point, the Automatic Repeat reQuest</a> (ARQ) mechanism checks for errors. The data frame and ACK frame have a 1-bit field for a sequence number, so it can be either 0</code> or 1</code>. The recipient does not send any feedback for damaged or out-of-order frames. After waiting for the ACK for a certain amount of time, the sender re-transmits the frame. This protocol is quite inefficient as the communication channel will handle at any time at most one frame, therefore we would not use its full transmissive capacity. Go-back-N ARQ</a></h3> The Go-back-N ARQ</a> protocol manages to send more than one frame, keeping a copy for each one if re-transmission is needed, discarding them when their relative ACK frame is received. It uses m bits for the sequence number field, so its values are within [0, 2ᵐ - 1]. The sender maintains a sliding window for these values, with size Sₗₑₙ = 2ᵐ - 1</code>, and two indices: Sₚ</code> pointing to the first frame still waiting for the ACK and Sₙ</code> pointing to the next frame to send. The recipient, on the other hand, has a window of size 1</code> as it is only interested in one ordered frame, while discarding any other. Go-back-N ARQ sender sliding-window with m = 3 When the time for the ACK of a frame is over, the Sₙ</code> index goes back (go-back) to the first frame without an ACK. In a channel with a high frequency of errors, this protocol would be inefficient: a damaged frame could mean re-sending many frames, resulting in a slowdown of the transmission. Selective Repeat ARQ</a></h3> The Selective Repeat ARQ</a> protocol solves the Go-back-N ARQ problems by avoiding re-sending the frames which arrive out of order, focusing only on the damaged ones. Both sender window and recipient window have size 2ᵐ⁻¹</code>. This means that frames can arrive out of order without being discarded by the recipient. Network switches</a></h2> Network switches</a> are used to connect together multiple networks. They can operate at various layers of Internet</a>: below the physics layer: passive hubs;</li> at the physics layer: repeaters and active hubs;</li> at the physics and link layer: bridges;</li> at the physics, link and network layer: router;</li> at all layers: gateway.</li> </ul> Passice Hubs</a></h3> Passive hubs are simple connectors between wires. They do not amplify the signal and do not need power supply. Repeaters and Active Hubs</a></h3> A signal traveling within a wire is subject to attenuation which can affect the integrity of data. Repeaters receive a signal before it degrades, they regenerate and forward it again. Active hubs are simply repeaters with multiple ports and are useful for star networks</a>. Bridge</a></h3> A bridge, as well as having the same capabilities as a repeater, can check source and destination addresses in a frame and figure out which port to forward it to, through a forwarding table</a>. In a transparent bridge</a>, the forwarding table is built automatically based on the traffic on the network. Router</a></h3> A router</a> operates on the network layer sending packets based on logic addresses. They are commonly used to connect LANs or WANs to the Internet. Gateway</a></h3> A gateway</a> is able to read and interpret messages from applications, therefore it could be used to connect two networks based on different models. Address resolution</a></h2> With address resolution protocols it is possible to obtain the logical address corresponding to a physical address and vice versa. Address Resolution Protocol</a></h3> Address Resolution Protocol</a> (ARP) allows a node to discover the physical address associated with a particular logical address. Those requests are sent in broadcast while the response is sent in unicast from the unique node which corresponds to that logical address. Reverse Address Resolution Protocol</a></h3> Reverse Address Resolution Protocol</a> (RARP) enables a node to find its logical address from its own physical address. This protocol is obsolete and it has been replaced by BOOTP and DHCP. Bootstrap Protocol</a></h3> Bootstrap Protocol</a> (BOOTP) works in the application layer and is based on a node of the network called a relay agent which knows the IP address of the BOOTP server. It is not dynamic because the associations between addresses are based on static tables manually managed by the administrator. Dynamic Host Configuration Protocol</a></h3> Dynamic Host Configuration Protocol</a> (DHCP) allows both static and dynamic allocation of IP addresses and it is compatible with BOOTP. A server using this protocol has a database to store static addresses and a database to store dynamic addresses. Routing protocols</a></h2> Routing protocols allow routers to communicate between each other for updating routing tables. There are protocols for intra-domain (Routing Information Protocol, Open Shortest Path First) and inter-domain (Border Gateway Protocol) routing. Distance-vector routing protocol</a></h3> In the Distance-vector routing protocol</a> every node maintains a vector with the minimum distance between other nodes. At the beginning, nodes know only the distance from the nodes they are directly connected to, but by sharing their routing tables with nearby nodes they can discover the topology of the entire network. Routing Information Protocol</a> (RIP) is based on a distance-vector and it is trivial as it assumes that the cost of hopping from one node to another would always be one. Link-state routing protocol</a></h3> In the Link-state routing protocol</a> every node builds its own routing table interpreting the entire network as a graph with Dijkstra's algorithm</a>. At the beginning, every node has a partial knowledge of the network, with nearby nodes, and shares that information with other nodes by sending packets called Link State Packets (LSP). The Open Shortest Path First</a> protocol is based on the link layer. Path-vector routing protocol</a></h3> Inter-domain routing is based on the Path-vector protocol</a>, where the various autonomous systems have a special node which shares its own routing table with nearby autonomous systems. The routing table will contain all possible destinations and the paths to reach them. The Border Gateway Protocol</a> is based on a path-vector. Devember: Socket API Antonio Caggiano — Tue, 15 Dec 2015 00:00:00 +0000 This devlog introduces the fundamental functions of the Berkeley socket API</a> by developing a simple client and server in the C language. The complete source code is available in this GitHub repository</a>. Client</a></h2> The first thing to do is to create a connection-oriented (SOCK_STREAM</code>) socket of the IPv6 Internet protocol family (AF_INET6</code>). This will use TCP</a>, a reliable transport protocol. int sockfd; if ((sockfd = socket(AF_INET6, SOCK_STREAM, 0)) < 0) { perror("socket"); return -1; } </code></pre> The socket can be used to establish a connection with a server, and we can specify the address to connect to using a sockaddr_in6</code> structure. struct sockaddr_in6 servaddr; bzero(&servaddr, sizeof(servaddr)); servaddr.sin6_family = AF_INET6; </code></pre> Both the port and the address data follow the host byte-ordering, which is not guaranteed to be the same as the ordering used by the network protocol. Accordingly, we need to convert them to a network representation, which can be done by using htons()</code> for the integer port and inet_pton()</code> for the IPv6 address string. servaddr.sin6_port = htons(atoi(argv[2])); if (inet_pton(AF_INET6, argv[1], &servaddr.sin6_addr) <= 0) { perror("inet_pton"); return -1; } </code></pre> We can then pass the socket and the sockaddr structure to connect()</code>, which will reach out to the server. if (connect(sockfd, (struct sockaddr*) &servaddr, sizeof(servaddr)) < 0) { perror("connect"); return -1; } </code></pre> Once the connection is established, we can receive data from the server by reading from the socket. The bytes read will be stored in the recvline</code> buffer, then a 0</code> is added at the end to finalize it as a string, and fputs()</code> is used to print it to stdout</code>. int n; char recvline[MAXLINE + 1]; while ((n = read(sockfd, recvline, MAXLINE)) > 0) { recvline[n] = 0; fputs(recvline, stdout); } if (n < 0) { perror("read"); return -1; } </code></pre> When the communication has finished, we need to close the socket, as with every file descriptor. close(sockfd); </code></pre> Server</a></h2> As with the client, the first thing the server does is create an IPv6 socket. int listenfd; if ((listenfd = socket(AF_INET6, SOCK_STREAM, 0)) < 0) { perror("socket"); return -1; } </code></pre> Then a sockaddr</code> structure is initialized using in6addr_any</code>, which is a wildcard IPv6 address, letting the system select the address for you. struct sockaddr_in6 servaddr; bzero(&servaddr, sizeof(servaddr)); servaddr.sin6_family = AF_INET6; servaddr.sin6_addr = in6addr_any; servaddr.sin6_port = htons(atoi(argv[1])); </code></pre> Before continuing, we call bind()</code> to assign this address to the socket. if ((bind(listenfd, (struct sockaddr*) &servaddr, sizeof(servaddr))) < 0) { perror("bind"); return -1; } </code></pre> Then we convert the socket to a listening one, so that it can be used to accept incoming connections. if (listen(listenfd, BACKLOG) < 0) { perror("listen"); return -1; } </code></pre> Here we can finally make the server wait for client requests. The accept()</code> function is blocking and returns when a new incoming connection has been established. To generate a response from the server, we get the date and time with the time()</code> function, then build the string to send to the client, and finally write it to the socket and close the connection once finished. int connfd; int n; time_t ticks; char buff[MAXLINE]; while (true) { if ((connfd = accept(listenfd, (struct sockaddr*) NULL, NULL)) < 0) { perror("accept"); return 1; } // Send the time to the client ticks = time(NULL); snprintf(buff, sizeof(buff), "%.24s\r\n", ctime(&ticks)); while ((n = write(connfd, buff, strlen(buff))) < 0); // Close the connection close(connfd); } </code></pre> Get client information</a></h2> The first thing we can do to improve the server is to make better use of the accept()</code> function. By passing a sockaddr</code> structure address as an argument, we can retrieve some information about the client. struct sockaddr_in6 cliaddr; socklen_t clilen = sizeof(cliaddr); bzero(&cliaddr, clilen); accept(listenfd, (struct sockaddr *) &cliaddr, &clilen); </code></pre> Please note that the data memory layout is still following the network order, and if we want to have meaningful address and port values on our system, we need to convert them into the appropriate host representation. inet_ntop(AF_INET6, &cliaddr.sin6_addr, buff, INET6_ADDRSTRLEN); printf("Serving new client from %s:%d\n", buff, ntohs(cliaddr.sin6_port)); </code></pre> Get local address</a></h2> We have seen how the server can retrieve the address of a client. Let us see, on the other hand, how the host can query its own local address using getsockname()</code>. struct sockaddr_in6 cliaddr; socklen_t clilen = sizeof(cliaddr); bzero(&cliaddr, clilen); if (getsockname(sockfd, (struct sockaddr *) &cliaddr, &clilen) < 0) { perror("getsockname"); return -1; } </code></pre> Now we have the information we need in cliaddr</code>, then we convert the IPv6 address and port into the appropriate host representation and finally print it out. char clistr[INET6_ADDRSTRLEN]; inet_ntop(AF_INET6, &cliaddr.sin6_addr, clistr, INET6_ADDRSTRLEN); printf("The current address is %s:%d\n", clistr, ntohs(cliaddr.sin6_port)); </code></pre> Sending an acknowledgement</a></h2> We would like the client to respond to the server with an acknowledgement message, and this can be done after the reading step by calling write()</code>. char* ack = "Message received\n"; if ((n = write(sockfd, ack, strlen(ack))) < 0) { perror("write"); return -1; } </code></pre> On the other side of the connection, the server should invoke read()</code> to receive the data sent by the client. char recvline[MAXLINE + 1]; if ((n = read(connfd, recvline, MAXLINE)) > 0) { recvline[n] = 0; fputs(recvline, stdout); } if (n < 0) { perror("read"); return -1; } </code></pre> As you may notice, both read()</code> and write()</code> return the number of characters written into the socket buffer. In case of an error, the return value is negative (-1</code>) and the errno</code> global variable is set appropriately. This means we can retrieve an informative message corresponding to the current value of errno</code> through the perror()</code> function. Recursive echo server</a></h2> Let us now see two new functions useful for our network programs, exso_readln()</code> and exso_writen()</code>, based on some utility functions presented in the Unix Network Programming</a> book and used in a networking course</a> I attended at university. The exso_readln()</code> function reads a line (a string ending with the newline character '\n'</code>) from a socket buffer and automatically appends '\0'</code> to mark the end of that string.</li> The exso_writen()</code> function writes n</code> bytes into a socket buffer.</li> </ul> More details can be found here: libexso.c</a>. </blockquote> The daytime server discussed so far features an iterative behaviour, which means it can serve only one client at a time. In order to serve more clients concurrently, we could make it recursive by spawning child processes to manage new incoming connections. That is how it can be done with fork()</code>. pit_t childpid; if ((childpid = fork()) == 0) { close(listenfd); server_echo(connfd); return 0; } </code></pre> The child process must close the listening socket before executing its tasks. At the same time, the parent closes the connected socket and returns to waiting for new requests. Here follows the server_echo()</code> function, which executes all the tasks of a server child process, also using the new read and write functions mentioned above. void server_echo(int sockfd) { ssize_t n; char line[MAXLINE]; while (true) { if ((n = exso_readln(sockfd, line, MAXLINE)) == 0) { return; // connection closed by the other end } exso_writen(sockfd, line, n); } } </code></pre> Kill the zombies</a></h2> Good, now the server can handle multiple concurrent connections by spawning child processes. However, we should not forget to handle these processes when they finish serving clients, otherwise they will remain in memory as zombies. When a child process terminates, the operating system sends a SIGCHLD</code> signal to the parent, which by default does not do anything. If we want to remove zombies (dead child processes), the parent can do that by registering a callback function for the SIGCHLD</code> signal. if (signal(SIGCHLD, handle_zombies) < 0) { perror("signal"); return -1; } </code></pre> Here is how the callback function works. By calling the waitpid()</code> function with -1</code> as the first argument, the parent process waits for the termination of any of its children. The stat</code> output variable will contain information about a child's exit status. void handle_zombies(int signo) { pid_t pid; int stat; while ((pid = waitpid(-1, &stat, WNOHANG)) > 0) { printf("Child %d terminated with exit status %d\n", pid, stat); } } </code></pre> UDP echo client</a></h2> So far, we have been using TCP as the transport protocol. If we want to use UDP</a>, we need to make some minor changes. Change the socket type to SOCK_DGRAM</code>. int sockfd; if ((sockfd = socket(AF_INET6, SOCK_DGRAM, 0)) < 0) { perror("socket"); return -1; } </code></pre> Data transmissions should be done using the sendto()</code> function. char sendline[MAXLINE]; if (fgets(sendline, MAXLINE, fp) != NULL) { if (sendto(sockfd, sendline, strlen(sendline), 0, servaddr, sizeof(servaddr) < 0) { perror("sendto"); return -1; } } </code></pre> Incoming data is collected with the recvfrom()</code> function. Notice how, when working with a connectionless protocol, the address of the sender is collected; otherwise, we would not know who sent these packets. struct sockaddr *replyaddr; replyaddr = malloc(sizeof(servaddr)); len = sizeof(servaddr); char recvline[MAXLINE + 1]; if ((n = recvfrom(sockfd, recvline, MAXLINE, 0, replyaddr, &len)) < 0) { perror("recvfrom"); return -1; } recvline[n] = 0; </code></pre> Consequently, we should verify the identity of the peer. Here, we just make sure all the bytes of the sockaddr</code> structures are equal. char buff[INET6_ADDRSTRLEN]; struct sockaddr_in6 *sa; if ((len != sizeof(servaddr)) || memcmp(&servaddr, replyaddr, len) != 0) { sa = (struct sockaddr_in6 *) replyaddr; inet_ntop(AF_INET6, &sa->sin6_addr, buff, INET6_ADDRSTRLEN); printf("Ignoring reply from %s\n", buff); continue; } </code></pre> Distributed calculator</a></h2> Let us try something a bit more complex: a distributed calculator. The communication takes place via UDP, so we use sendto()</code> and recvfrom()</code> as introduced in the previous section. char buff[MAXLINE]; int a = 0; int b = 0; char op[OP_LEN] = "+"; while (fgets(buff, MAXLINE, stdin) != NULL) { if (sscanf(buff, "%d %s %d", &a, op, &b) == 3) { // ... do networking } } </code></pre> On the other end, the server receives the data, interprets it, computes the result, and sends it back to the client. char buff[MAXLINE]; socklen_t len; int a; int b; char op[OP_LEN]; while (true) { // Receive datagram len = clilen; if (recvfrom(sockfd, buff, MAXLINE, 0, cliaddr, &len) < 0) { perror("recvfrom"); return -1; } // Interpret data and compute the result if (sscanf(buff, "%d %s %d", &a, op, &b) == 3) { if (strcmp(op, "+") == 0) { sprintf(buff, "%d", a + b); } else if (strcmp(op, "-") == 0) { sprintf(buff, "%d", a - b); } else if (strcmp(op, "*") == 0) { sprintf(buff, "%d", a * b); } else if (strcmp(op, "/") == 0) { if (b != 0) { sprintf(buff, "%d", a / b); } else { sprintf(buff, "Undefined"); } } else if (strcmp(op, "mod") == 0) { sprintf(buff, "%d", a % b); } else { sprintf(buff, "Invalid operator"); } } else { sprintf(buff, "Invalid message"); } // Send result to the client if (sendto(sockfd, buff, strlen(buff), 0, cliaddr, len) < 0) { perror("sendto"); return -1; } } </code></pre> I/O multiplexing using select</a></h2> The simple echo client</a> described previously suffers from some robustness problems. For example, if the server closes the connection while the client is blocked waiting for user input, the client would not be aware of anything until it tries to send data again after the user input has been read. I/O multiplexing can help us solve this problem. By means of the select()</code> function, we can work with more than one descriptor, and that requires preparing an fd_set</code> object. In the example below, we reset readset</code> with FD_ZERO()</code> and then add our file descriptors through FD_SET()</code>. FILE *fp; int sockfd; // ... fd_set readset; FD_ZERO(&readset); FD_SET(fileno(fp), &readset); FD_SET(sockfd, &readset); int maxfd = MAX(fileno(fp), sockfd) + 1; if (select(maxfd, &readset, NULL, NULL, NULL) < 0) { perror("select"); return -1; } </code></pre> When select()</code> returns, we can check whether the descriptors are ready by making use of FD_ISSET()</code>. // Check if socket is ready to receive data from the server if (FD_ISSET(sockfd, &readset)) { if ((n = exso_readln(sockfd, recvline, MAXLINE)) < 0) { perror("exso_readln"); return -1; } if (n == 0) { printf("Server terminated prematurely\n"); return -1; } fputs(recvline, stdout); } // Check if file is ready to send its content to the server if (FD_ISSET(fileno(fp), &readset)) { if (fgets(sendline, MAXLINE, fp) == NULL) { return 0; } if (exso_writen(sockfd, sendline, strlen(sendline)) < 0) { perror("exso_writen"); return -1; } } </code></pre> Half closing the socket</a></h2> Another way to improve the robustness of the client code is by shutting down the write half of the connection once all reading operations from standard input have finished. This can be done by calling the shutdown()</code> function. char stdin_eof = 0; // ... if (FD_ISSET(fileno(fp), &readset)) { if (fgets(sendline, MAXLINE, fp) == NULL) { stdin_eof = 1; shutdown(sockfd, SHUT_WR); FD_CLR(fileno(fp), &readset); continue; } if (exso_writen(sockfd, sendline, strlen(sendline)) < 0) { perror("exso_writen"); return -1; } } </code></pre> Improved echo server</a></h2> A recursive server is not the best choice if we want to avoid a proliferation of child processes, given that we fork every time a new client is connected. The server, as well as the client, could benefit from I/O multiplexing via select()</code> to handle both the listening socket and the other connection sockets. if ((ready = select(maxfd + 1, &rset, NULL, NULL, NULL)) < 0) { perror("select"); return -1; } // Check for incoming connections if (FD_ISSET(listenfd, &rset)) { if ((connfd = accept(listenfd, (struct sockaddr *) &cliaddr, &clilen)) < 0) { perror("accept"); return -1; } // Save connected socket descriptor into an array for (i = 0; i < FD_SETSIZE; i++) { if (clients[i] < 0) { clients[i] = connfd; break; } } // ... } // Serve clients for (i = 0; i < FD_SETSIZE; i++) { if ((sockfd = clients[i]) < 0) { continue; } if (FD_ISSET(sockfd, &rset)) { if ((n = exso_readln(sockfd, buff, MAXLINE)) < 0) { perror("exso_readln"); } else if (n == 0) { printf("A client is gone\n"); close(sockfd); FD_CLR(sockfd, &allset); clients[i] = -1; } else if (exso_writen(sockfd, buff, n) < 0) { perror("exso_writen"); } // ... } } </code></pre> Broadcast</a></h2> What we have now is an array of all the connected clients, and that enables us to turn the server into a chat room! Here, the server broadcasts every message sent by a client to all the other connected clients: for (i = 0; i < FD_SETSIZE; i++) { if (sockfd == client[i] || client[i] == -1) { continue; } if (exso_writen(client[i], buff, n) < 0) { perror("exso_writen"); } } </code></pre> Nickname command</a></h2> After transforming the server into a chat room, it would definitely be a good idea to allow clients to set their nickname with a command. So, when a client is connected, the server expects to receive a message starting with /nickname</code> followed by the actual nickname. #define MAXNICK 32 // ... char nicknames[FD_SETSIZE][MAXNICK]; // Processing the i-th client if (nicknames[i][0] == 0) { if (strncmp(buff, "/nickname", 9) == 0) { sscanf(buff, "/nickname %s\n", nicknames[i]); sprintf(buff, "%s has joined the chat\n", nicknames[i]); } else { sprintf(buff, "Error, expecting /nickname\n"); exso_writen(client[i], buff, strlen(buff)); continue; } } </code></pre> Once the nickname is set, we can use it as a prefix for the message and broadcast it to everyone. char temp[MAXLINE]; sprintf(temp, "%s: %s", nicknames[i], buff); sprintf(buff, "%s", temp); // ... for (i = 0; i < FD_SETSIZE; i++) { if (sockfd == client[i] || client[i] == -1) { continue; } if (exso_writen(client[i], buff, strlen(buff)) < 0) { perror("exso_writen"); } } </code></pre> To conclude, when a client logs out, we can reset their nickname. // If there are no more characters to read if (n == 0) { close(sockfd); FD_CLR(sockfd, &allset); client[i] = -1; bzero(nicknames[i], MAXNICK); } </code></pre> Android notes Antonio Caggiano — Tue, 27 Oct 2015 00:00:00 +0000 This is a collection of notes I took during the Mobile Programming course at my university. Project</a></h2> The project needs to follow a specific structure to be compiled and packaged correctly by the Android Software Development Kit</a>. At a higher level, we subdivide it into modules, such as: Android application modules: with code, resources, and configurations. These will be transformed into an apk file that will be installed on devices.</li> test modules: containing JUnit</a> tests.</li> library modules: which are code shared with other projects. These will be included in the apk as well.</li> </ul> Files</a></h3> build/</code>: application build artifacts.</li> libs/</code>: private libraries.</li> src/</code>: the source code. androidTest/</code>: Java tests.</li> main/java/com.project.app</code>: Java code such as activities.</li> main/assets/</code>: store for game assets.</li> main/res/</code>: various resources. anim/</code>: XML files compiled into animation objects.</li> color/</code>: XML files with colors.</li> drawable/</code>: bitmap files (PNG, JPEG, GIF), 9-Patch, and XML describing drawables.</li> mipmap/</code>: Application icons.</li> layout/</code>: XML files compiled into layouts.</li> menu/</code>: XML files defining menus.</li> raw/</code>: for various assets, like mp3 or ogg files.</li> values/</code>: XML files defining generic values.</li> xml/</code>: other XML files.</li> </ul> </li> AndroidManifest.xml</code>: main file describing the application and all of its components.</li> </ul> </li> .gitignore/</code>: files to be ignored from git</a> versioning.</li> app.iml/</code>: IntelliJ IDEA config file.</li> build.gradle</code>: build config file.</li> proguard-rules.pro</code>: ProGuard</a> config file.</li> </ul> Localization</a></h2> When the user launches an app, Android automatically selects and loads the right resources according to the device configuration. In the res/values/strings.xml</code> file, strings are stored that are used by default, though it is possible to specify alternative resources using qualifiers for different languages. For instance, to localize</a> text content in Italian, we need to create an alternative strings.xml</code> file under the res/values-it/</code> folder. Testing</a></h2> It is possible to test our apps on an emulator or a real Android device. The number of smartphones on the market is huge and continuously growing. Nevertheless, every device is different and deciding which ones to test can be challenging. It would be ideal to support as many devices as possible. We could buy a certain number of devices and test our app under real conditions, but it would definitely be more expensive than using the emulator. The emulator might not allow us to see how apps work on real devices, but it does not hurt from a financial perspective. When developing on a device, it is still good practice to use the emulator to test our apps on configurations that are different from those of real devices available to us. Even though the emulator cannot test all settings, it can verify that the apps work correctly on different Android versions, or screen sizes and orientations. A mix of real device testing and emulator testing could guarantee good test coverage at a reasonable price. Layout</a></h2> A layout is the visual structure of a user interface and it can be defined in two ways: XML: Android provides XML tags corresponding to classes of the View</a>.</li> Runtime: you can create View</a> and ViewGroup</a> objects programmatically.</li> </ul> We can use one or both methods to declare and manage the graphical interface of our application. For example, we could declare some layout in XML, and later add code to modify at runtime the state of the elements on the screen. The benefit of using XML files is the separation between presentation and the code controlling the behaviour of the application. The description of the user interface is external to the logic code, enabling us to modify it without needing to recompile. Moreover, declaring the layout in XML makes it easier to visualize the structure of the user interface and simplifies debugging. View</a></h3> A View is basically a rectangle with width and height, and a position expressed as left and top. The unit is the pixel. We can also distinguish two pairs of width and height: measured width and height relative to its parent, and drawing width and height, which define the size when drawing on screen. Drawing a layout involves two steps: measure and layout. The measure step is implemented in measure(int, int)</code></a>, which is a top-down traversal of the view-tree where their dimensions are calculated. The second step is implemented in layout(int, int, int, int)</code></a>, also top-down, where every parent is responsible for moving their children using values calculated during the measure step. ViewGroup</a></h2> Linear Layout</a></h3> A linear layout is a ViewGroup which aligns its children horizontally or vertically (android:orientation</code>). Relative Layout</a></h3> A relative layout is a ViewGroup which shows children with relative positions to their siblings (left-of, below, …) or parent (bottom, left, center, …). List View</a></h2> A list view is a ViewGroup showing a list of elements. The elements are added automatically using an Adapter</a>, which takes the content of a source, like an array or a database, and converts each element into a View to be inserted into the list. Grid View</a></h3> A grid view is a ViewGroup which shows a grid of elements which, like the list view, is populated through an Adapter. Adapter View</a></h3> When the content is dynamic, we can use an AdapterView</a> subclass to populate it at runtime. An AdapterView subclass uses an Adapter, which behaves like a mediator between the data source and the layout. The Adapter receives data and converts each entry into a View that can be added to the layout. Android provides some Adapter subclasses for certain cases: ArrayAdapter: useful when the data source is an array. By default, it creates a View for every element of the array by calling toString()</code> and putting it into a TextView</a>.</li> </ul> ArrayAdapter<String> adapter = new ArrayAdapter<>( this, android.R.layout.simple_list_item1, myStringArray); ListView listView = (ListView) findViewById(R.id.listview); listView.setAdapter(adapter); </code></pre> SimpleCursorAdapter: useful when data come from a Cursor</a>.</li> </ul> Toast</a></h2> A Toast provides simple feedback for an operation in a small popup. It occupies only the space required by the message and the current Activity remains visible and interactive. Toasts vanish automatically after a timeout. We can create them with the static method Toast.makeText()</code></a>, which takes three arguments (context, message, and duration), and can be shown with the show()</code> method. Toast.makeText(context, "text", Toast.LENGTH_SHORT) </code></pre> We can position it with the setGravity()</code></a> method, which accepts three arguments (gravity constant, x offset, and y offset). toast.setGravity(Gravity.TOP | Gravity.LEFT, 0, 0); </code></pre> It is also possible to create a custom layout for toasts in XML and use it by passing it to the toast through the setView(View)</code> method. Western Lion: Post mortem Antonio Caggiano — Thu, 22 Oct 2015 00:00:00 +0000 Western Lion is a collection of two minigames based on the spaghetti western theme, developed during the one-month Spaghetti Western Jam</a> organized by IndieVault.it</a>. In one of the games, you impersonate Nobody, trying to shoot mugs before they shatter on the pavement, while in the other game you are Jack, annoyed by a fly while waiting at the train station. Preparation</a></h2> The idea of minigames originated from the fragmentary way scenes from spaghetti western movies I have seen over the years came back to my mind. Figuring out how to realize that idea was the next step. The libGDX</a> framework was definitely a good choice from both a prototyping speed and portability perspective. Talking about graphics, I reduced it to the lowest terms, as it was easier working with an 8-bit palette borrowed from the wonderful PICO-8</a> fantasy console, and a resolution of 160x90 pixels. Audio resources were simply collected by searching on Freesound.org</a>. Jack and the Fly</a></h2> The first mini-game is Jack and the fly. It is inspired by the concept of waiting, which has a prominent role in the beginning of Sergio Leone's Once Upon a Time in the West</a>. Waiting makes us think; it gives us time to breathe, to meditate, to observe. This emphasis projects us onto those boundless spaces and, at the same time, allows us to get lost in the tiny details. Nobody is drinking</a></h2> The second mini-game is Nobody is drinking. It is based on a scene from Tonino Valerii's My Name Is Nobody</a>. Nobody, the main character of the movie, bets on a particular game where you drink whiskey from a mug, then throw the mug into the air, and try to shoot it before it shatters into pieces on the ground. With both games, the key to winning is being alert and quick. Indeed, when you finish a game, your time is recorded onto a leaderboard. Development</a></h2> Here is the list of tools I used to develop Western Lion: Android Studio</a>, for coding;</li> The GNU Image Manipulation Program</a> to create graphic content;</li> Audacity</a> to edit audio resources.</li> </ul> Although the right tools greatly simplify the development of projects like this, a good understanding of mathematics and physics is fundamental to realizing the ideas that come to your mind. A two-dimensional Cartesian coordinate system helps position pictures in the right place on the screen;</li> The laws of motion allow you to simulate the movement of objects, like the fly and the mugs.</li> Trigonometric functions can be used to make cool, smooth animations like the sliding in the achievements screen.</li> </ul> These are only some examples of the countless applications that mathematics has in the world of game development. </iframe> </div> </div>

Hardware Accelerated Raytracing</a></h2>
They are incredibly fast, orders of magnitude faster than the normal processor we have in our computers. So, with the latest generation smartphones, we can do amazing things.</p>
Let me make this cameo: 'What a Time To Be Alive'!</p>

Rust+Wasm+WebGL: Create interesting interactive 3D content for the web

Panfrost performance counters with Perfetto

An exercise with boost::asio

Vulkan Samples: Subpasses

Vulkan Samples: Appropriate use of render pass attachments

Computer network notes

Spread Spectrum</a></h2>
In Spread Spectrum</a> techniques, signals of various sources are combined to prevent detection and interference. Those techniques are based on redundancy</strong>, increasing the width of the original bandwidth.</p>

Router</a></h3>
A router</a> operates on the network layer sending packets based on logic addresses. They are commonly used to connect LANs or WANs to the Internet.</p>

Gateway</a></h3>
A gateway</a> is able to read and interpret messages from applications, therefore it could be used to connect two networks based on different models.</p>

Devember: Socket API

Android notes

Western Lion: Post mortem

multidimensional code

VCL: a new open source VirtIO-GPU OpenCL driver leveraging hardware acceleration

Computer Graphics: Follow The Light

Venus on QEMU: Enabling the new virtual Vukan driver

Profiling virtualized GPU acceleration with Perfetto

NcJump devlogs