Network Draw Application

I have really enjoyed this task a lot.

At the very end of week 1, we started talking about networking in class. It was all new stuff to me, so I found it extremely interesting. I have been interested in getting started with this stuff for a little. I did dip my toes into it back in Make-a-Thing last year, but I had some help from Pat.

The task we were given was to create a drawing application that would connect to a server (provided) and would allow multiple people to all draw together. We are able to send circles, squares, lines and single pixels to the server. I mainly focused on pixels as I wanted players to have that freehand drawing functionality.

I grabbed SFML 2.3 and linked it with a new project (I’m getting pretty good at this…) and got started. Then I got started. One of my goals for this project was to try and keep my project tidy and code in relevant files. I feel like I have achieved that well as all my networking code has gone into it own file, UI stuff into another etc. You can view the files on github.

My original idea for sending packets would be I have two arrays the size of SCREENSIZE * SCREENSIZE. Each one would represent a single pixel. Then, every interval, I would check the difference between them and send the pixel packets. I thought that would work well and I implemented it…overlooking a crucial thing. You can never draw over pixels. So…that was a problem. Also, it was difficult to send multiple pixels at once without being in-efficient.

After learning that it was possible to send multiple pixels in a single packet (and advised due to the overhead of each packet being so large for such a small amount of data), I changed the system. Instead, I created an array that would hold all the pixels to send each interval and when it was time to send the pixel packets, I would send the array instead, making that I would need to send way less packets, and also i’m not sending tiny amounts each time. This was much more efficient and I found on average I was sending 10x less packets.

I also worked on a few UI elements. So I created Buttons, Text Input Fields and Sliders. I thought that it would be worth investing time into these as I can use them in the future. The one I had most difficulty with was the text input field. The reason being was I didn’t understand how strings worked well enough. There was also an issue here with unicodes. Eventually, I realised strings are just an array of characters, and I worked through with the unicode characters. After much tinkering, I finally got a field where when you click on it, you can change the text, add more text and if you click out or press enter, it no longer has focus. I ended up using that so the user can type the IP and Port then having a connect button. The sliders were used for RBG.

The final task was to make a heatmap. I decided to map the user’s mouse position rather than when they click. To do this, I had a heatmap class that had an array to keep track of previous mouse positions. Similarly to the sending of packets, ever x interval, I would loop through the array and modify the image. I ran into a silly problem with this. It wasn’t drawing the pixels correctly and it was creating lots of images really fast. What was happening was the image was being saved and opened too fast, causing issues. This happened because I forgot to reset the interval. It was a really silly mistake and I laughed when I found it.

In the end, I was really happy with my draw client. I am really looking forward to doing so much more with it. There is a part two to this task that got completed over the next week. My understanding of networking is a lot stronger, and I believe this is an area in programming that I would like to focus on, alongside tools.

Link to github:


Making a Raytracer Multi-Threaded

Recently we were given an un-optimized raytracer so we could work on making it multi-Threaded and some optimization techniques. During my time working with this project, I spent a lot of time trying to understand what multithreading is and how it works.

During the classes I asked lot of questions to help further my understanding. I feel like I have a good grasp of the concept now, allowing me to implement it into the raytracer and actually understand what is happening.

I used openmp for multithreading for the project. When I first got the project, it took ~64 seconds to render. By the end, I got it down to ~11. I would like to continue further with this in the future, but at the moment, I am focusing on other projects.

One problem I ran into while working was that you had to enable openmp. I was implementing it without seeing any effects. This signalled a red flag to me, so I researched it a bit and found out that you had to enable it within visual studios. Once that was done, the program was running much much faster.

What I did was use openmp to determine how many processors the computer had and based everything off that. To do that, it was one simple function:

unsigned int nProcessors = omp_get_max_threads();

Once that was complete, I was able to tell openmp to create threads equal to 4 times the amount of cores the computer had. I did that with:

omp_set_num_threads(nProcessors * 4);

I came to the number of threads by trial. I found that it was much faster to have double the amount of processors rather than the same amount. Then I kept increasing it, with it peaking at around 4 times the amount. Anything more and it was slowing down due to the excess time required to keep swapping threads.

The next process was the utilise multithreading. To do so, at loops where the program can run in parallel, I used:

#pragma omp parallel for

This broke the for loop down and assigned work to each different thread. An example of that is if there was a for loop like so:

for(int i = 0; i < 100; i++)

and there is four threads, it will assign the work load equally. The first thread will compute from 0 -24, the second thread will do 25-49 and so on. Then they can all run parallel making the program run much faster. At this point, the program was running at ~16 seconds.

In the way of optimisation, I didn’t really do too much. The main thing I did was think about how shadows were handled. I realised that when doing intersections to determine where the shadows were, if it intersected with one thing, then we knew we would have to cast shadows. Therefore, rather than loop through all the rest of the checks, I just returned form the function. Upon comparison of the old and new versions of the rendered images, there were no differences.

Overall, I feel like with this project, I have achieved a much better understanding of how threads work. I managed to do a little optimization appart from the threads and got it to render in ~11 seconds rather than the original ~64 seconds.

Link to raytacer: