Now that we've got a way to plot pixels and write frames to disk as ppm files, let's turn our attention to calculating the positions of each star.

The particular way that we decide to simulate something from the real world in a mathematical sense is known as a model. A complex model will create a more accurate simulation, but will also likely be several orders of magnitude more complicated to program, and use more computing resources when run. We need to choose an appropriate level of complexity for the requirements of the task in hand.

The simplest model would be to set the initial co-ordinates of each star randomly, and then move them closer to the edge of the screen at a constant speed. Not surprisingly, this looks fairly awful, but it is quite trivial to program.

The memory for the structure will be allocated in the main program before calling this function, so we don't need to do it here. Note that the data elements for each star will be stored together in memory. This doesn't matter at all here, as the dataset is tiny, and we will be processing the data for each star in turn anyway. However, when dealing with large datasets, it makes sense to consider the likely access patterns to the data, and organise it in such a way that data items which are likely to be accessed together are stored in adjacent memory locations.

If we were processing data for a million stars, possibly with more information than simple co-ordinates, we might want to process or iterate over all of the stored values for one particular data item to find an average, upper and lower bound, or do some other sort of calculation. In these cases, performance can often be increased by storing the values of each data item for each star sequentially in memory. So in our simple example, we could store all of the X co-ordinates in one array, and all of the Y co-ordinates in another.

Our new main function just needs to allocate storage for the star data, initialize it by calling init_stars, and then loop around repeatedly clearing the framebuffer, plotting the pixels that correspond to the current star positions, updating those positions, and writing the completed frame as a sequentially numbered ppm file.

First we define some new integer variables; vx and vy will be used to store the motion vectors for each star processed, i is a general purpose counter, and current_frame holds the sequential number of the animation frame that we are currently working on, which we need to create the output filename. We also define three pointers, filename will obviously be used to build the output filename for the current frame, framebuffer is the same as before, and we also have a pointer to an instance of the starinfo structure we defined earlier, to hold the sets of co-ordinates.

We allocate sufficient memory space for STARS_TOTAL entries, again using malloc with a multiplication which is perfectly safe as the values are known to be within acceptable limits in our use case.

Next, we call init_stars to set up our initial random co-ordinates, then begin the main loop. This is where things finally get more interesting, as the following code is where we actually implement the model of the star movement.

First, we set the framebuffer to black with a call to framebuffer_clear, and enter another loop that iterates over the co-ordinates for each star. We immediately plot the co-ordinates we read as a single white pixel, RGB values 255, 255, 255, then calculate the X velocity vector, in other words, how quickly this star is moving ‘horizontally’. We do this by subtracting the X co-ordinate from half of the width of the framebuffer, in other words, the middle horizontally. Further from the middle, the star is ‘closer’ to us, and so moves more quickly. Since typical values for a 1920 × 1080 framebuffer might be in the low hundreds, either positive or negative, we divide this value by 32, to avoid the star movements being too rapid and jerky. 32 is an arbitrary number, although as we are dealing with integer arithmetic here, it makes sense to choose a number which is a power of 2, that is, a round number in binary.

We subtract this value from the current X co-ordinate, which obviously turns into an addition for stars on the right hand side of the screen, as the vx number itself would be negative. At this point, we have our new X co-ordinate, ready to draw on the next animation frame.

We repeat the whole process for the Y value, and then do a quick check to see if the new position still lies within the co-ordinate range of the framebuffer. If it does, everything is fine. If the new co-ordinate lies outside the bounds of the framebuffer, then the star has moved off-screen, and we simply reposition it at a random location just as we did for all of the stars in init_stars.

Note that we don't have to ensure that the new random co-ordinates fall near the centre of the screen for a good visual effect. Although all of our stars are currently going to be plotted as the same brightness, in reality stars vary in brightness, and it seems logical that some might not come into view until they are closer to us. So an entirely random placement should work just fine.

After this we end the stars loop, and write an appropriate filename into the buffer filename using asprintf, which will allocate memory for us automatically. We then call output_ppm to write the ppm file to disk, and loop for the remaining frames after freeing the filename buffer that asprintf allocated.

Well, the code compiles and runs. It does indeed produce a vaguely recognisable starfield simulation. So far, so good.

But there is obviously a lot of room for improvement.

To start with, the stars being a single white pixel makes them quite difficult to see if your monitor doesn't have good contrast or you're in a bright room. This can easily be overcome by plotting a square of four white pixels.

Re-compiling and re-running the code, the stars are definitely more distinct. However, look more carefully at the generated display. There are other problems apparent.

If we run the code repeatedly, each invocation will give us a different starfield, as we're using non-deterministic random numbers. This is a good thing during testing, as the erroneous effects are more pronouned with some initial co-ordinate values than with others.

Since we're using integer arithmetic, values of vx less than 32 will evaluate to zero. The star won't move at all, and so vx will also evaluate to zero on the next frame, and so on. The star will remain fixed in place forever.

Most of the output is fine, but near the middle the star trails are obviously ragged.

This is another integer rounding artifact. A star at the very centre, with co-ordinates 960, 540, will start by moving a single pixel, and will do this for 32 frames. For the next 16 frames, it will move two pixels, followed by 11 frames of three pixels, 8 frames of four pixels, and so on. The numbers involved might seem too small to make a visible difference, but clearly they do. You can even see the problem with the call to framebuffer_clear in place, if you look carefully. Every so often, the starts appear to be shifting into a higher gear, and jump forward.

We've arrived at a passable, although admittedly very basic, implementation of a starfield simulator fairly quickly. Excluding comments, it's only about 80 lines of C, and it compiles to an executable of about 10 kilobytes.