Late policy: The "6A checkpoint" will be graded out of 20 points; the "6B boss battle" will be graded out of 100 points. We will accept late submissions; however, for every day that a submission is overdue (including weekend days), we will subtract 10 points (for 6A) or 20 points from the total (for 6B). (We understand that sometimes multiple assignments hit at once, or other life events intervene, and hence you have to make some tough choices. We'd rather let you turn something in late, with some points off, than have a "no late assignments accepted at all" policy, since the former encourages you to still do the assignment and learn something from it, while the latter just grinds down your soul.) The due date was chosen so that the assignment will not be hanging over your head over Thanksgiving break, so you really want to have it done before you leave for Thanksgiving.
Hello and again welcome to the Aperture Science Xbox Multicorification Center. Your application for employment has been reviewed, and on the basis of your participation in the Georgia Tech class "Multicore and GPU Programming for Video Games," we have elected to detain you for further testing to determine your suitibility for employment as a Multicorifier.
Multicorifiers at the Aperture Science Xbox Multicorification Center are responsible for transforming legacy single-threaded game code into multi-threaded game code in preparation for the incorporation of enhanced features that would overwhelm a single-threaded implementation.
To demonstrate your 1337 multithreading skills, please find an interesting single-threaded XNA game that you would like to work on. Be sure to select a game with a design that emphasizes the real-time nature of the medium, such as an arcade game, a first-person or third-person shooter, a martial arts game, a real-time strategy game, sports game, flight simulator, etc., and not something like a Bejeweled or chess. If you choose something off the web, we recommend finding a program that works in XNA 2.0 and the Xbox 360 "out of the box." If you want to try to use an XNA 1.0 program, and/or one that is only claimed to work under Windows, realize that you may need to make some tweaks to get it to work in XNA 2.0 and on the Xbox 360, and these tweaks may be easy or difficult. Instead of finding a new game off the web, you are welcome to try using either your Homework #3 or your Homework #5; however, note that neither has been tested on the Xbox 360, so some tweaking might be required there. You are welcome to use the various Starter Kits such as Spacewar, or one off the Creator's Club website, but avoid games that are already extensively multithreaded (such as Rocket Commander and Racing Game).
Ideally, each applicant would be working on a diferent game, although we realize that the same game may be independenly chosen by multiple students.
Here are some links of places to start looking. Google may turn up more.
(Aperture Science in no way warrants the usefulness of the code available at any of the above links. Any particular piece of code may be full of bugs, poorly written, may not run on the PC, may not run on the Xbox 360, or may not compile at all.)
Spend some time looking at a different games and poking at a lot of source code before you commit to one, since you will be spending a lot of time with the source code of whatever game you pick. You do not need to pick something complicated; simpler games will be easier to multicorify.
You will probably wish to do most of your development and debugging on the PC, and then use appropriate compiler directives to set thread affinities for your Xbox 360 version. Your code must successfully run on the Xbox 360.
The five Xbox 360s in Klaus 1446 are available for your use. Note that over 30 other subjects are being tested for suitability as Multicorifiers. Please be courteous about sharing the limited resources available. In particular, do not expect to monopolize one of the 360s the day the project is due; we recommend trying to finish ahead of the due date. (If necessary, we may develop some sort of "signup" system where you may reserve a block of time on a 360, although this didn't seem to be a problem last year).
Modify your single-threaded example program to use multiple threads running on at least two cores by splitting the update logic and the rendering logic into separate threads running on separate cores. Modify the game state structures as needed to create a "double buffer" scheme so that the rendering thread and go about its rendering business on one buffer while the updating thread is writing to another buffer. Designing code that is intended to be multithreaded from the beginning is tricky; taking code that was never intended to be multithreaded and making it multithreaded, as we are doing here, can be even trickier. Simplicity is key. We will not be worried if your multithreaded implementation does not run any faster, since making it work at all without unpredicable bugs will likely prove sufficiently challenging. However, it should not run significantly slower.
You should feel free to make whatever other tweaks to the art assets or gameplay that you would like, although such tweaks are not required for this test.
Warning: As discussed in lecture, mMost peripheral I/O, such as loading and saving games or reading from the controller, seems to want to take place on the main thread. Peripherals such as those seem to be less accessible from spawned threads.
Remember, the Xbox 360s contain no user servicable parts. Do not submerge the Xbox 360s in liquid, even partially.
Deliverables: For the "4A checkpoint," please describe 1) what game you are modifying, including a URL pointer to the game, 2) a brief description of the most important game state structures, and 3) a brief discussion of which game state structures you will need to double buffer and which ones you won't. Upload a photo (a cheap camera cell phone or camera PDA photo will do) to T-square of an Xbox 360 running the game (showing it running in its original unmodified state is OK), with you next to it, smiling proudly, to prove that you can run the code on the Xbox 360. If you do not access to a digital camera, try to drag along a friend who does. If all else fails, you can show it running to Prof. Lanterman in person, but he would rather not make 30 appointments to meet in Klaus 1446, so surely you know someone with a camera? The purpose of this checkpoint is to make sure that you've picked a game, are able to deploy it on the Xbox 360, and have given some thought to multicorifying it.
For the "4B boss battle," upload a zip file with all the assets needed to compile and deploy your game on the Xbox 360. Include a README file of some sort that describes what changes you made to the code, why you made the choices you did, and what difficulties you encountered. Note that some of this may wind up being copied from your responses to (2) and (3) for the "4A checkpoint," or it may be entirely new material.
Note that we are not requiring that your final "4B boss battle" submission actually use the multicorifying strategy or even the same game that you described in the "4A checkpoint" submission. As you dig into your game while working on 4B, you may run into apparently insurmountable obstacles and choose to ditch it in favor of another game. We expect very few students will need to do this, however.
Be sure to finish sufficiently in advance of the deadline that you will be able to work around any troubles T-square gives you to successfully submit before the deadline. If you have trouble getting T-square to work, please try e-mailomg your compressed file to lanterma@ece.gatech.edu, with "MPG HW #6A" or "MPG HW 64B" and your full name in the header line; please only use this e-mail submission as a last resort if T-square isn't working. If e-mail doesn't work, put it on your webspace and e-mail Prof. Lanterman a link.
When you submit your 6B, please tell us an approximate number of total hours you spent working on it, as well your thoughts on the homework, particularly suggestions for improving it in the future. (If you don't have any suggestions, that's OK, just tell us an approximate number of hours.) This will help us with future offerings of the class.
Discussion board: We will set up a "HW #6" discussion board where students can discuss the homework and in particular ask questions that the professors and other students can help answer.
Ground rules: The ground rules on this assignment differ from the others. Since most people will be working on different code, you should feel free to look at one another's code in detail, ask others for help with debugging your code, brainstorm strategies for your paricular game with your friends, etc. The only exception to this rule is if you find that someone else happened to pick the same game as you; in this case, you should not be looking at each other's code, but you can discuss high-level issues. In your README file, be sure to give proper credit to people who helped you, i.e. "Thanks to such-and-such for helping me find the infinite recursion in blahblah.cs."
Also, if you use adapt code from other sources, be sure to credit the source both in your README and in the code itself.