haas/spring2026/cprog/projects.md
... ...
@@ -8,10 +8,10 @@
8 8
| [pct7](../common/projects/pctX.md) | (bonus; due 20260311) |
9 9
| [wcp7](../common/projects/wcpX.md) | (due 20260311) |
10 10
| [bwp1](../common/projects/pctX.md) | (bonus; due 20260325) |
11
-| [cnv1](../common/projects/cnv1.md) | (due 20260325) |
11
+| [cnv1](projects/cnv1.md) | (due 20260325) |
12 12
| [pct8](../common/projects/pctX.md) | (due 20260325) |
13 13
| [wcp8](../common/projects/wcpX.md) | (due 20260325) |
14
-| [fwg0](../common/projects/fwg0.md) | (due 20260401) |
14
+| [fwg0](projects/fwg0.md) | (due 20260401) |
15 15
| [pct9](../common/projects/pctX.md) | (bonus; due 20260401) |
16 16
| [wcp9](../common/projects/wcpX.md) | (due 20260401) |
17 17
haas/spring2026/cprog/projects/cnv1.md
... ...
@@ -0,0 +1,452 @@
1
+# CSCS1320 C/C++ Programming
2
+
3
+# PROJECT: CALCULATING N-ARY VALUES (cnv1)
4
+
5
+## OBJECTIVE
6
+
7
+To create a program that can calculate and determine the number of factor
8
+pairs (nary value) over a given range of numbers.
9
+
10
+## BACKGROUND
11
+
12
+In mathematics, you have likely encountered the notion of "prime"
13
+numbers, those values which are divisible only by 1 and the number
14
+itself.
15
+
16
+Expanding our view on the situation, when considering factors of a
17
+number, we have the presence of a "factor pair"; ie a pair of two values
18
+that are evenly divisible into that number.
19
+
20
+For 17, a prime number, we have just ONE factor pair: 1 and 17:
21
+
22
+ * `17 % 1 == 0`
23
+ * `17 % 17 == 0`
24
+
25
+All other values (2-16) when we divide them into 17 results in a non-zero
26
+value for the remainder.
27
+
28
+In this way, prime, or primary, numbers, have exactly ONE factor pair. To
29
+further simplify matters, we can call it an N-ary(1) or nary(1) value.
30
+Where the number indicates the number of factor pairs.
31
+
32
+A secondary, or nary(2) number, on the other hand, has exactly TWO sets
33
+of factor pairs.
34
+
35
+Take the number 6, for instance:
36
+
37
+ * factor pair of 1 and 6
38
+ * factor pair of 2 and 3
39
+
40
+Where 17 was a primary number, 6 is a secondary number.
41
+
42
+### DETERMINING FACTOR PAIRS
43
+
44
+We are going to be exploring a basic, brute force, method of determining
45
+factors for a number, and that is the "trial by division" method.
46
+
47
+Here, we successively divide a number by potential factors, to see if the
48
+factor evenly divides into the number. For convenience, we will assume
49
+the 1 and number factor pair, because EVERY number is evenly divisible by
50
+1 and itself.
51
+
52
+So, the number 5:
53
+
54
+ * `5 % 2 == 1`
55
+ * `5 % 3 == 2`
56
+ * `5 % 4 == 1`
57
+
58
+No other evenly divisible factors were found in the range 2-(N-1),
59
+therefore we are only left with the factor pair of 1 and N, making 5 an
60
+nary(1) value.
61
+
62
+The number 14:
63
+
64
+ * `14 % 2 == 0` another factor!
65
+ * `14 % 3 == 2`
66
+ * `14 % 4 == 2`
67
+ * `14 % 5 == 4`
68
+ * `14 % 6 == 2`
69
+ * `14 % 7 == 0` another factor!
70
+ * `14 % 8 == 6`
71
+ * `14 % 9 == 5`
72
+ * `14 % 10 == 4`
73
+ * `14 % 11 == 3`
74
+ * `14 % 12 == 2`
75
+ * `14 % 13 == 1`
76
+
77
+Because factor pairs ALWAYS come in a set of 2, we have the factor pairs
78
+of 1 and 14, along with 2 and 7.
79
+
80
+How about 12:
81
+
82
+ * `12 % 2 == 0`
83
+ * `12 % 3 == 0`
84
+ * `12 % 4 == 0`
85
+ * `12 % 5 == 2`
86
+ * `12 % 6 == 0`
87
+ * `12 % 7 == 5`
88
+ * `12 % 8 == 4`
89
+ * `12 % 9 == 3`
90
+ * `12 % 10 == 2`
91
+ * `12 % 11 == 1`
92
+
93
+There are 4 additional factors discovered here, giving us a total of 6
94
+factors, or three factor pairs:
95
+
96
+ * 1, 12
97
+ * 2, 6
98
+ * 3, 4
99
+
100
+Notice also how the factors are nested: 1 and 12 are the outermost, 2 and
101
+6 are encapsulated within that, and inside there, 3 and 4.
102
+
103
+Because there are 3 factor pairs, 12 would be considered an nary(3) value
104
+(or a tertiary number).
105
+
106
+### COMMANDLINE ARGUMENTS
107
+
108
+To facilitate our activities, we will be making use of command-line
109
+arguments in our programs.
110
+
111
+Command-line arguments are simply the tokens (space-separated pieces of
112
+information) we provide to the computer at the prompt:
113
+
114
+```
115
+lab46:~/src/SEMESTER/cprog/project$ ./project token1 token2 ... tokenN
116
+```
117
+
118
+The operating system packages up this information and provides it to our
119
+program, allowing us to access it.
120
+
121
+The first token ("./project") will be the invocation of our program,
122
+allowing our programs to know what they are called.
123
+
124
+The second token is the argument that immediately follows (in our case,
125
+"token1"); the third is "token2", and on and on until our very last
126
+provided argument ("tokenN" in our conceptual example).
127
+
128
+In addition to all the arguments packaged together in an array of
129
+strings, we are also provided with a total overall argument count, so we
130
+can know how many elements there are in this array of strings.
131
+
132
+### ARGUMENT NAMING CONVENTIONS
133
+
134
+Although you can name them anything, conventionally in many documents
135
+these have been named:
136
+
137
+ * **argc** (or **ac**): the argument count, a signed integer (`int argc`)
138
+ * **argv** (or **av**): the array of strings (or an array of an array of char), a double pointer (`char **argv`)
139
+
140
+### ACCEPTING ARGUMENTS IN YOUR PROGRAM
141
+
142
+To access this command-line information, we provide arguments to our
143
+main() function, as follows:
144
+
145
+```
146
+int main (int argc, char **argv)
147
+{
148
+```
149
+
150
+We then have access to those populated variables (when we run a program,
151
+we are calling main(), so it should make sense that the arguments we
152
+provide to our program are passed as parameters to our main() function,
153
+the starting point of our program).
154
+
155
+### ACCESSING OUR ARGUMENTS
156
+
157
+The arguments are accessible via the argv array, in the order they were
158
+specified:
159
+
160
+ * argv[0]: program invocation (path + program name)
161
+ * argv[1]: first argument to the program (2nd argument to the command-line)
162
+ * argv[2]: second argument to the program (3rd overall on the command-line)
163
+ * ...
164
+ * argv[N]: the last provided argument
165
+
166
+N in this case is equivalent to (**argc - 1**), as is commonly the case
167
+with array size and addressing.
168
+
169
+Additionally, let's not forget the **argc** variable, an integer, which
170
+contains a count of arguments (argc `==` argument count). If we provided
171
+argv[0] through argv[4], argc would contain a 5 (because array elements
172
+0-4 indicate 5 distinct array elements).
173
+
174
+### EXAMPLE
175
+
176
+For example, if we had the following program:
177
+
178
+```
179
+lab46:~/src/SEMESTER/cprog/project$ ./project 128 1 2 2048
180
+```
181
+
182
+We'd have:
183
+
184
+ * `argv[0]`: "./project"
185
+ * `argv[1]`: "128" (note, NOT the scalar integer 128, but a string)
186
+ * `argv[2]`: "1"
187
+ * `argv[3]`: "2"
188
+ * `argv[4]`: "2048"
189
+
190
+and let's not forget:
191
+
192
+ * argc: 5 (there are 5 things, argv indexes 0, 1, 2, 3, and 4)
193
+
194
+### SIMPLE ARGUMENT CHECKS
195
+
196
+While there are a number of checks we should perform, one of the first
197
+should be a check to see if the minimal number of arguments has been
198
+provided:
199
+
200
+```
201
+ if (argc < 3) // if less than 3 arguments (program_name + argv[1] + argv[2] == 3) have been provided
202
+ {
203
+ fprintf(stderr, "%s: insufficient number of arguments!\n", argv[0]);
204
+ exit(1);
205
+ }
206
+```
207
+
208
+Trying to access a non-existent argument could result in a segmentation
209
+fault. ALWAYS check your count to ensure the desired argument exists at
210
+the given position.
211
+
212
+### HEADER FILES
213
+
214
+We don't need any extra header files to use command-line arguments, but
215
+we will need an additional header file to use the **atoi(3)** function,
216
+which we'll use to quickly turn the command-line parameter into an
217
+integer, if such an operation is needed; and that header file is
218
+**stdlib.h**, so be sure to include it with the others:
219
+
220
+```
221
+#include <stdio.h>
222
+#include <stdlib.h>
223
+```
224
+
225
+In the above example, if argv[1] was "128" and we actually wanted that as
226
+an integer (versus the string it is initially available as), we utilize
227
+**atoi(3)** in the following manner:
228
+
229
+```
230
+ int value = 0;
231
+
232
+ value = atoi (argv[1]);
233
+```
234
+
235
+NOTE: you will want to do proper error checking and first ensure that
236
+argv[1] even exists (by checking **argc**). Failure to do so may result
237
+in a segmentation fault.
238
+
239
+## GRABIT
240
+
241
+There is a grabit for this project, which will provide you with some
242
+files pertinent for performing this project.
243
+
244
+Run '**grabit**' on lab46 in the appropriate manner to obtain the files,
245
+then move them to your development system used in this class.
246
+
247
+## COMPILING
248
+
249
+Since there is a provided Makefile in the project grabit, we can use that
250
+to compile, either regularly:
251
+
252
+```
253
+yoursystem:~/src/SEMESTER/cprog/cnv1$ make
254
+```
255
+
256
+Or, with debugging support:
257
+
258
+```
259
+yoursystem:~/src/SEMESTER/cprog/cnv1$ make debug
260
+```
261
+
262
+## PROGRAM
263
+
264
+It is your task to write a program that, upon accepting various pieces of
265
+input from the user, computes the number of factor pairs of a given
266
+number or range of numbers, displaying to STDOUT all the numbers in that
267
+range that qualify as that N-ary value.
268
+
269
+## SPECIFICATIONS
270
+
271
+Your program should:
272
+
273
+ * have valid, descriptive variable names of length //no shorter than// 4 symbols
274
+ * have consistent, well-defined indentation (no less than 4 spaces per level of indentation)
275
+ * all code within the same scope aligned to its indentation level
276
+ * have proximal comments explaining your rationale and what is going on, throughout your code
277
+ * from the command-line, obtain the needed parameters for your program (require these arguments to be present, displaying errors to STDERR and exiting if they are not present):
278
+ * argv[1]: N-ary value (how many factor pairs are we requiring; 1 for prime, 2 for secondary, 3 for tertiary, etc.); this should be stored and managed as an **unsigned char**.
279
+ * argv[2]: lower-bound (where to start processing, inclusive of the lower bound value); this should be stored in an **unsigned short int**
280
+ * argv[3]: upper-bound (where to stop processing, inclusive of the upper bound value); this should be shored in an **unsigned short int**
281
+ * immediately after parameter processing, check to make sure the specified parameters are positive numbers. Any deviations should be displayed as error messages to STDERR:
282
+ * N-ary value must be between 1 and 16 (inclusive of 1 and 16)
283
+ * on error display "ERROR: invalid nary value (#)!" and terminate execution sending back a 1 (the # should be the actual number in deviation)
284
+ * lower bound must be between 2 and 40000 (inclusive of 2 and 40000)
285
+ * on error display "ERROR: invalid lower bound (#)!" and terminate execution sending back a 2 (the # should be the actual number in deviation)
286
+ * upper bound must be between 2 and 65000 (inclusive of 2 and 65000)
287
+ * on error display "ERROR: invalid upper bound (#)!" and terminate execution sending back a 3 (the # should be the actual number in deviation)
288
+ * on situation of lower bound being greater than upper bound, display "ERROR: lower bound (#) is larger than upper bound (#)!", terminating execution and sending back a 4 (the # should be the actual number in deviation)
289
+ * proceed to evaluate the appropriate number range, determining whether or not it is an N-ary number of runtime specification
290
+ * if it is, display the value to STDOUT in space-separated form (see execution section below for format)
291
+ * if it is not, do not display anything related to that value (again, see execution section below)
292
+ * using a single return statement at the conclusion of the code, return a 0 indicating successful operation
293
+ * for all error results, use **exit()** instead; there should only be exactly ONE **return()** statement per function
294
+
295
+Some additional points of consideration:
296
+ * Note that the driving variables in your loops need to be at least of type **short int**, otherwise you may get a warning when you compile it.
297
+
298
+## EXECUTION
299
+
300
+### PRIMARY NUMBER OUTPUT
301
+
302
+```
303
+yoursystem:~/src/SEMESTER/cprog/cnv1$ ./cnv1 1 8 24
304
+11 13 17 19 23
305
+yoursystem:~/src/SEMESTER/cprog/cnv1$
306
+```
307
+
308
+### SECONDARY NUMBER OUTPUT
309
+
310
+```
311
+yoursystem:~/src/SEMESTER/cprog/cnv1$ ./cnv1 2 3 12
312
+4 6 8 9 10
313
+yoursystem:~/src/SEMESTER/cprog/cnv1$
314
+```
315
+
316
+### TERTIARY NUMBER OUTPUT
317
+
318
+```
319
+yoursystem:~/src/SEMESTER/cprog/cnv1$ ./cnv1 3 11 37
320
+12 16 18 20 28 32
321
+yoursystem:~/src/SEMESTER/cprog/cnv1$
322
+```
323
+
324
+The execution of the program is short and simple- obtain the input, do
325
+the processing, produce the output, and then terminate.
326
+
327
+## REFERENCE
328
+
329
+In the CPROG public directory, inside the **cnv1/** subdirectory, will
330
+be a copy of my implementation (in executable form, by the name
331
+**ref_cnv1**), which abides by the project specifications. Please compare
332
+its output against that of your implementation. You can run "make check"
333
+to have it run your program through a few variations:
334
+
335
+```
336
+yoursystem:~/src/SEMESTER/cprog/cnv1$ make check
337
+n-ary(1) from 2 to 50: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47
338
+n-ary(2) from 2 to 50: 4 6 8 9 10 14 15 21 22 25 26 27 33 34 35 38 39 46 49
339
+n-ary(3) from 2 to 50: 12 16 18 20 28 32 44 45 50
340
+n-ary(4) from 2 to 50: 24 30 40 42
341
+n-ary(5) from 2 to 50: 36 48
342
+```
343
+
344
+## VERIFICATION
345
+
346
+In addition, I have also placed a **cnv1verify** script in that same
347
+subdirectory, which will test your program against a range of values, to
348
+determine overall correctness. You can run it by doing a "make verify":
349
+
350
+```
351
+yoursystem:~/src/SEMESTER/cprog/cnv1$ make verify
352
+ERROR CHECK
353
+=================
354
+invalid nary (0): ERROR: invalid nary value (0)!
355
+ exit status: 1, should be: 1
356
+- - - - - - -
357
+invalid nary (17): ERROR: invalid nary value (17)!
358
+ exit status: 1, should be: 1
359
+- - - - - - -
360
+invalid lower (1): ERROR: invalid lower bound (1)!
361
+ exit status: 2, should be: 2
362
+- - - - - - -
363
+invalid lower (43100): ERROR: invalid lower bound (43100)!
364
+ exit status: 2, should be: 2
365
+- - - - - - -
366
+invalid upper (0): ERROR: invalid upper bound (0)!
367
+ exit status: 3, should be: 3
368
+- - - - - - -
369
+invalid upper (65501): ERROR: invalid upper bound (65501)!
370
+ exit status: 3, should be: 3
371
+- - - - - - -
372
+lower (300) bigger than upper (65): ERROR: lower bound (300) is larger than upper bound (65)!
373
+ exit status: 4, should be: 4
374
+- - - - - - -
375
+Press ENTER to continue verification tests
376
+nary( 1)
377
+========
378
+ have: >23 29 31 <
379
+ need: >23 29 31 <
380
+
381
+nary( 2)
382
+========
383
+ have: >21 22 25 26 27 33 34 35 <
384
+ need: >21 22 25 26 27 33 34 35 <
385
+
386
+nary( 3)
387
+========
388
+ have: >20 28 32 <
389
+ need: >20 28 32 <
390
+
391
+nary( 4)
392
+========
393
+ have: >24 30 <
394
+ need: >24 30 <
395
+
396
+nary( 5)
397
+========
398
+ have: >36 <
399
+ need: >36 <
400
+
401
+yoursystem:~/src/SEMESTER/cprog/cnv1$
402
+```
403
+
404
+## SUBMISSION
405
+
406
+To successfully complete this project, the following criteria must be
407
+met:
408
+
409
+ * Code must compile cleanly (no notes, warnings, nor errors)
410
+ * Output must be correct, and match the form given in the sample output above.
411
+ * Code must be nicely and consistently indented, to show scope and maximize readability
412
+ * Code must be well commented (why and how comments)
413
+ * Do NOT double space your code. Group like statements together.
414
+ * Output Formatting (including spacing) of program must conform to the provided output (see above).
415
+ * Track/version the source code in your private semester repository
416
+ * Submit a copy of your source code to me using the **submit** tool.
417
+
418
+### SUBMIT TOOL USAGE
419
+
420
+To submit this program to me using the **submit** tool, run the following
421
+command at your lab46 prompt:
422
+
423
+```
424
+lab46:~/src/SEMESTER/cprog/cnv1$ make submit
425
+```
426
+
427
+And make sure you get no error messages.
428
+
429
+You should get some sort of confirmation indicating successful submission
430
+if all went according to plan. If not, check for typos and or locational
431
+mismatches.
432
+
433
+### RUBRIC
434
+
435
+What I'll be looking for:
436
+
437
+```
438
+208:cnv1:final tally of results (208/208)
439
+*:cnv1:resources obtained via grabit by Sunday before deadline [24/24]
440
+*:cnv1:proper error checking and status reporting performed [36/36]
441
+*:cnv1:correct variable types and name lengths used [36/36]
442
+*:cnv1:proper output formatting per specifications [36/36]
443
+*:cnv1:runtime tests of submitted program succeed [36/36]
444
+*:cnv1:no negative compiler messages for program [20/20]
445
+*:cnv1:code is pushed to lab46 repository [20/20]
446
+```
447
+
448
+Additionally:
449
+ * Solutions not abiding by spirit of project will be subject to a 50% overall deduction
450
+ * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
451
+ * Solutions not utilizing consistent, sensible indentation to promote scope and clarity will be subject to a 25% overall deduction
452
+ * Solutions not organized and easy to read are subject to a 25% overall deduction
haas/spring2026/cprog/projects/fwg0.md
... ...
@@ -0,0 +1,186 @@
1
+# CSCS1320 C/C++ Programming
2
+
3
+# PROJECT: FUN WITH GAMES (fwg0)
4
+
5
+## OBJECTIVE
6
+
7
+Obtain the latest stable release source code, or latest repository code,
8
+of the `Vircon32` Fantasy Console, along with its `DevTools`, and modify
9
+the provided code to display a sprite, move it around the screen, and
10
+detect screen bounds.
11
+
12
+## TASK
13
+
14
+Obtain and install on your development system the latest stable release,
15
+or latest version of the repository code, of the `Vircon32` Fantasy
16
+Console, along with its `DevTools` (C compiler).
17
+
18
+NOTE: Do not add the source code or binary code to `Vircon32` or
19
+`DevTools` to your repository! Process these outside of your repository.
20
+Once installed, your files specifically related to your modified code
21
+SHOULD be added to your repository.
22
+
23
+There is a `README` file in the base directory of the Vircon32
24
+`ComputerSoftware` directory that includes build instructions.
25
+
26
+Verify that it works, by testing the grabit code in its initial state by
27
+ensuring the `DevTools` work when called (`compile`, `assemble`, and
28
+`packrom`), and of course running it in the `Vircon32` emulator.
29
+
30
+Then, modify the program according to the following criteria:
31
+
32
+## PROGRAM
33
+
34
+You are to write a Vircon32 C program that does the following:
35
+
36
+ * displays some "sprite" of your choosing on the screen
37
+ * moves based on the control of the first gamepad (left, right, up, down)
38
+ * screen bounds detection and handling (barrier or wrap-around)
39
+
40
+NOTE: the first gamepad by default is mapped to the keyboard
41
+
42
+## URLs
43
+
44
+The main Vircon32 site can be found [here](https://www.vircon32.com/), be
45
+sure to note the link to the Vircon32 API.
46
+
47
+The code can be found on the [Vircon32 ComputerSoftware GitHub
48
+repository](https://github.com/vircon32/ComputerSoftware/)
49
+
50
+I would recommend against checking out the tutorials: too many have
51
+gotten into trouble being influenced by the code, running into issues
52
+trying to conform to project specifications.
53
+
54
+## CARTRIDGE BUILD PROCESS
55
+
56
+All of these steps can be automated with the use of the provided
57
+`Makefile` simply by typing `make` at the prompt.
58
+
59
+NOTE that with certain modifications, you'll first need to modify the XML
60
+file as appropriate.
61
+
62
+### COMPILE
63
+
64
+First step is to compile the C code, which can be done with the following
65
+command from the Vircon32 developer tools C compiler (`compile`):
66
+
67
+```
68
+yoursystem:~/src/SEMESTER/cprog/fwg0$ compile fwg0.c -o fwg0.asm
69
+```
70
+
71
+This compiles, or translates, the C code into Vircon32 assembly language
72
+code, which will then need to be assembled to machine code:
73
+
74
+### ASSEMBLE
75
+
76
+Once you've compiled your code successfully, you can use the Vircon32
77
+`assemble` DevTool to assemble the assembly:
78
+
79
+```
80
+yoursystem:~/src/SEMESTER/cprog/fwg0$ assemble fwg0.asm -o fwg0.vbin
81
+```
82
+
83
+### IMAGE CONVERSTION
84
+
85
+Any PNG images you'd like to use need to be converted to Vircon32 texture
86
+format via the `png2vircon` tool:
87
+
88
+```
89
+yoursystem:~/src/SEMESTER/cprog/fwg0$ png2vircon background.png -o background.vtex
90
+yoursystem:~/src/SEMESTER/cprog/fwg0$ png2vircon sprites.png -o sprites.vtex
91
+```
92
+
93
+Note that you'll also want to ensure the XML file has been updated to
94
+reference these textures:
95
+
96
+```
97
+ <binary path="fwg0.vbin" />
98
+ <textures>
99
+ <texture path="background.vtex" />
100
+ <texture path="sprites.vtex" />
101
+ </textures>
102
+```
103
+
104
+### AUDIO CONVERSION
105
+
106
+Should you have any WAV files you'd like to use need to be converted to
107
+the Vircon3 sound format via the `wav2vircon` tool:
108
+
109
+```
110
+yoursystem:~/src/SEMESTER/cprog/fwg0$ wav2vircon backgroundmusic.wav -o backgroundmusic.vsnd
111
+yoursystem:~/src/SEMESTER/cprog/fwg0$ wav2vircon soundfx.wav -o soundfx.vsnd
112
+```
113
+
114
+Note that you'll also want to ensure the XML file has been updated to
115
+reference these sounds:
116
+
117
+```
118
+ <sounds>
119
+ <sound path="backgroundmusic.vsnd" />
120
+ <sound path="soundfx.vsnd" />
121
+ </sounds>
122
+```
123
+
124
+### PACKING THE ROM
125
+
126
+Once all the components have been built, you can pack them together into
127
+a Vircon32 cartridge for use in the emulator via the `packrom` tool:
128
+
129
+```
130
+yoursystem:~/src/SEMESTER/cprog/fwg0$ packrom fwg0.xml
131
+```
132
+
133
+## SUBMISSION
134
+
135
+To be successful in this project, the following criteria (or their
136
+equivalent) must be met:
137
+
138
+ * Project must be submit on time, by the deadline.
139
+ * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline.
140
+ * Executed programs must display in a manner similar to provided output
141
+ * output formatted, where applicable, must match that of project requirements
142
+ * Processing must be correct based on input given and output requested
143
+ * Output, if applicable, must be correct based on values input
144
+ * Code must be nicely and consistently indented
145
+ * Code must be consistently written, to strive for readability from having a consistent style throughout
146
+ * Code must be commented
147
+ * Any "to be implemented" comments **MUST** be removed
148
+ * these "to be implemented" comments, if still present at evaluation time, will result in points being deducted.
149
+ * Sufficient comments explaining the point of provided logic **MUST** be present
150
+ * No global variables (without instructor approval), no goto statements, no calling of main()!
151
+ * Track/version the source code in your private semester repository
152
+ * Submit a copy of your source code to me using the **submit** tool by the deadline.
153
+
154
+### SUBMIT TOOL USAGE
155
+
156
+Let's say you have completed work on the project, and are ready to
157
+submit, you would do the following:
158
+
159
+```
160
+lab46:~/src/SEMESTER/cprog/fwg0$ make submit
161
+```
162
+
163
+You should get some sort of confirmation indicating successful submission
164
+if all went according to plan. If not, check for typos and or locational
165
+mismatches.
166
+
167
+### RUBRIC
168
+
169
+I'll be evaluating the project based on the following criteria:
170
+
171
+```
172
+234:fwg0:final tally of results (234/234)
173
+*:fwg0:code modified to meet project specifications [52/52]
174
+*:fwg0:grabit of project data by Sunday prior to duedate [26/26]
175
+*:fwg0:screenshot or video posted to class DISCORD of game running [52/52]
176
+*:fwg0:source file, XML file, build script, and cartridge submit [52/52]
177
+*:fwg0:code compiles, cartridge builds with no warning or error [26/26]
178
+*:fwg0:committed project related changes to private semester repo [26/26]
179
+```
180
+
181
+Additionally:
182
+
183
+ * Solutions not abiding by spirit of project will be subject to a 50% overall deduction
184
+ * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
185
+ * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction
186
+ * Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction