School of Computing: assessment brief

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 might be better to focus on a subset of tasks and commit to these fully than to  attempt everything in a superficial way.

2. Assessment tasks

Please see detailed instructions in the document following the standardized assessment brief (pages i-iv). The work is split into several tasks, accounting for 50% of the total module grade.

3. 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 is primarily provided during scheduled lab hours. Support for general issues may be provided through the module’s  “Teams” channel.  Do not expect answers outside of scheduled hours.  Do not post specific issues relating to your code in the public Teams channels. Do not crosspost across multiple channels.

4. Assessment criteria and marking process

Submissions take place through Gradescope.   Valid  submissions  will  be marked primarily based on the report and secondarily based on the submitted code.  See following sections for details on submission requirements and on requirements on the report. Marks and feedback will be provided through Minerva (and not through Gradescope - Gradescope is only used for submissions!).

5. 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.

Your submission will consist of source code and a report (≲ 8 pages).  The report is the basis for assessment.  The source code is supporting evidence for claims made in the report.  Tasks/results without supporting  code will receive zero marks.

Submissions are made through Gradescope (do not send your solutions by email!). You can use any of Gradescope’s mechanisms for uploading the complete solution  and report.  In particular, Gradescope accepts  . zip archives  (you should see the contents of them when uploading to Gradescope). Do not use other archive formats (Gradescope must be able to unpack them!). 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 UG teaching lab (2.05 in Bragg). 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. This is not applicable for easily fixed problems and other bulk warnings (for example, type conversions) – you are always expected to correct the underlying issues for such.  Do 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 (e.g. final binaries,  . o files, ...), temporary files generated by your IDE  or other tools (e.g.  . vs directory and contents) or files used by version control (e.g. .git directory and related files).  Note that some of these files may be hidden by default, but they are almost always visible when inspecting the archive with various  tools. Do not submit unused code (e.g. created for testing). Submitting unnecessary files may result in a deduction of marks.

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.

6. Presentation and referencing

Your report must be a single PDF file called report. pdf.  In the report, you must list all tasks that you have attempted and describe your solutions for each task.  Include screenshots for each task unless otherwise 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, but scale them down in the PDF). 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.

Furthermore, the UoL standard practices apply:

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 maybe ineffective at times

• There are (at least) attempts at referencing

• Word choice and grammar do not seriously undermine the meaning and compre- hensibility of the argument

• Word choice and grammar are generally appropriate to an academic text

These are pass/ fail criteria. So irrespective of marks awarded elsewhere, if you do not meet these criteria you will fail overall.

7. 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 (include information about the source 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.

Furthermore, the UoL standard practices apply:

Academic integrity means engaging in good academic practice. This involves essential academic skills, such as keeping track of where you find ideas and information and referencing these accurately in your work.

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.