Chapter 19 // Exercise 12 - Principles & Practice Using C++

In this exercise I am using Visual Studio 2017 and a modified version of the std_lib_facilities header found here.

Chapter 19 // Exercise 12

Define a File_handle class with a constructor that takes a string argument (the file name), opens the file in the constructor, and closes it in the destructor.

Github: https://github.com/l-paz91/principles-practice/tree/master/Chapter%2019/Exercise%2012

I'm not sure if he wanted us to use ofstream or ifstream or even the c-style FILE. Or if he wanted us to open a file that already exists or open a new file, or use FILE to guess? I decided to go with the simple option of a file to open that already exists seeing as how FILE has not been introduced.

Chapter 19 // Exercise 11 - Principles & Practice Using C++

In this exercise I am using Visual Studio 2017 and a modified version of the std_lib_facilities header found here.

Chapter 19 // Exercise 11

Design and implement a counted_ptr<T> that is a type that holds a pointer to an object of type T and a pointer to a "use count" (an int) shared by all counted pointers to the same object of type T. The use count should hold the number of counted pointers pointing to a given T. 

Let the counted_ptr's constructor allocate a T object and use a count on the free store. Let counted_ptr's constructor take an argument to be used as the initial value of the T elements. When the last counted_ptr for a T is destroyed, counted_ptr's destructor should delete the T.

Give the counted_ptr operations that allow us to use it as a pointer. This is an example of a "smart pointer" used to ensure that an object doesn't get destroyed until after its last user has stopped using it. Write a set of test cases for counted_ptr using it as an argument in calls, container elements, etc.

Github: https://github.com/l-paz91/principles-practice/blob/master/Chapter%2019/Exercise%2011

So I think this is basically a shared pointer and it took me a moment to wrap my head around what to do. The main key things are to ensure we're not allocating when copying (or increasing if the pointers are pointing at the same thing) as well as only delete the object and counter once all the other shared pointers have gone out of scope.

C++ & FLTK // Adding Simple "Sprite" Support

This isn't really a tutorial, more of a "hey, I wanted to add 'sprites' to my FLTK build, how would I do that?"

For those of you new to my blog, I've been working my way through Bjarne Stroustrup's Practice & Principles using C++ in which there are several chapters focused on graphics programming. For this he supplies a couple of helper files that wrap some fltk features in a "higher level bow" so to speak. Over the months I've been editing these quite a bit to create my own shapes and add other functionality.

After these graphics chapters ended, I started to wonder if I could make a 2d engine using fltk and what does every good 2d engine need? Sprite support.

After an hour of tinkering, I had achieved this:

Very exciting. I'd like to note, this did not capture well and it kind of looks like there's a slight stall after a few frames but when running the program it's fine.

So I first went about this by creating a new simple window that supports "ticking". It has a quit button and a tick function that's registered with fltk's callback system to run every 0.1 seconds.

Then I made a new class called Sprite which inherits from the Shape class. I soon learnt that Shape is great for basic stuff, but when you want to start doing event based game stuff, the way shapes are drawn and updated is kind of clunky so I need to re-do shapes. But for now I worked round it.

So a Sprite takes in a point to draw from the top left-hand corner, a file name, frame width, frame height and the number of rows in the spritesheet; kind of reaching for the moment as it can't deal with sprites with multiple rows just yet.

The Sprite itself is just an Fl_Image that holds the png "spritesheet". This was mine:

It's the coin blocks from Super Mario World. When attaching this image to the window, obviously the entire image was displayed. Sprites should be able to only display a certain portion or 'frame' of their spritesheet, so I made a function called drawFrame() that takes in a frame number. This frame number is stored and used in draw_lines() to display a particular part of the image. This is the annoying part of using a Shape; I must override draw_lines() and use that to draw. 

To only display a certain part of the image, you can just use built-in functionality of Fl_Image. The draw() function allows you to specify a part of the image to draw by passing in the top left corner locations and an offset. This essentially "crops" the image to the size given. The width and height is then multiplied by the frame number each frame to advance it to the next image:

Here, my spritesheet is 200x400 pixels with each block being 40x40. Therefore, to play an animation, fltk is told to start at frame 0 and increase by 1 each frame until it hits 3, then go back to 0. This stops it from showing the brown block, which is frame number 4.

So to show the second image block, it would do 40 * 1, which is 40. This gives an x offset of 40. Then the x and y coordinates of the new cropped image are obtained by getting the top left of the full sprite sheet (I set it to 50, 50) then adding on the offset; making the new draw point 90, 50. The draw() function is handy though as it can display the cropped image in the same position as the last through the first two parameters. The Y offset is ignored right now as we don't have multiple rows.

It's also important that post increment is used here. I usually detest using post++, however here it is necessary as the current frame needs to be drawn before it's incremented. If it was ++frame, then the next frame would be drawn as it's incremented before use.

And that's pretty much it for creating the most basic of basic sprite systems for FLTK. I have plans to rewrite the shape class so I have full control over how they're drawn.

You can find the full code for this project here along with a project file:

https://github.com/l-paz91/FLTK-Projects/tree/main/SimpleSpriteClass

Ray Tracing in One Weekend Review

I've now finished this web book; admittedly it took me a little longer than 1 weekend due to chores and other things getting in the way but it's definitely doable in one weekend.

It basically teaches you how to brute force your way to creating a ray tracer using C++ and a lot of scary looking maths equations. With that said, it's basically an exercise in copying code correctly as there isn't much interaction with the concepts taught. That is left up to you at the end of the book.

Instead you will go through creating materials, cameras and various methods like calculating reflections that can be used in whatever your mind cooks up. You will have this scene by the end of it though:

That is the final image size for me; it's 400x225 with a paltry 100 samples per pixels and it took a whopping 27 minutes to render. This is where you can do some self-learning and improve the code. I've already tasked myself with parallelising the pixel calculations as currently the program only uses 1 core and 1 thread to do all the work.  I have an i7-4790k which has 4 cores (and therefore 8 threads). I could use the standard C++ library to spin up as many threads as possible across all cores and get the render done much faster.

I have very little experience with multi-threading so this seems like a nice way to ease myself into the subject. After that, I'd like to create some more material types and perhaps even make the render interactive by being able to move the camera? I would have to turn the the samples per pixel down to about 15 but I think it would be doable. I think this would be similar to how Blender displays objects when you switch to the cycles renderer.

I think if you are an absolute beginner into graphics or general programming this will go over your head. The author doesn't even mention how you create the image and assumes that you know to call a certain command in command line. For reference you navigate to the folder the exe is stored in and type: RayTracing.exe > image.ppm

This will redirect cout to the supplied format instead. I found the PPM to be a bit bulky as it's all text but allows you to spot bad pixels easily (useful when attempting to multi-thread). PhotoShop opens it fine but I had difficulty finding another program to open that format as the IrfanViewer website was blocked by my anti-virus.

All in all; worth a weekend or two of your time if you're interested in rendering, graphics and ray tracing. There are two other books to complete after this as well that go into more depth on the topic.

https://raytracing.github.io/

Chapter 19 // Exercise 10 - Principles & Practice Using C++

In this exercise I am using Visual Studio 2017 and a modified version of the std_lib_facilities header found here.

Chapter 19 // Exercise 10

Implement a simple unique_ptr supporting only a constructor, destructor, ->, *, and release(). In particular, don't try to implement an assignment or copy constructor.

Github: https://github.com/l-paz91/principles-practice/blob/master/Chapter%2019/Exercise%2010

I left the crtDetectMemoryLeaks function in this one and it works for new and delete as well! Happy days. Glad I did as my first run leaked memory. I had forgotten which way round to delete in the destructor. I used to see a lot of code that would do:

delete object;

object = nullptr;

I messed it up and of course that memory was lost because I didn't stop to think. I did google to find out if it's standard practice to delete and null and the consensus is; not really as it may cover up double delete bugs. We've had problems with double deletes at work so I don't want to contribute to covering up those as they are nasty to solve.