School of Computer Science: Assessment Brief
Module title Computer Graphics
Module code COMP3811
Assignment title Coursework 1
Assignment type
and description Programming assignment: Graphics fundamentals
Rationale
The coursework revolves around fundamental graphics operations and data types. These include images and the
manipulation thereof, drawing primitives such as lines and
triangles, and blitting images.
Word limit and guidance
Report: Each task on exactly one separate page,
so exactly 13 A4 pages with 2cm or larger margins, 10pt
font size (including figures). Code: no limit. Please read
the submission instructions carefully!
Use of GenAI in this
assessment
AMBER: AI tools can be used in an assistive role You
are permitted to use AI tools for specific defined processes
within the assessment. See below for further details.
Weighting 50%
Submission deadline 2025-11-07 15:00
Submission method Gradescope: code and report
Feedback provision Written nodes (Minerva)
Learning outcomes
assessed
Understanding, description and utilization of standard
methods to programmatically create and manipulate images. Understanding, description, application and evaluation of fundamental algorithms and methods in computer
graphics.
Module lead Markus Billeter
i
1. Assignment guidance
In the first coursework, you are tasked with implementing several drawing
functions for primitive graphics operations. These include drawing lines,
triangles and blitting images. You will verify that these functions work
correctly and analyze their behaviour.
Before starting your work, please study the coursework document in its
entirety. Pay special attention to the requirements and submission information. Plan your work. It is better to focus on a subset of tasks and
commit to these fully than to attempt everything in a superficial way.
2. Use of GenAI
You can use LLMs/GenAI for research, e.g., by asking questions (verify
the answers!). However, you must write all code yourself. GenAI may
provide examples for you, but you cannot copy-paste them directly into
your code. Simple auto-complete is exempt from this rule (but the autocomplete must not be more than at most one non-compound statement at
a time). However, all code comments must be written by you and cannot
be provided by GenAI. You may also not use GenAI in your report.
3. Assessment tasks
Please see detailed instructions in the document following the standardized assessment brief (pages i-vi). The work is split into several tasks,
accounting for 50% of the total module grade.
4. General guidance and study support
Please refer to materials handed out during the module, specifically the
tutorial-style exercises for 2D graphics and maths.
Support for the coursework is provided during scheduled lab hours in the
labs. Lab assistants will direct you towards a solution - they will not solve
problems for you. For administrative enquiries, please contact the module
leader by email. Do not under any circumstances cross-post questions on
multiple channels.
5. Assessment criteria and marking process
Submissions take place through Gradescope. Valid submissions will be
marked based on the report and submitted code. See following sections
for details on submission requirements and on requirements on the report.
ii
Marks and feedback will be provided through Minerva (and not through
Gradescope - Gradescope is only used for submissions!).
6. Presentation and referencing
Your report must be a single PDF file called report.pdf. Focus on answering the questions asked with each task. Be concise, precise and technical. Avoid unnecessary blathering or rambling. Include screenshots as
noted in the task description! You may refer to your code in the descriptions, but descriptions that just say “see source code” are not sufficient.
Do not reproduce bulk code in your report. If you wish to highlight a
particularly clever method, a short snippet of code is acceptable. Never
show screenshots/images of code - if you wish to include code, make sure
it is rendered as text in the PDF using appropriate formatting and layout.
Screenshots must be of good quality (keep the resolution at 1280×720 or
higher). Don’t compress the screenshots overly much (e.g., visible compression artifacts).
Apply good report writing practices. Structure your report appropriately.
Use whole English sentences. Use appropriate grammar, punctuation and
spelling. Provide figure captions to figures/screenshots, explaining what
the figure/screenshot is showing and what the reader should pay attention to. Refer to figures from your main text. Cite external references
appropriately.
Identifiers and comments in your code must be written in English. You
must use either ASCII or UTF-8 encoding for your code.
The quality of written English will be assessed in this work. As a minimum, you must ensure:
• Paragraphs are used
• There are links between and within paragraphs although these may
be ineffective at times
• There are (at least) attempts at referencing
• Word choice and grammar do not seriously undermine the meaning
and comprehensibility of the argument
• Word choice and grammar are generally appropriate to an academic
text
iii
These are pass/ fail criteria. So irrespective of marks awarded elsewhere,
if you do not meet these criteria you will fail overall.
7. Submission requirements
Your coursework will be graded once you have
(a) Submitted required files (code and report) through Gradescope.
(b) If deemed necessary, participated in an extended interview with the
instructor(s) where you explain your submission in detail.
You are encouraged to make test submissions in Gradescope. Please exclude the report from such test submissions, such that we can easily identify
work-in-progress.
Your submission will consist of source code and a report. Marking relies
on both report and submitted code. Make sure that your report includes
all items requested in each task (and only these), along with possible
references. Tasks/results without working code will receive zero marks.
Commented-out code is not considered “working code”.
IMPORTANT: In the report, you are required to put the answer for
each task on a separate page. The answer must fit on that page. If you
skip a task, include an empty page for this task. This means that Task 1
goes on Page 1 in your report, Task 2 on Page 2 and so on (use \clearpage
in LaTeX). Do not include a title page or similar. You may add one page
at the end for references only.
Submissions are made through Gradescope (do not send your solutions
by email!). Gradescope can pull from a Git repository. Alternatively, it
accepts .zip archives (you should see the contents of them when uploading
to Gradescope). Avoid uploading individual files as this tends to fail.
Gradescope will run preliminary checks on your submission and indicate
whether it is considered a valid submission.
The source code must compile and run as submitted on the standard SoC
machines found in the module’s labs. Your code must compile cleanly,
i.e., it should not produce any warnings. If there are singular warnings
that you cannot resolve or believe are in error, you must list these in your
report and provide an explanation of what the warning means and why it
is acceptable in your case. You are always expected to fix easily corrected
problems and other bulk warnings (for example, type conversions). Do
iv
not change the warning level defined in the handed-out code. Disabling
individual warnings through various means will still require documenting
them in the report.
Your submission must not include any “extra” files that are not required
to build or run your submission (aside from the report). In particular,
you must not include build artifacts, temporary files generated by your
IDE or other tools or files used by version control. Note that some of
these may be hidden by default, but they are almost always visible when
inspecting the archive with various tools. Do not submit unused code.
While you are encouraged to use version control software/source code management software (such as git or subversion), you must not make your
solutions publicly available. In particular, if you wish to use Github, you
must use a private repository. You should be the only user with access
to that repository.
8. Academic misconduct and plagiarism
You are encouraged to research solutions and use third-party resources.
If you find such, you must provide a reference to them in your report
and in code. Include information about the source (where to find it) and
original author(s). Never “copy-paste” code from elsewhere – all code
must be written yourself. If the solution is based on third party code,
make sure to indicate this in comments surrounding your implementation
in your code, in addition to including a reference in your report. It is
expected that you fully understand all code that you hand in as part of
your submission. You may be asked to explain any such code as part of
the marking process. If deemed necessary, you may be asked to attend a
short individual interview with the instructor(s), where you are asked to
explain specific parts of your submission.
• Leeds students are part of an academic community that shares ideas
and develops new ones.
• You need to learn how to work with others, how to interpret and
present other people’s ideas, and how to produce your own independent academic work. It is essential that you can distinguish between
other people’s work and your own, and correctly acknowledge other
people’s work.
v
• All students new to the University are expected to complete an online
Academic Integrity tutorial and test, and all Leeds students should
ensure that they are aware of the principles of Academic integrity.
• When you submit work for assessment it is expected that it will meet
the University’s academic integrity standards.
• If you do not understand what these standards are, or how they apply
to your work, then please ask the module teaching staff for further
guidance.
By submitting this assignment you are confirming that the work
is a true expression of your own work and ideas and that you
have given credit to others where their work has contributed to
yours.
9. Assessment/marking criteria grid
Please see individual tasks. Full marks are only awarded to high-quality
solutions with high-quality descriptions (where applicable).
vi
COMP3811
Coursework 1
Contents
1 Tasks 2
1.1 Setting Pixels . . . . . . . 2
1.2 Clipping Lines . . . . . . 3
1.3 Drawing Lines . . . . . . 3
1.4 2D Rotation . . . . . . . 3
1.5 Drawing triangles . . . . 4
1.6 Blitting images . . . . . . 4
1.7 Testing: lines . . . . . . . 5
1.8 Testing: triangles . . . . 6
1.9 Benchmarking - Specs . 6
1.10 Benchmark: Lines I . . . 7
1.11 Benchmark: Blitting . . . 7
1.12 Benchmark: Lines II . . . 7
1.13 Your own space ship . . 8
Coursework 1 focuses on basic graphics operations in 2D, including manipulating images, drawing lines and
triangles, and blitting images. Coursework 1 is to be solved individually and determines 50% of the total
mark for COMP3811.
Before starting work on the tasks below, study this document in its entirety. Plan your work. It is better to
focus on a subset of tasks and commit to these fully than to attempt everything in a superficial way. For the
purpose of planning, you may consider tasks in Sections 1.7 to 1.12 to be (more) advanced tasks. You should
hold off on these until you have completed other tasks.
While you are encouraged to use version control software/source code management software (such as git or subversion),
you must not make your solutions publicly available. In particular, if you wish to use Github, you must use a private
repository. You should be the only user with access to that repository.
You are allowed to discuss ideas with your colleagues. However, do not share your code with anybody else.
You must program independently and not base your submission on any code other than what has been provided with the coursework and/or in the exercises for COMP3811. As a special exception, you may reuse code
from COMP3811 exercises that was handed out (including briefs) or that you are the sole author of.
Use good commenting practices to explain your approach and solution. Good, thoughtful and well-written
comments will help you show that you understand your code. It will also decrease the chances of accidentally
ending up with submissions similar to other’s work.
Reminder: In your report, answer each task on a separate page. Include pages for tasks that you skip. This
means that Task 1 goes on page 1 in your report, Task 2 on page 2 and so on. You are not expected to fill the
pages. You cannot use more than one page per task. See assessment brief front for additional information.
Coursework 1 will not require you to use any third-party software outside of what is included in the handedout code. You are therefore not allowed to use additional third-party libraries.
2 COMP3811 - Coursework 1
1 Tasks
Start by downloading the Coursework 1 base code. Make sure you are able to build it. If necessary, refer to the
first exercise handed out in COMP3811. It uses the same base structure and includes detailed instructions to
get you started.
The Coursework 1 base code includes several subprojects. Some of them you will have already encountered
in exercises. Others are specific to the coursework.
• main, a program which combines elements from all tasks to draw a game-like 2D environment.
• draw2d, a library where you implement the various drawing functions.
• vmlib, a library for linear algebra/math-related functions.
• support, a library with some helper functions relating to setup and on-screen display.
• lines-sandbox, a simple graphical program that only draws lines. Use it for quick visual testing.
• lines-test, a program for automated tests relating to line drawing.
• lines-benchmark, a program for automated benchmarks relating to line drawing.
• triangles-sandbox, a graphical program that only draws triangles. Use it for quick visual testing.
• triangles-test, a program for automated tests relating to triangle drawing.
• blit-benchmark, a program for automated benchmarks relating to image blitting.
• x-*, which correspond to the various third-party libraries. Unlike the other subprojects, these are not
defined in the main premake5.lua, but rather in third party/premake5.lua.
Although the teaser image looks somewhat like a screenshot from a game, quite a few things that make a
game are missing. This includes functionality like collision detection, sound, game logic, AI, networking, etc
etc. However, most importantly for COMP3811, there are several graphics subroutines whose implementations
are missing as well. Each task that you complete will progress you from the initial empty black screen towards
the teaser image shown on the first page in this document.
Coursework 1 includes tasks for a maximum of 50 marks. Each of the tasks below indicates the maximum
number of marks that you can receive for it. Grading of each task is assessed based your answers in your
report and on code quality, including correctness, clarity, commenting and efficiency. Your code must work in
both debug and release modes.
1.1 Setting Pixels
2 marks
Drawing anything on screen ultimately requires you to set a specific pixel to a specific color. In this first task,
you will implement helper functions to do so. Any drawing from here on out will use these helpers, specifically
the Surface:set_pixel_srgb method.
Consider the Surface::set_pixel_srgb and Surface::get_linear_index methods. These are declared in
the Surface class in draw2d/surface.hpp and defined in draw2d/surface.inl. Implement the two
functions in draw2d/surface.inl.
The pixel coordinate (0, 0) must correspond to the bottom-left corner in the window.
The Surface class uses a RGBx image format, where each color component is stored in a single 8-bit unsigned
integer (std::uint8_t). You may set the fourth component (“x”) to zero. It is included to pad each pixel to be
32-bits but otherwise ignored. The image is stored in row-major order.
Important:
• You are not allowed to change the draw2d/surface.hpp header (and, consequently, you may not
change the interface of the Surface class).
• You must keep the assert()-line as the first line of the Surface::set_pixel_srgb function definition.
Only add new code below it.
These methods are used to draw the background particle field. Refer to Figure 1 for possible results. You can
move around by first tapping space to enter piloting mode (your mouse cursor should turn into a crosshair),
moving the mouse cursor in the direction you wish to accelerate, and then pressing and holding the right
mouse button to accelerate. Tapping space bar a second time will exit the piloting mode.
In your report: Provide a screenshot of the particle field. Make sure that the particles are visible (if necessary,
add a scaled-up cut-out image).
COMP3811 - Coursework 1 3
(a) Background “starfield” (b) Magnified view
Figure 1: Task 1. You might need to zoom in to the left image in your PDF viewer to see the individual points. The right
image shows a magnified view of the top-left region.
1.2 Clipping Lines
3 marks
Consider the function clip_line. It is declared in draw2d/draw.hpp and defined in draw2d/draw.cpp.
It is supposed to take the line from aBegin to aEnd and clip it against the aTargetArea rectangle (Rect2F,
defined in draw2d/rect.hpp).
If the line requires clipping, update the aBegin and aEnd arguments to define the clipped line (i.e., the portion
of the line inside the target area). The arguments are defined as non-const references, meaning this will change
the passed-in values. The function should return true if the line is visible and false otherwise. You should
not make any dynamic allocations (nor any system calls) in the clipping method.
In your report: Explain your method for clipping (as a reminder: do not just dump code into your report). Be
concise. If appropriate, use a figure to support your explanation.
1.3 Drawing Lines
5 marks
Next, consider the function draw_line_solid and the related draw_clip_line_solid. The functions are
also declared in the draw2d/draw.{hpp,cpp} pair of files. The former is provided to you and simply calls
clip_line and then -if visible- draw_clip_line_solid.
Implement the draw_clip_line_solid function. The goal is to produce a line that is as thin as possible (single
pixel width) and that does not have any holes (i.e., each pixel should connect to another pixel either by nearest
neighbours or by diagonals). Recall the parametrised version of a line as a starting point. You should ensure
that the function produces correct results with all pre-clipped inputs. You may pick any drawing method, but
it should scale with O (N) with respect to the number of drawn pixels (N). You should not make any dynamic
allocations (nor any system calls) in the line drawing method.
The handed-out code contains two additional programs related to your line drawing. Use lines-sandbox
to visually verify your results in isolation. It includes a small number of examples already. You can switch
between the examples using the number keys. See source code comments for more information. You are free
to add additional examples.
The second program, lines-test, runs a few automated tests on the line drawing. It uses the Catch2
testing library. Ensure that your implementation passes the existing tests. Refer to the source code for more
information on the tests.
With the line drawing in place, you should now be able to see a space ship (Figure 2a).
In your report: Explain your line drawing method. Be concise. Focus on technical aspects. Use equations/figures for support. A reader should be able to understand how your method works. Include a screenshot of the
drawn ship.
1.4 2D Rotation
2 marks
The space ship initially always faces to the right. To make it turn, you must implement a few functions related
to the 2 × 2 matrices:
• Matrix-matrix multiplication: Mat22f operator*( Mat22f const&, Mat22f const& ) noexcept
• Matrix-vector multiplication: Vec2f operator*( Mat22f const&, Vec2f const& ) noexcept
4 COMP3811 - Coursework 1
• Creation of a rotation matrix: Mat22f make_rotation_2d( float aAngleInRadians ) noexcept
The functions are both declared and defined in vmlib/mat22.hpp. Provide implementations for these functions/operators. With the implementations in place, the ship should now always face the mouse cursor when
in piloting mode (compare to Figure 2b – the spaceship is facing to the bottom right in this example).
In your report: Include a screenshot of the rotated ship.
1.5 Drawing triangles
6 marks
Consider the function draw_triangle_interp. It is also declared in the draw2d/draw.hpp header and defined in draw2d/draw.cpp. This function draws a single triangle defined by its three vertices (aP0, aP1 and
aP2). Each vertex is assigned a color (aC0, aC1 and aC2, respectively). These colors should be interpolated
across the triangle with barycentric interpolation. Implement this function. Make sure that the function works
correctly with all (reasonable) inputs.
Unlike earlier examples, the colors are specified in linear RGB (ColorF). You should perform the interpolation
in linear RGB space and only convert to the 8-bit sRGB representation when writing the color to the surface.
You can pick any method, but it should be reasonably efficient (e.g., simply testing all pixels in the screen is
not acceptable). You should not make any dynamic allocations or system calls in the triangle drawing method.
Use the triangles-sandbox to visually experiment with your triangle drawing in isolation. Run the tests in
triangles-test and ensure that they pass. When you have implemented the triangle drawing, you should
also be able to see the asteroids in the main program (see teaser image).
Note: You must not change the prototype of the draw_triangle_interp function. You must use Surface▽
▷ ::set_pixel_srgb to draw pixels.
In your report: Explain your method (same requirements as Section 1.3). Document any special handing that
you perform. Include a screenshot of the main program, with the asteroids visible.
1.6 Blitting images
4 marks
In this task, you will implement image blitting with alpha masking. Consider the blit_masked function
declared in draw2d/image.hpp and defined in draw2d/image.cpp. You will also need to implement a
few helper functions in draw2d/image.inl. Search for lines containing the string // TODO.
You should blit the input image (aImage of type ImageRGBA) to the position specified by aPosition. The
position is relative to the center of the input image. Input pixels with an alpha value (a component of the
Color_sRGB_Alpha color struct) less than 128 should be discarded. Consider efficiency in your implementation
and do not make any dynamic allocations/syscalls (etc etc.). If you have implemented the method correctly,
you should find the earth after flying a bit to the right – it will be off-screen initially (see teaser image and
Figure 3).
Note: You must not change the prototype of the blit_masked function. You must not change the ImageRGBA
class and the load_image function.
In your report: Describe your implementation of the blit (same requirements as Section 1.3). Discuss the
efficiency of your implementation. Focus specifically on choices in your implementation that benefit efficiency
and the impact of clipping/culling.
(a) Section 1.3 (b) Section 1.4
Figure 2: (a) Space ship without rotation, facing the default direction (right). (b) Space ship with rotation, always facing
the mouse cursor when in piloting mode.
COMP3811 - Coursework 1 5
Figure 3: Approaching the earth (lithobraking not yet implemented!).
Figure 4: Illustration of the displayArea.png base image for use in Sections 1.7 and 1.8, arranged in a 2 × 2 grid . You
must use this image to illustrate your distinct test cases for each of the scenarios. The center blue area represents the area of
the Surface. The gray area represents space outside of the image. Use it to help illustrate lines for e.g., Scenarios 1 and 2 in
Section 1.7. You can get the base image on Minerva, or via the following “links” (PDF attachments): ,
& .
1.7 Testing: lines
8 marks
Consider the lines-test program. It contains a few example tests that verify expected behaviour. However,
the tests are far from exhaustive.
We will explore the following four scenarios to verify that the line drawing (with clipping) works correctly:
1. Consider lines with one point inside the surface and one outside.
2. Consider lines with both points outside of the surface.
3. Consider a line from p0 to p1. It should be identical to the line from p1 to p0.
4. Consider two lines. The first starts at p0 and extends to p1. The second starts at p1 and extends to p2.
When both are drawn, there should be no gap between the two lines. Extend this to multiple lines - what
happens if the lines are very short?
First, for each scenario, construct four different cases that are distinct from each other in a significant way.
Avoid selecting cases that share similar properties (e.g., where all are axis-aligned). Illustrate these using one
figure per scenario, with the provided displayArea.{png,pdf,svg} as a base (see Figure 4). Next, implement tests for each scenario. Each scenario must be implemented in a separate TEST_CASE named ScenarioN
(with N equal to the number in the list above) in the scenarios.cpp file. Each scenario is expected to (at
least) test your representative lines. It is expected that each case uses multiple assertions.
If your line drawing implementation fails some of the tests, you should tag the corresponding TEST_CASE with
[!mayfail]. Mention this in your report.
6 COMP3811 - Coursework 1
In your report: Include the four figures with your selected cases (label individual cases if necessary). Describe
them briefly and motivate your choice of them. Why are these are a good selection for your tests? Describe how
you have implemented the corresponding tests. No marks will be awarded for tests that lack an explanation
and solid reasoning.
1.8 Testing: triangles
4 marks
Add at least two (2) more distinct test cases to the triangles-test program. Refer to Section 1.7 for details –
the same requirements/guidelines apply here. Illustrate each of the two scenarios for your tests using Figure 4,
showing triangles for each case. Use the provided scenarios.cpp file. Make sure the tests that you add are
meaningful.
In your report: Describe each scenario. Include two figures with your representative cases for the scenarios
(label individual cases if necessary). Describe them briefly and motivate your choice of them. Why are these
are a good selection for your tests? Describe how you have implemented the corresponding tests. No marks
will be awarded for tests that lack an explanation and solid reasoning.
1.9 Benchmarking - Specs
0 marks - REQUIRED for Sections 1.10 to 1.12
This task by itself does not give you any marks, but is required if you plan on attempting the benchmarking
related tasks. If the information is missing from your report (or obviously incorrect), the benchmarking tasks
will automatically receive zero marks.
Important for all benchmarking tasks: You should only ever benchmark code built in the release configuration. The
debug configuration disables many compiler optimizations (including code inlining!) to aid debugging and is
therefore not representative of the final performance. Hence, when running benchmarks, make sure you only
ever use release builds.
Modern CPUs and operating systems also adjust clock rates of the processor based on work load.
Many CPUs can additionally boost to higher clock rates for short periods of time. These features are
obviously desirable under normal conditions, but make life during benchmarking more difficult.
Refer to Benchmarking details below for additional discussion on this topic.
In your report: Please reproduce the following table in your report and fill in with the relevant information
for the system on which you run the benchmarks.
CPU model name
L1 data cache amount (core)
L2 cache amount (core)
System RAM amount
System RAM type & speed
Operating system
Compiler
If you run the benchmarks on more than one system, please repeat it for each. Make sure that it is clear which
system you are using whenever you report results.
Example:
CPU model name Intel(R) Core(TM) i7-12700K
L1 data cache amount 48 KiB (P core), 32 KiB (E core)
L2 cache amount 1.25 MiB
System RAM amount 64 GiB
System RAM type & speed DDR5 at 4800 MT/s
Operating system Linux
Compiler GCC 14.3.0
On Linux, the CPU model name can be found by reading /proc/cpuinfo and looking for the model name
line. It should uniquely and unambiguously identify the CPU. Information on caches may require some slight
research. In this case, I found the information Intel’s documentation (formerly Ark) and on Wikichip. In
the labs, you can use inxi to find information about system RAM:
> module add inxi
> inxi -m
COMP3811 - Coursework 1 7
1.10 Benchmark: Lines I
5 marks
Compare the performance of your line drawing (draw_line_solid()) under different conditions. For this
task, use the line-benchmark application. It uses, in turn, Google’s microbenchmarking library, which
allows you to implement these benchmarks. Study the documentation and examples at the provided link. The
provided code implements a simple example that shows how the library can be used.
There are multiple variables that could affect line drawing performance with draw_line_solid()). Identify
three (3) such variables. Make sure your choices are independent of each other. List your choices and for each
briefly (one paragraph) explain why you believe that variable should affect performance. Include a hypothesis
on how it affects performance (e.g., does changing the variable increase performance or decrease it?).
Next, test your hypotheses by varying each variable (independently). Make sure your tests use representative lines. You might need to test with multiple different lines for each value of a certain variable. Always
benchmark different lines in isolation.
Check your results: do they make sense?
In your report: As requested above, list your variables, explanations of them and your hypotheses. Document
your representative lines and explain why these are good picks (and sufficient for your tests). Present the
results from your benchmarks using a graph/plot (do not just dump output of the benchmarking program in
the terminal). Evaluate and analyze your results. Were your hypotheses correct? Discuss the results and try to
explain what you have seen.
Do not forget to include units on axes/reported numbers. Marks are mainly awarded for a solid analysis
and discussion of the results. Poor and/or badly motivated choices of variables will result in zero marks.
Benchmarking incorrect line drawing may result in zero marks, as will nonsensical results.
1.11 Benchmark: Blitting
5 marks
Compare the performance of your blit (blit_masked) to two more blit variants under different conditions. For
this task, use the blit-benchmark program; like earlier tasks it uses Google’s microbenchmarking library.
You should first implement the additional blit variants in draw-ex.cpp:
• blit_ex_solid: A blit without alpha masking, where you just copy over the target image pixel by pixel.
Implement this yourself using loops in C++.
• blit_ex_memcpy: A blit without alpha masking, but implement this using std::memcpy, one for each
line in the image.
These “extended” functions take a SurfaceEx argument instead of the Surface. The main difference is that
SurfaceEx gives out a raw std::uint8_t* pointer to the image data; you will (minimally) need this for the
std::memcpy-based variant. Study the declaration of SurfaceEx for details.
As always, you should ensure that the variants work correctly. There is no point in benchmarking incorrect
code.
Benchmark the performance under different conditions. Identify candidate variables that could affect performance. Vary only one variable at a time. (However, the benchmark program should run all variants automatically.)
Analyze your results. Do they seem realistic/reasonable?
In your report: What variables did you consider? Why? Are there any others that you did not consider? Why?
Present your results using graphs/plots (do not dump output from the terminal). What are your observations?
Try to explain what you have seen.
Marks are mainly awarded for a solid analysis and discussion of the results. No marks are awarded for just
showing the results. Do not forget to include units on axes/reported numbers.
1.12 Benchmark: Lines II
5 marks
Study the draw-ex.hpp and draw-ex.cpp files, specifically the declaration of draw_ex_line_solid() and
the provided draw_ex_diagonal().
8 COMP3811 - Coursework 1
Your task is to implement a second line drawing method in draw_ex_line_solid(). Choose from the following options:
• Research an optimized line drawing method. It should be based on existing (technical) literature that
you can reference.
• If you previously implemented a method like DDA (with floating point), implement an integer-only
method (e.g. Bresenham). If you already implemented an integer-only method, then implement a standard DDA with floats1
.
Your improved method may use the SurfaceEx class. The method must function as a drop-in replacement for
draw_line_solid() and work correctly in all circumstances.
Compare performance of the implementations. Include cases where you can use draw_ex_diagonal as a
simple baseline for your comparisons. What can you learn from that?
Try to identify the bottlenecks in your implementations. What could you do to improve performance further?
You might find Agner Fog’s instruction table listings helpful, along with Matt Godbolt’s compiler explorer.
In your report: Present your findings appropriately (see previous benchmarking tasks). Analyze the results
and discuss your conclusions.
Do not forget to include units on axes/reported numbers. Marks are mainly awarded for a solid analysis
and discussion of the results. Your draw_ex_line_solid() must function correctly, i.e., as an one-to-one
replacement of draw_line_solid().
1.13 Your own space ship
1 mark
The default space ship shape is defined in main/spaceship.cpp. It consists of a number of points that are
connected by lines.
Define your own custom space ship (see instructions in the source code). You must not use more than 32
points. The ship shape must show some amount of complexity and creativity. In your report, indicate if you
have created a custom design and include a screenshot of your custom ship.
Please indicate in the source code (see comments) whether you would allow us to use your ship shape in
future iterations of the COMP3811 module (for example as non-player ships). Your choice here does not affect
the marking of this task.
In your report: Include a screenshot of your ship. Briefly explain your design and mention the number of
lines/points you used.
Wrapping up
Please double-check the submission requirements and ensure that your submission conforms to these. In
particular, pay attention to file types (archive format and report format) and ensure that you have not included
any unnecessary files in the submission. Make sure that you have tested your code (compiled and run) in both
debug and release modes.
Acknowledgements
The document uses icons from https://icons8.com: , , . . The “free” license requires attribution in documents that use the icons.
Note that each icon is a link to the original source thereof.
Benchmarking details
As mentioned previously in this document, CPU frequency scaling can make benchmarking results less reliable. There are some tricks that may help.
A common workaround is to “warm up the CPU” by running a computationally heavy task for a short while
before starting measurements. The computational load will cause the OS to transition the CPU to a higher
clock rate. The main measurements should only take place after this warm up.
1
In real-time graphics, we typically avoid doubles. They cost twice as much storage, may be significantly slower to compute, and the
extra precision is seldom needed. In fact, there are often better methods to improve precision than just reaching for a more expensive type.
COMP3811 - Coursework 1 9
Google Benchmark seems to run benchmarks in the order they are declared (at least when using a single file).
You can try to add a dummy benchmark at the start, whose results you discard, before running the main
benchmarks. You can also try reordering individual benchmarks. If the results stay the same or very close, it
is a good sign.
A better way would be to disable the CPU frequency scaling temporarily. Unfortunately, this is not always
possible (it requires superuser privilege, which you probably shouldn’t have on the SoC computers).
Nevertheless, if you have your own Linux machine, you can run the following (it requires the cpupower tool):
$ cpupower frequency-info
analyzing CPU 0:
driver: acpi-cpufreq
...
available cpufreq governors: ondemand userspace powersave performance schedutil
current policy: frequency should be within 2.20 GHz and 3.70 GHz.
The governor "schedutil" may decide which speed to use
within this range.
...
This lists the current CPU frequency governor (here: shedutil) and available governors. We’re interested in
the performance governor, which simply runs at the max clock rate the CPU supports. You can activate it
with (this probably requires superuser access):
$ sudo cpupower frequency-set -g performance
Password: hunter2
Setting cpu: 0
...
Setting cpu: 11
Following CPUs are offline:
12-15
cpupower set operation was not performed on them
(The exact output will depend on your CPU. If you have them, don’t worry about the “offline” CPUs, these
likely correspond to cores that were disabled at the factory.)
Run the tests with the “performance” governor.
After you complete the tests, you will want to switch back to your default governor (here: “schedutil”). Using
the “performance” governor for an extended time will likely make your CPU waste power and may cause
devices like laptops to run hot.
請加QQ：99515681 郵箱：99515681@qq.com WX：codinghelp
