Given a simulation of balls bouncing, implement stop and restart features. This involves converting a single-threaded program into a two-threaded program.

Details:

• By `stop', it is meant that the simulation will stop updating and the balls will remain in their current location.
• By `restart', it is meant that the simulation will continue from the ball configuration as it was at the point when the simulation was stopped.
• One also needs to worry about what happens if the buttons are pressed in the wrong order or if one button is pressed twice in a row.
• The messages in the label at the top of the applet should be updated in response to the button presses to reflect the messages shown in the Sample Run below.
• All of the code you write is required to be in the file named Homework4.java.
• The provided copy of Homework4.java is 4 lines long and merely provides a connect from the provided applet Homework4.html to the TheGUI class. As is, once the simulation is started, the buttons cannot be used to stop it. If you did not launch the appletviewer into background, then a control-C in the xterm where the appletviewer was launched will kill it. If it was launched into background, then you will need to use the `jobs' command to find out its job id and then do a `kill -9 ...' to kill the job (where ... is replaced by a percent sign immediately followed by the job number).
• You are required to use the CS342.Hwk4 package via importing it rather than copying it to your work space. The same CLASSPATH from Homework 3 should work here fine.
• You are required to implement the Homework4 class as an extension of TheGUI class. You may implement other classes as needed. Where possible you should make maximum use of the code in CS342.Hwk4 to minimize the amount of stuff you have to write yourself.
• On Gaul, you can find the source files and test data you need in: /gaul/s1/usr/faculty/webber/CS342/Homework4. These should be all you need to copy to your workspace.
• If you are running on a home computer, in addition to the above stuff, you are also going to need to copy the stuff in /gaul/s1/usr/faculty/webber/classes and install it on your home machine.
• This is to be done as an applet.
• No error messages are generated by the application.
• It is sufficient if your program works on either Java 1.0.2 or Java 1.1.3. Of course, if we should try to run your program, it will be the Solaris JDK implementations of these versions that we will use to verify whether or not your code works.

Handin Requirements

• What to hand in
  • You will need to handin your modified source file Homework4.java (the other source files you may not change and you may not use any additional source files, so there is no need to hand in any other source files).
  • On the hardcopy version only, it is required that a test run be shown. This involves taking four screen captures of the program running during a single run (no restarts). The printouts of these screen captures should be clearly labelled.
    • Screen Capture 1 shows the screen before any buttons have been pushed.
    • Screen Capture 2 shows the screen after the righthand button has been pushed (following Screen Capture 1).
    • Screen Capture 3 shows the screen after the lefthand button hs been pushed (following Screen Capture 2).
    • Screen Capture 4 shows the screen after the righthand button has been pushed (following Screen Capture 3).
    Screen captures can be done using the same method as in Homework 3.
  • It is perfectly fine to use your home printers as long as they are readable.
  • Issues relating to documentation requirements are the same as for the third homework. See reminder from TA in Overheads file.
  • The hardcopy version must be in an 8.5x11 envelope if it is being handed in in the locker. If it is being handed in in class, it is ok if it is just stabled together (2 stables) or in a report folder (clasped). Loose pages or pages held together only be a paperclip are too easy to get mixed up together. Envelops that are not 8.5x11 make the pile of assignments difficult to sort through and should not be used. Your name should appear clearly on the outside cover of whatever you are handing in, as well as on each page.
  • For online handin, use CS342HandinFromGaul as was done for Homework 1.
• When to hand it in: the process is the same as for the second homework.

Reference:

The text discussion of Threads is quite sufficient for this assignment. The Pendulum program can be consulted as an example.

Sample Run:

• Using appletviewer, the following would be the test run that I would hand in:
  • Screen Capture 1

    

  • Screen Capture 2

    

  • Screen Capture 3

    

  • Screen Capture 4

    

Hints:

• Before comments (but with blank lines for spacing), my code was 61 lines long. After comments, it was 107 lines long (this included the dashed line comments the TA wants).
• It would seem natural to use suspend() and resume() for this application, but because the canvas and the buttons are part of the same applet thread, suspending the canvas can also freeze the buttons (meaning you never get a chance to resume).
• As a result of the above, I implemented the stop/restart feature by extending the canvas updater so that a flag could control whether a real update was done or a short sleep was done instead (by a short sleep, I mean the sleep length that the original code used to idle while waiting for the next time interval to start).
• Although this assignment does involve threads, it also involves more extensive use of subclassing than previous assignments. My solution involved me defining 3 classes (a thread class and two subclasses of CS342.Hwk4 classes) and 6 methods (each of which was either a constructor or overrided a method defined in a superclass).

Side Notes:

• The code in the CS342.Hwk4 package was broken up into 9 classes and many small methods to facilitate reuse. Before commenting, it contained 434 lines of code.
• The collisions sometimes look a bit odd. This is because the disks are modelled as point sources and upon collision simply swap their velocity vectors.
• Although the simulation moves a bit slower than one would like, it avoids the flicker problem that the Pendulum code had. When running under Unix, most of the screen updates occurred in just a millisecond -- so plenty fast. However, the program got swapped out a few times per second causing the motion to appear ragged.
• On Solaris, you can use the command `top' to monitor the machine usage. This program appears to be something of a CPU hog and so shouldn't be run more than is needed for testing purposes.
• This code began life as the start of the development of a game. The idea for the game was that there would be two groups of 3 disks bouncing around on the screen (each group representing a player). There would be a circle twice the width of a disk at the center of the screen. The score for a player would be the amount of time that this center circle was occupied by disks that were all from the player's group. Players could influence the game by moving around a square whose width was half the width of a disk. The squares could be moved around while the simulation was running, but would only interact with the disks when they had been left in place for 30 milliseconds. There would be a circle four times the width of a disk centered on the other circle marking a boundary within which neither player could place their square. A line would divide the court in half with each player having to keep their square on their own half. A single player version of the game could be implemented by extending the current program. A two player version would require network communication (as Java doesn't appear to support workstations with two mice).
• The above goal was the reason why the WorldElement abstract class was created. It was hoped that the squares would become a second subclass of this class when they were implemented.