Using the TIC-80 fantasy console simulator on your pi, implement a program that visually displays a graph of the timed results of your various prime algorithms (brute force, brute force + optimizations, Sieve of Eratosthenes) so that one can more clearly see the difference in performance each algorithm offers.

The graph you should produce can be a simple line graph, perhaps a unique color for each algorithm+optimization, with at least 8 different ranges that you run EACH combination through to obtain the time and a plot with that result on your graph.

So: the vertical axis would be time, and the horizontal axis would be the upper bound (getting progressively larger the further you travel to the right).

Additionally, the entire class will be participating in documenting and filling out this project page. It is the responsibility of EACH class member to:

• ask copious, clarifying questions (so you can better add content)
• craft a coherent and organized document, with information located under pertinent headings
• explain the fundamentals of the process, conceptual background, algorithmic approach, and you can even suggest particulars related to TIC-80 (certain functions that might prove useful- individual, unrelated snippets to do things like capturing time or displaying text, etc.)
• to get full credit, each individual that submits must perform no fewer than 4 changes to this document (as viewable from the wiki revision system). Failure to do so will result in documentation penalties being applied.

Since this program is more about comparing times than finding primes, old display methods are out the window; we want to display a graph, not a list of numbers. In doing so, the resulting screen should more or less use its rectangular area to display a Cartesian mapping of upper bound (since the lower bound may always be 2, or some other constant for simplicity) to the time taken for each of the 7 (or 9, including optimization redundancies) calculation methods.

A tried and true method of accomplishing this is the common line, which, by changing its color, may be readily used to represent each of those calculation methods' performance. As the times (and potentially bounds, if desired) may vary on an execution by execution basis, however, a problem is encountered: how is it assured that all of the data is presented to the user? If the scale of the graph is constant, sometimes points may attempt to appear beyond its bounds, or, less catastrophically, detail may be surrendered for graphs that do not take advantage of their maximum bounds. That introduces a new (and useful) concept into this program: dynamic scaling.

Dynamic scaling, as it reads, is variability in size based upon some factor. In our case, that factor is the maximum time taken, as well as the maximum bound calculated. From this information, we can derive two scaling factors: one for the x dimension, and one for the y. To determine what these values are, though, the size of the graph must first be decided on, and for this example, the maximum dimensions of the TIC80 screen will be used. By dividing the maximum desired pixel dimensions of the desired graph by the maximum potential values for the point coordinates, you obtain a number which, when multiplied by the time taken or bound calculated of a given data point, results in that datapoint scaled up or down to the size of the screen.

// Calculate scalers
xScaler = 240 / maximumBound;
yScaler = 136 / maximumTime;

// Now multiply the point coordinates by the scalers.
// This way, if the point coordinates are larger than the resolution, they 
// will be shrunk. Likewise, if the graph would only take up a fraction
// of the screen, the points will be scaled up.
point.x = point.x * xScaler;
point.y = point.y * yScaler;

For the displaying of time, since we will be measuring and graphing multiple instances, it may prove useful to store the largest value in a variable and use it to calculate your bound(s) for the time axis. You could also do so statically, which would be more consistent, but has the potential to be less rewarding.

While you may be able to scale and display data appropriately, displaying data upwards or downwards is a different story. Given how TIC-80 has its origin starting from the top left, one must manipulate the calculated points (from the scalers) in order to display downwards.

In order for the bottom left to be treated as the origin (as we expect in a normal graph), the pointers must be subtracted from their respective maximum-possible value from the scaler.

If we were to assume 50 is the maximum possible x-value, then we do “xScaler-point.x” in order to display upwards. A downward-leaning graph may be suitable if displayed in a detailed fashion, however it may not be ideal when wanting many different people to understand the data.

https://en.wikipedia.org/wiki/Cartesian_coordinate_system

https://hub.xpub.nl/sandbot/PrototypingTimes/tic80-manual.html

https://github.com/nesbox/TIC-80/wiki

https://www.lua.org/pil/contents.html

In order to submit the game file, our “tic” file, the file must be added to your lab46 somehow. This can be achieved through FTP software, such as FileZilla, or more easily by putting the file onto your Pi then pushing to your repo and pulling from lab46.

Of course, if you are using the TIC-80 application on your Pi then the file will exist there when saved.

To submit this project using the submit tool, run the following command at your lab46 prompt:

lab46:~/src/SEMESTER/DESIG/pnfX$ submit DESIG pnfX GAMENAME.tic
Submitting DESIG project "pnfX":
    -> GAMENAME.tic(OK)

SUCCESSFULLY SUBMITTED

NOTE: “GAMENAME” here is the name of your game. Please do not literally submit a tic file named “GAMENAME”, come up with a creative name for your game.

I'll be looking for the following:

78:pnf3:final tally of results (78/78)
*:pnf3:no errors, program runs without issue in TIC-80 [13/13]
*:pnf3:user can specify lower and upper bounds at runtime [13/13]
*:pnf3:specified algorithms are implemented and functional [26/26]
*:pnf3:timing of process is implemented, functional, shown [13/13]
*:pnf3:project page contributions as per project specifications [13/13]

Additionally:

• Solutions not abiding by SPIRIT of project will be subject to a 25% overall deduction
• Solutions not utilizing descriptive why and how COMMENTS will be subject to a 25% overall deduction
• Solutions not utilizing INDENTATION to promote scope and clarity will be subject to a 25% overall deduction
• Solutions lacking ORGANIZATION and are not easy to read (within 90 char width) are subject to a 25% overall deduction