haas/fall2026/cprog/projects/fwg0.md
... ...
@@ -78,7 +78,7 @@ Once you've compiled your code successfully, you can use the Vircon32
78 78
yoursystem:~/src/SEMESTER/cprog/fwg0$ assemble fwg0.asm -o fwg0.vbin
79 79
```
80 80
81
-### IMAGE CONVERSTION
81
+### IMAGE CONVERSION
82 82
83 83
Any PNG images you'd like to use need to be converted to Vircon32 texture
84 84
format via the `png2vircon` tool:
haas/fall2026/cprog/projects/fwg1.md
... ...
@@ -52,7 +52,7 @@ Once you've compiled your code successfully, you can use the Vircon32
52 52
yoursystem:~/src/SEMESTER/cprog/fwg1$ assemble fwg1.asm -o fwg1.vbin
53 53
```
54 54
55
-### IMAGE CONVERSTION
55
+### IMAGE CONVERSION
56 56
57 57
Any PNG images you'd like to use need to be converted to Vircon32 texture
58 58
format via the `png2vircon` tool:
haas/fall2026/cprog/projects/fwg2.md
... ...
@@ -58,7 +58,7 @@ Once you've compiled your code successfully, you can use the Vircon32
58 58
yoursystem:~/src/SEMESTER/cprog/fwg2$ assemble fwg2.asm -o fwg2.vbin
59 59
```
60 60
61
-### IMAGE CONVERSTION
61
+### IMAGE CONVERSION
62 62
63 63
Any PNG images you'd like to use need to be converted to Vircon32 texture
64 64
format via the `png2vircon` tool:
haas/fall2026/cprog/projects/fwg3.md
... ...
@@ -109,7 +109,7 @@ Once you've compiled your code successfully, you can use the Vircon32
109 109
yoursystem:~/src/SEMESTER/cprog/fwg3$ assemble fwg3.asm -o fwg3.vbin
110 110
```
111 111
112
-### IMAGE CONVERSTION
112
+### IMAGE CONVERSION
113 113
114 114
Any PNG images you'd like to use need to be converted to Vircon32 texture
115 115
format via the `png2vircon` tool:
haas/fall2026/cprog/projects/fwg4.md
... ...
@@ -0,0 +1,280 @@
1
+# CSCS1320 C/C++ Programming
2
+
3
+# PROJECT: FUN WITH GAMES (fwg4)
4
+
5
+## OBJECTIVE
6
+
7
+Using your Vircon32 build and installation from fwg0, and the game
8
+foundations from fwg1, fwg2, and fwg3, implement a simple 2D game using
9
+**C++ classes**. This project introduces the `v32c++` C++ transpiler,
10
+which allows you to write object-oriented code that is translated into
11
+C code the Vircon32 `compile` tool can understand.
12
+
13
+Your game can be an OOP reimagining of one of your earlier efforts
14
+(pong, breakout, or your fwg3 game) or something entirely new. Where
15
+fwg3 grouped related data into structs, here you will go a step further:
16
+bundle the data **and** the operations on that data into classes, and
17
+use access control (`public` / `private`) to protect the internal state
18
+of your objects.
19
+
20
+## THE V32C++ TRANSPILER
21
+
22
+The Vircon32 `compile` tool only understands C. The `v32c++` transpiler
23
+bridges the gap: it takes your C++ source (`.cpp`), and translates it
24
+into plain C (`.c`), which then enters the normal build pipeline.
25
+
26
+NOTE: you should already have installed `v32c++` per the instructions
27
+given in class. If you have not, do so now, **outside** of your
28
+repository (just as with `Vircon32` and `DevTools`). Do **NOT** add the
29
+`v32c++` source or binaries to your repository!
30
+
31
+Verify the installation works by running it from the command line:
32
+
33
+```
34
+yoursystem:~$ which v32c++
35
+yoursystem:~$ v32c++ --help
36
+```
37
+
38
+Should either command fail, check that the install location is in your
39
+`PATH` (the same way you did for the DevTools), and consult the class
40
+notes / Discord for troubleshooting.
41
+
42
+Since the transpiler is not a full C++ compiler, expect some limitations
43
+on which C++ features are available. Stick to the basics we've covered:
44
+classes, constructors, member functions, and public/private sections.
45
+When in doubt, **keep it simple**, and test early and often (compile
46
+after every small change, rather than writing everything at once).
47
+
48
+NOTE: the first gamepad by default is mapped to the keyboard
49
+
50
+## PROGRAM
51
+
52
+You are to write a Vircon32 C++ game that:
53
+
54
+ * has a player-controlled object, moved via the gamepad
55
+ * has at least one other kind of game object (enemy, obstacle,
56
+ ball, projectile, pickup, etc.) that acts on its own
57
+ * detects collisions between objects, with a meaningful result
58
+ * keeps a score (or lives, or timer) displayed or otherwise tracked
59
+ * has a win and/or lose condition (even if it simply resets)
60
+ * is built around classes:
61
+ * define at least TWO distinct classes in your game, for example
62
+ a player class and an enemy/ball/projectile class
63
+ * each class has **private** member data (position, velocity,
64
+ size, and an active/alive flag at a minimum, as relevant to
65
+ your game); code outside the class must NOT touch these directly
66
+ * each class has **public** member functions to operate on that
67
+ data, including:
68
+ * a constructor to initialize the object into a valid state
69
+ * accessor ("getter") functions to read private data
70
+ * mutator ("setter") or behavior functions to change private
71
+ data (such as `move()`, `update()`, `bounce()`, `reset()`)
72
+ * a function to draw the object to the screen
73
+ * create objects (instances) of your classes in your game
74
+ * `main()` should primarily coordinate the objects: let the objects
75
+ do the work via their member functions
76
+
77
+NOTE: you are free to use arrays of objects if your game calls for it,
78
+but the emphasis of this project is on the design and use of the classes
79
+themselves, and the separation of public interface from private data.
80
+
81
+## CLASS REMINDERS
82
+
83
+A quick example of the sort of thing we are after (yours will differ):
84
+
85
+```
86
+class Sprite
87
+{
88
+ private:
89
+ int x; // where it is on screen
90
+ int y;
91
+ int dx; // how it moves each frame
92
+ int dy;
93
+ int active; // is it currently in play?
94
+
95
+ public:
96
+ Sprite(int startx, int starty)
97
+ {
98
+ x = startx;
99
+ y = starty;
100
+ dx = 0;
101
+ dy = 0;
102
+ active = 1;
103
+ }
104
+
105
+ int getX() { return x; }
106
+ int getY() { return y; }
107
+
108
+ void setVelocity(int newdx, int newdy)
109
+ {
110
+ dx = newdx;
111
+ dy = newdy;
112
+ }
113
+
114
+ void move()
115
+ {
116
+ x += dx;
117
+ y += dy;
118
+ }
119
+};
120
+```
121
+
122
+Remember: use the dot operator (`.`) with an object variable, and the
123
+arrow operator (`->`) with a pointer to an object. Members declared
124
+`private` are only accessible from within the class's own member
125
+functions; everything else must go through the `public` interface.
126
+
127
+## CARTRIDGE BUILD PROCESS
128
+
129
+All of these steps can be automated with the use of the provided
130
+`Makefile` simply by typing `make` at the prompt.
131
+
132
+NOTE that with certain modifications, you'll first need to modify the XML
133
+file as appropriate.
134
+
135
+### TRANSPILE
136
+
137
+First step is to transpile your C++ code into C, with the `v32c++` tool
138
+(consult `v32c++ --help` for the exact options of your installed
139
+version):
140
+
141
+```
142
+yoursystem:~/src/SEMESTER/cprog/fwg4$ v32c++ fwg4.cpp -o fwg4.c
143
+```
144
+
145
+This translates your C++ code into a C file, which will then be compiled
146
+like any other Vircon32 C program. Do **NOT** track the generated `.c`
147
+file in your repository; it is a build product (the `.cpp` is your
148
+source code).
149
+
150
+### COMPILE
151
+
152
+Next, compile the generated C code with the Vircon32 developer tools C
153
+compiler (`compile`):
154
+
155
+```
156
+yoursystem:~/src/SEMESTER/cprog/fwg4$ compile fwg4.c -o fwg4.asm
157
+```
158
+
159
+This compiles, or translates, the C code into Vircon32 assembly language
160
+code, which will then need to be assembled to machine code:
161
+
162
+### ASSEMBLE
163
+
164
+Once you've compiled your code successfully, you can use the Vircon32
165
+`assemble` DevTool to assemble the assembly:
166
+
167
+```
168
+yoursystem:~/src/SEMESTER/cprog/fwg4$ assemble fwg4.asm -o fwg4.vbin
169
+```
170
+
171
+### IMAGE CONVERSION
172
+
173
+Any PNG images you'd like to use need to be converted to Vircon32 texture
174
+format via the `png2vircon` tool:
175
+
176
+```
177
+yoursystem:~/src/SEMESTER/cprog/fwg4$ png2vircon background.png -o background.vtex
178
+yoursystem:~/src/SEMESTER/cprog/fwg4$ png2vircon sprites.png -o sprites.vtex
179
+```
180
+
181
+Note that you'll also want to ensure the XML file has been updated to
182
+reference these textures:
183
+
184
+```
185
+ <binary path="fwg4.vbin" />
186
+ <textures>
187
+ <texture path="background.vtex" />
188
+ <texture path="sprites.vtex" />
189
+ </textures>
190
+```
191
+
192
+### AUDIO CONVERSION
193
+
194
+Should you have any WAV files you'd like to use need to be converted to
195
+the Vircon32 sound format via the `wav2vircon` tool:
196
+
197
+```
198
+yoursystem:~/src/SEMESTER/cprog/fwg4$ wav2vircon backgroundmusic.wav -o backgroundmusic.vsnd
199
+yoursystem:~/src/SEMESTER/cprog/fwg4$ wav2vircon soundfx.wav -o soundfx.vsnd
200
+```
201
+
202
+Note that you'll also want to ensure the XML file has been updated to
203
+reference these sounds:
204
+
205
+```
206
+ <sounds>
207
+ <sound path="backgroundmusic.vsnd" />
208
+ <sound path="soundfx.vsnd" />
209
+ </sounds>
210
+```
211
+
212
+### PACKING THE ROM
213
+
214
+Once all the components have been built, you can pack them together into
215
+a Vircon32 cartridge for use in the emulator via the `packrom` tool:
216
+
217
+```
218
+yoursystem:~/src/SEMESTER/cprog/fwg4$ packrom fwg4.xml
219
+```
220
+
221
+## SUBMISSION
222
+
223
+To be successful in this project, the following criteria (or their
224
+equivalent) must be met:
225
+
226
+ * Project must be submit on time, by the deadline.
227
+ * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline.
228
+ * Executed programs must display in a manner similar to provided output
229
+ * output formatted, where applicable, must match that of project requirements
230
+ * Processing must be correct based on input given and output requested
231
+ * Output, if applicable, must be correct based on values input
232
+ * Code must be nicely and consistently indented
233
+ * Code must be consistently written, to strive for readability from having a consistent style throughout
234
+ * Code must be commented
235
+ * Any "to be implemented" comments **MUST** be removed
236
+ * these "to be implemented" comments, if still present at evaluation time, will result in points being deducted.
237
+ * Sufficient comments explaining the point of provided logic **MUST** be present
238
+ * No global variables (without instructor approval), no goto statements, no calling of main()!
239
+ * Track/version the source code in your private semester repository
240
+ * Submit a copy of your source code to me using the **submit** tool by the deadline.
241
+
242
+### SUBMIT TOOL USAGE
243
+
244
+Let's say you have completed work on the project, and are ready to
245
+submit, you would do the following:
246
+
247
+```
248
+lab46:~/src/SEMESTER/cprog/fwg4$ make submit
249
+```
250
+
251
+You should get some sort of confirmation indicating successful submission
252
+if all went according to plan. If not, check for typos and or locational
253
+mismatches.
254
+
255
+### RUBRIC
256
+
257
+I'll be evaluating the project based on the following criteria:
258
+
259
+```
260
+260:fwg4:final tally of results (260/260)
261
+*:fwg4:code modified to meet project specifications [26/26]
262
+*:fwg4:screenshot or video posted to class DISCORD of game running [26/26]
263
+*:fwg4:at least two distinct classes defined and used [26/26]
264
+*:fwg4:classes use private member data and public member functions [26/26]
265
+*:fwg4:constructors, accessors, and behavior functions implemented [26/26]
266
+*:fwg4:working collision detection between game objects [26/26]
267
+*:fwg4:game has scoring (or lives/timer) and a win/lose condition [26/26]
268
+*:fwg4:v32c++ transpile step integrated into build process [26/26]
269
+*:fwg4:game uses at least one texture and one sound [13/13]
270
+*:fwg4:source file, XML file, build script, and cartridge submit [13/13]
271
+*:fwg4:code compiles, cartridge builds with no warning or error [13/13]
272
+*:fwg4:committed project related changes to private semester repo [13/13]
273
+```
274
+
275
+Additionally:
276
+
277
+ * Solutions not abiding by spirit of project will be subject to a 50% overall deduction
278
+ * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
279
+ * 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
280
+ * 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