c35ae24fd65e568c1c27e305e7b51390ee6ed79f
haas/spring2026/cprog/projects/fwg1.md
| ... | ... | @@ -0,0 +1,159 @@ |
| 1 | +# CSCS1320 C/C++ Programming |
|
| 2 | + |
|
| 3 | +# PROJECT: FUN WITH GAMES (fwg1) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Using your Vircon32 build and installation from fwg0, implement your own |
|
| 8 | +pong-like game: at least one paddle, at least one ball. Ball rebounds off |
|
| 9 | +the walls, reflects off the paddle. Simple score if the ball makes it |
|
| 10 | +past the paddle. |
|
| 11 | + |
|
| 12 | +## PROGRAM |
|
| 13 | + |
|
| 14 | +You are to write a Vircon32 C pong game: display the usual assets, with |
|
| 15 | +the expected mechanics and interactions (paddle, ball, collision, score). |
|
| 16 | + |
|
| 17 | + * a paddle, guarding one of the walls |
|
| 18 | + * paddle moves based on control of the gamepad |
|
| 19 | + * ball moves independently around the screen, rebounding/reflecting |
|
| 20 | + * ball rebounds off non-paddle walls |
|
| 21 | + * ball reflects off paddle when a collision occurs |
|
| 22 | + * scoring based on ball making it past the paddle |
|
| 23 | + |
|
| 24 | +NOTE: the first gamepad by default is mapped to the keyboard |
|
| 25 | + |
|
| 26 | +## CARTRIDGE BUILD PROCESS |
|
| 27 | + |
|
| 28 | +All of these steps can be automated with the use of the provided |
|
| 29 | +`Makefile` simply by typing `make` at the prompt. |
|
| 30 | + |
|
| 31 | +NOTE that with certain modifications, you'll first need to modify the XML |
|
| 32 | +file as appropriate. |
|
| 33 | + |
|
| 34 | +### COMPILE |
|
| 35 | + |
|
| 36 | +First step is to compile the C code, which can be done with the following |
|
| 37 | +command from the Vircon32 developer tools C compiler (`compile`): |
|
| 38 | + |
|
| 39 | +``` |
|
| 40 | +yoursystem:~/src/SEMESTER/cprog/fwg1$ compile fwg1.c -o fwg1.asm |
|
| 41 | +``` |
|
| 42 | + |
|
| 43 | +This compiles, or translates, the C code into Vircon32 assembly language |
|
| 44 | +code, which will then need to be assembled to machine code: |
|
| 45 | + |
|
| 46 | +### ASSEMBLE |
|
| 47 | + |
|
| 48 | +Once you've compiled your code successfully, you can use the Vircon32 |
|
| 49 | +`assemble` DevTool to assemble the assembly: |
|
| 50 | + |
|
| 51 | +``` |
|
| 52 | +yoursystem:~/src/SEMESTER/cprog/fwg1$ assemble fwg1.asm -o fwg1.vbin |
|
| 53 | +``` |
|
| 54 | + |
|
| 55 | +### IMAGE CONVERSTION |
|
| 56 | + |
|
| 57 | +Any PNG images you'd like to use need to be converted to Vircon32 texture |
|
| 58 | +format via the `png2vircon` tool: |
|
| 59 | + |
|
| 60 | +``` |
|
| 61 | +yoursystem:~/src/SEMESTER/cprog/fwg1$ png2vircon background.png -o background.vtex |
|
| 62 | +yoursystem:~/src/SEMESTER/cprog/fwg1$ png2vircon sprites.png -o sprites.vtex |
|
| 63 | +``` |
|
| 64 | + |
|
| 65 | +Note that you'll also want to ensure the XML file has been updated to |
|
| 66 | +reference these textures: |
|
| 67 | + |
|
| 68 | +``` |
|
| 69 | + <binary path="fwg1.vbin" /> |
|
| 70 | + <textures> |
|
| 71 | + <texture path="background.vtex" /> |
|
| 72 | + <texture path="sprites.vtex" /> |
|
| 73 | + </textures> |
|
| 74 | +``` |
|
| 75 | + |
|
| 76 | +### AUDIO CONVERSION |
|
| 77 | + |
|
| 78 | +Should you have any WAV files you'd like to use need to be converted to |
|
| 79 | +the Vircon3 sound format via the `wav2vircon` tool: |
|
| 80 | + |
|
| 81 | +``` |
|
| 82 | +yoursystem:~/src/SEMESTER/cprog/fwg1$ wav2vircon backgroundmusic.wav -o backgroundmusic.vsnd |
|
| 83 | +yoursystem:~/src/SEMESTER/cprog/fwg1$ wav2vircon soundfx.wav -o soundfx.vsnd |
|
| 84 | +``` |
|
| 85 | + |
|
| 86 | +Note that you'll also want to ensure the XML file has been updated to |
|
| 87 | +reference these sounds: |
|
| 88 | + |
|
| 89 | +``` |
|
| 90 | + <sounds> |
|
| 91 | + <sound path="backgroundmusic.vsnd" /> |
|
| 92 | + <sound path="soundfx.vsnd" /> |
|
| 93 | + </sounds> |
|
| 94 | +``` |
|
| 95 | + |
|
| 96 | +### PACKING THE ROM |
|
| 97 | + |
|
| 98 | +Once all the components have been built, you can pack them together into |
|
| 99 | +a Vircon32 cartridge for use in the emulator via the `packrom` tool: |
|
| 100 | + |
|
| 101 | +``` |
|
| 102 | +yoursystem:~/src/SEMESTER/cprog/fwg1$ packrom fwg1.xml |
|
| 103 | +``` |
|
| 104 | + |
|
| 105 | +## SUBMISSION |
|
| 106 | + |
|
| 107 | +To be successful in this project, the following criteria (or their |
|
| 108 | +equivalent) must be met: |
|
| 109 | + |
|
| 110 | + * Project must be submit on time, by the deadline. |
|
| 111 | + * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. |
|
| 112 | + * Executed programs must display in a manner similar to provided output |
|
| 113 | + * output formatted, where applicable, must match that of project requirements |
|
| 114 | + * Processing must be correct based on input given and output requested |
|
| 115 | + * Output, if applicable, must be correct based on values input |
|
| 116 | + * Code must be nicely and consistently indented |
|
| 117 | + * Code must be consistently written, to strive for readability from having a consistent style throughout |
|
| 118 | + * Code must be commented |
|
| 119 | + * Any "to be implemented" comments **MUST** be removed |
|
| 120 | + * these "to be implemented" comments, if still present at evaluation time, will result in points being deducted. |
|
| 121 | + * Sufficient comments explaining the point of provided logic **MUST** be present |
|
| 122 | + * No global variables (without instructor approval), no goto statements, no calling of main()! |
|
| 123 | + * Track/version the source code in your private semester repository |
|
| 124 | + * Submit a copy of your source code to me using the **submit** tool by the deadline. |
|
| 125 | + |
|
| 126 | +### SUBMIT TOOL USAGE |
|
| 127 | + |
|
| 128 | +Let's say you have completed work on the project, and are ready to |
|
| 129 | +submit, you would do the following: |
|
| 130 | + |
|
| 131 | +``` |
|
| 132 | +lab46:~/src/SEMESTER/cprog/fwg1$ make submit |
|
| 133 | +``` |
|
| 134 | + |
|
| 135 | +You should get some sort of confirmation indicating successful submission |
|
| 136 | +if all went according to plan. If not, check for typos and or locational |
|
| 137 | +mismatches. |
|
| 138 | + |
|
| 139 | +### RUBRIC |
|
| 140 | + |
|
| 141 | +I'll be evaluating the project based on the following criteria: |
|
| 142 | + |
|
| 143 | +``` |
|
| 144 | +260:fwg1:final tally of results (260/260) |
|
| 145 | +*:fwg1:code modified to meet project specifications [52/52] |
|
| 146 | +*:fwg1:grabit of project data by Sunday prior to duedate [26/26] |
|
| 147 | +*:fwg1:screenshot or video posted to class DISCORD of game running [26/26] |
|
| 148 | +*:fwg1:working collision detection between paddle and ball [52/52] |
|
| 149 | +*:fwg1:source file, XML file, build script, and cartridge submit [26/26] |
|
| 150 | +*:fwg1:code compiles, cartridge builds with no warning or error [26/26] |
|
| 151 | +*:fwg1:committed project related changes to private semester repo [52/52] |
|
| 152 | +``` |
|
| 153 | + |
|
| 154 | +Additionally: |
|
| 155 | + |
|
| 156 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 157 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 158 | + * 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 |
|
| 159 | + * 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 |
haas/spring2026/cprog/projects/fwg2.md
| ... | ... | @@ -0,0 +1,168 @@ |
| 1 | +# CSCS1320 C/C++ Programming |
|
| 2 | + |
|
| 3 | +# PROJECT: FUN WITH GAMES (fwg2) |
|
| 4 | + |
|
| 5 | +## OBJECTIVE |
|
| 6 | + |
|
| 7 | +Using your Vircon32 build and installation from fwg0, and pong foundation |
|
| 8 | +from fwg1, implement your own breakout-like game: at least one paddle, at |
|
| 9 | +least one ball. Ball rebounds off the walls, reflects off the paddle. An |
|
| 10 | +array of bricks displayed on the screen, which vanish once colliding with |
|
| 11 | +the ball. Score based on bricks hit. |
|
| 12 | + |
|
| 13 | +## PROGRAM |
|
| 14 | + |
|
| 15 | +You are to write a Vircon32 C breakout game: display the usual assets, |
|
| 16 | +with the expected mechanics and interactions (paddle, ball, bricks, |
|
| 17 | +collision, score). |
|
| 18 | + |
|
| 19 | + * a paddle, guarding one of the walls |
|
| 20 | + * paddle moves based on control of the gamepad |
|
| 21 | + * ball moves independently around the screen, rebounding/reflecting |
|
| 22 | + * ball rebounds off non-paddle walls |
|
| 23 | + * ball reflects off brick when a ball-brick collision occurs |
|
| 24 | + * brick disappears upon collision with ball |
|
| 25 | + * ball reflects off paddle when a ball-paddle collision occurs |
|
| 26 | + * scoring based on brick collisions |
|
| 27 | + * use an array to manage the bricks |
|
| 28 | + * use a loop to transact the array |
|
| 29 | + |
|
| 30 | +NOTE: the first gamepad by default is mapped to the keyboard |
|
| 31 | + |
|
| 32 | +## CARTRIDGE BUILD PROCESS |
|
| 33 | + |
|
| 34 | +All of these steps can be automated with the use of the provided |
|
| 35 | +`Makefile` simply by typing `make` at the prompt. |
|
| 36 | + |
|
| 37 | +NOTE that with certain modifications, you'll first need to modify the XML |
|
| 38 | +file as appropriate. |
|
| 39 | + |
|
| 40 | +### COMPILE |
|
| 41 | + |
|
| 42 | +First step is to compile the C code, which can be done with the following |
|
| 43 | +command from the Vircon32 developer tools C compiler (`compile`): |
|
| 44 | + |
|
| 45 | +``` |
|
| 46 | +yoursystem:~/src/SEMESTER/cprog/fwg2$ compile fwg2.c -o fwg2.asm |
|
| 47 | +``` |
|
| 48 | + |
|
| 49 | +This compiles, or translates, the C code into Vircon32 assembly language |
|
| 50 | +code, which will then need to be assembled to machine code: |
|
| 51 | + |
|
| 52 | +### ASSEMBLE |
|
| 53 | + |
|
| 54 | +Once you've compiled your code successfully, you can use the Vircon32 |
|
| 55 | +`assemble` DevTool to assemble the assembly: |
|
| 56 | + |
|
| 57 | +``` |
|
| 58 | +yoursystem:~/src/SEMESTER/cprog/fwg2$ assemble fwg2.asm -o fwg2.vbin |
|
| 59 | +``` |
|
| 60 | + |
|
| 61 | +### IMAGE CONVERSTION |
|
| 62 | + |
|
| 63 | +Any PNG images you'd like to use need to be converted to Vircon32 texture |
|
| 64 | +format via the `png2vircon` tool: |
|
| 65 | + |
|
| 66 | +``` |
|
| 67 | +yoursystem:~/src/SEMESTER/cprog/fwg2$ png2vircon background.png -o background.vtex |
|
| 68 | +yoursystem:~/src/SEMESTER/cprog/fwg2$ png2vircon sprites.png -o sprites.vtex |
|
| 69 | +``` |
|
| 70 | + |
|
| 71 | +Note that you'll also want to ensure the XML file has been updated to |
|
| 72 | +reference these textures: |
|
| 73 | + |
|
| 74 | +``` |
|
| 75 | + <binary path="fwg2.vbin" /> |
|
| 76 | + <textures> |
|
| 77 | + <texture path="background.vtex" /> |
|
| 78 | + <texture path="sprites.vtex" /> |
|
| 79 | + </textures> |
|
| 80 | +``` |
|
| 81 | + |
|
| 82 | +### AUDIO CONVERSION |
|
| 83 | + |
|
| 84 | +Should you have any WAV files you'd like to use need to be converted to |
|
| 85 | +the Vircon3 sound format via the `wav2vircon` tool: |
|
| 86 | + |
|
| 87 | +``` |
|
| 88 | +yoursystem:~/src/SEMESTER/cprog/fwg2$ wav2vircon backgroundmusic.wav -o backgroundmusic.vsnd |
|
| 89 | +yoursystem:~/src/SEMESTER/cprog/fwg2$ wav2vircon soundfx.wav -o soundfx.vsnd |
|
| 90 | +``` |
|
| 91 | + |
|
| 92 | +Note that you'll also want to ensure the XML file has been updated to |
|
| 93 | +reference these sounds: |
|
| 94 | + |
|
| 95 | +``` |
|
| 96 | + <sounds> |
|
| 97 | + <sound path="backgroundmusic.vsnd" /> |
|
| 98 | + <sound path="soundfx.vsnd" /> |
|
| 99 | + </sounds> |
|
| 100 | +``` |
|
| 101 | + |
|
| 102 | +### PACKING THE ROM |
|
| 103 | + |
|
| 104 | +Once all the components have been built, you can pack them together into |
|
| 105 | +a Vircon32 cartridge for use in the emulator via the `packrom` tool: |
|
| 106 | + |
|
| 107 | +``` |
|
| 108 | +yoursystem:~/src/SEMESTER/cprog/fwg2$ packrom fwg2.xml |
|
| 109 | +``` |
|
| 110 | + |
|
| 111 | +## SUBMISSION |
|
| 112 | + |
|
| 113 | +To be successful in this project, the following criteria (or their |
|
| 114 | +equivalent) must be met: |
|
| 115 | + |
|
| 116 | + * Project must be submit on time, by the deadline. |
|
| 117 | + * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline. |
|
| 118 | + * Executed programs must display in a manner similar to provided output |
|
| 119 | + * output formatted, where applicable, must match that of project requirements |
|
| 120 | + * Processing must be correct based on input given and output requested |
|
| 121 | + * Output, if applicable, must be correct based on values input |
|
| 122 | + * Code must be nicely and consistently indented |
|
| 123 | + * Code must be consistently written, to strive for readability from having a consistent style throughout |
|
| 124 | + * Code must be commented |
|
| 125 | + * Any "to be implemented" comments **MUST** be removed |
|
| 126 | + * these "to be implemented" comments, if still present at evaluation time, will result in points being deducted. |
|
| 127 | + * Sufficient comments explaining the point of provided logic **MUST** be present |
|
| 128 | + * No global variables (without instructor approval), no goto statements, no calling of main()! |
|
| 129 | + * Track/version the source code in your private semester repository |
|
| 130 | + * Submit a copy of your source code to me using the **submit** tool by the deadline. |
|
| 131 | + |
|
| 132 | +### SUBMIT TOOL USAGE |
|
| 133 | + |
|
| 134 | +Let's say you have completed work on the project, and are ready to |
|
| 135 | +submit, you would do the following: |
|
| 136 | + |
|
| 137 | +``` |
|
| 138 | +lab46:~/src/SEMESTER/cprog/fwg2$ make submit |
|
| 139 | +``` |
|
| 140 | + |
|
| 141 | +You should get some sort of confirmation indicating successful submission |
|
| 142 | +if all went according to plan. If not, check for typos and or locational |
|
| 143 | +mismatches. |
|
| 144 | + |
|
| 145 | +### RUBRIC |
|
| 146 | + |
|
| 147 | +I'll be evaluating the project based on the following criteria: |
|
| 148 | + |
|
| 149 | +``` |
|
| 150 | +286:fwg2:final tally of results (286/286) |
|
| 151 | +*:fwg2:code modified to meet project specifications [26/26] |
|
| 152 | +*:fwg2:grabit of project data by Sunday prior to duedate [26/26] |
|
| 153 | +*:fwg2:screenshot or video posted to class DISCORD of game running [26/26] |
|
| 154 | +*:fwg2:working collision detection between paddle and ball [26/26] |
|
| 155 | +*:fwg2:working collision between ball and individual bricks [26/26] |
|
| 156 | +*:fwg2:code makes use of an array to manage the bricks [26/26] |
|
| 157 | +*:fwg2:code uses a loop to transact the array [26/26] |
|
| 158 | +*:fwg2:source file, XML file, build script, and cartridge submit [26/26] |
|
| 159 | +*:fwg2:code compiles, cartridge builds with no warning or error [26/26] |
|
| 160 | +*:fwg2:committed project related changes to private semester repo [52/52] |
|
| 161 | +``` |
|
| 162 | + |
|
| 163 | +Additionally: |
|
| 164 | + |
|
| 165 | + * Solutions not abiding by spirit of project will be subject to a 50% overall deduction |
|
| 166 | + * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction |
|
| 167 | + * 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 |
|
| 168 | + * 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 |