In this lab, you will implement a C++ linked list and then use that linked list to store a movie. Specifically, each node will represent one frame of the film as a string. You will then create a movie player program that will load a movie into a linked list and perform some basic operations for playing and editing the film.

To get started, run update35 from a computer science lab computer. The program update35 will create a cs35/labs/04 directory in your CS home directory, and the program handin35 will subsequently submit files from that directory.

You may choose one partner for this lab. Both partners should be present and working on the code together. You will both be responsible for understanding all concepts, so dividing and conquering is not an option. The academic integrity policy applies to the entire pair; you cannot work or share code with anyone outside of your partner. Also, be sure to indicate who your partner is by including both names at the top of your files and by also selecting the 'p' option when using handin35 for the first time. Only one student in the pair should submit the lab.

You will earn reasonable partial credit for this lab if you complete and test your linked list implementation. So be sure to work in a modular fashion, testing and completing your linked list first before implementing the main program

This lab is inspired by a late-90s internet phenomenon known as ASCII-mation (head here to see Star Wars as you've never seen it before). Most of you are familiar with ASCII art, where basic characters and symbols are pieced together to represent an image. ASCII-mation takes this a step further by placing a series of ASCII images one after another until it looks like a movie. In this lab, you will create a movie player that will load an ASCII-mation movie and allow a user to perform some basic functionalities including general playing features (playing, pausing, stopping, fast forwarding, and rewinding) and basic editing features (deleting scenes or reversing playback).

As mentioned above, you will represent a movie as linked list of frames. You will then use basic linked list operations to implement the basic functionalities listed above for a movie player/editor. Most of the file format/playing features have been provided for you. One frame of the image will look similar to the following:

31
                 -===                    `"',
                ""o o                    O O|)   Going somewhere,
                _\ -/_                  _\o/ _        Solo?
               /| || |\                /|\ / |\
              //| || |\\              //| |  |\\
             || | || | \\            // | |  | ||
             || |/  \|  \\        -==#  | |  | ||
             |! |====|   ')         '\  |====| /#
             =] |/|| |                  | || |  "
              I ( )( )                  | || |
                |-||-|                  | || |
                | || |                  | || |
________________[_][__\________________/__)(_)_____________________

We will represent the text for the frame as one large string. The value in the upper left-hand corner (e.g., 31) is to compress the file size. It represents how many frames in a row looked the same as this. The movie has been filmed at 15 frames a second, so a value of 31 means that this image appears on the screen for 31 frames, or just over 2 seconds.

Here, I list the requirements for each major component of the lab. See the IMPLEMENTATION STRATEGY section below for hints on how to begin attacking the problem.

You have been given the following files (blue indicates you will need to modify/implement in this file):

• movieList.h - the MovieList interface. This file should not be modified
• movieLinkedList.h, movieLinkedList.cpp - the declaration and definition of the MovieLinkedList class. You will need to implement both files.
• frameNode.h, frameNode.cpp - the declaration and definition of the FrameNode class. These files should not be modified.
• testLinkedList.cpp - a partially completed test file for the FrameNode class. You will need to implement your tests here. You should start here by filling out more tests to understand how a FrameNode works. You should then use this file to test out every aspect of your MovieLinkedList class as you implement it.
• player.cpp - the main program for playing a movie. This has been started for you; implement a main while loop here and handle any cleanup after the loop finishes. Most of the functions you will call will be defined in...
• movie.h,movie.cpp - where the majority of your functionality will be implemented. Note that this is not a class, but rather a file of function declarations and definitions. You will need to complete loadMovie and implement additional functions.
• scenes/ (scene1.ani, scene2.ani, scene3.ani) - small scenes for testing your program. Made available by Andrew Horner
• scenes/starwars.ani - Episode IV in all of its glory, DO NOT TEST WITH THIS FILE! Think of it as a reward for all of your hard work.
• Makefile - use to compile your code. Initially, this only compiles the FrameNode class testLinkedList.cppM. You will need to modify this once you want to test your MovieLinkedList.

MovieList

I have provided a MovieList interface, very similar to the StringList interface given in lecture. A MovieList defines the normal list functionality, but adds remove (removes the data at position i) and a playFrom method specific to this task. Recall that the interface is not the implementation, so we could theoretically use either arrays or linked lists to implement a MovieList.

You must define and implement a MovieLinkedList class that implements the MovieList interface, without altering the MovieList interface.

MovieLinkedList (and its Requirements)

Don't worry about the movie-specific aspects at first; this class will largely be the same as any other linked list implementation. Begin by thinking about your algorithms in pseudocode and then implement them one-by-one. MovieLinkedList header file. Some requirements to note:

• You should not add any extra public methods to the MovieLinkedList interface than what is already specified in the MovieList interface.
• You may, however, add as many private methods as you desire.
• The class should only contain variables necessary for maintaining the linked list. Do not declare local variables in the class declaration.
• Your methods should be safe. That means that it should not rely on a user of the class to avoid making mistakes, such as removing a non-existent item. In the case that the class-user attempts something illegal, you should throw a runtime_error with a descriptive message (see the ArrayStringList implementation from class and the Tips and Hints section below).
• Your implementation must manage dynamic memory allocation properly. No memory leaks!
• You must modify your testLinkedList.cpp file to make sure your MovieLinkedList implementation is working. The ninjas will ask you to show your test file to help you with errors.
• playFrom has largely been implemented for you. You do not need to handle the actual movie playing -- that has been provided for you using some unix-specific features. Simply replace each TODO with one or two lines of code to finish up the function.

Main Player Program (and its Requirements)

Once you have thoroughly tested your MovieLinkedList implementation, you should implement the main program. The program has been started for you. To keep the program clean, we have divided the main program into three files. player.cpp only contains the main loop. Modify this to get it working, but any large implementation details should be done in the helper files. Those details should use good top down design (e.g., one function per feature). Any functions should be declared and defined in movie.h/.cpp respectively. We have provided getChoice() for you as an example. To complete the main program:

• Your main function will need to maintain a few data items. At a minimum, you will need to have the film stored as a MovieList and the current frame in the movie. Your MovieLinkedList should not store the current frame number, only main should. Note that playFrom returns the frame number every time you pause.
• Begin by finishing loadFilm, which reads the sequence from a file. Most of the messy file reading details have been provided. Read and understand it. You only need to add a few lines to add each frame to the MovieList. Recall that each frame stays up for a different duration; you will simulate this by adding a given frame to the linked list multiple times.

Take a look at getChoice() to see what options the user has. You should implement each option appropriately in the main while loop. These include:

• (0) Get Movie Status - prints the name of the file and the current pause point (i.e., frame number) of play back. You should convert the frame number into real time (15 frames per second) when outputting the status. An example response would be:

  You are watching scenes/starwars.ani  
  You are currently at 0hr 0min 0sec
  

• (1) Play Movie - begin playing the movie from the previous pause point (i.e., stored frame). When the user pauses, store the frame number where play back halted.
• (2) Stop Movie - stop the movie by reseting the counter to 0. Note that this can only be done after the movie has been paused DO NOT exit the program.
• (3) Fast Forward - ask the user how many seconds to move forward in the film and adjust the pause point accordingly. Error check the user input - it should not be negative or go past the end of the movie. If it does, ignore the request.
• (4) Rewind - the same, but move backwards.
• (5) Cut Trailers - eliminate 1 second from the beginning of the movie (i.e., 15 frames).
• (6) Cut Credits - eliminate 1 second from the end of the movie
• (7) Delete Current Scene - delete one second from the current pause point.
• (8) Reverse Movie -take the existing movie reel and flip it backwards. This is permanent, so the original movie reel should be replaced by a backwards one. Be careful with memory management; be sure to reset the pause point to 0.
• (9) Exit - add a message thanking the user for using your program and let your main function end normally.

A couple pointers when implementing these methods:

• Keeping track of the current pause point can be a bit tricky. Be sure to consider its status after each of the menu options above. In particular, the pause point may need to be adjusted when you delete frames (e.g., if you delete the trailers while in the middle of the movie, you should shift the pause point back a second).
• The pause point should never exceed the number of frames in the movie.
• The pause point should never go below 0.
• Whenever you delete frames, make sure that frame actually exists. This applies to all three delete methods.

You should always program incrementally such that you can test your work as you go. Here is one suggested strategy:

1. Start by testing the FrameNode class in testLinkedList.cpp. Can you create a few nodes? Link them together? Print all the items? I have provided the beginning of a program to do this.
2. Begin declaring the MovieLinkedList class in movieLinkedList.h. Remember that you must declare all data members and at least all methods specified in the MovieList interface before proceeding.
3. Begin implementing your class in movieLinkedList.cpp. I suggest stubbing all functions (that is, defining the function and giving a dummy return value). This will let you compile the class properly without having done any actual implementation. An example function stub is:

   /* get - returns the value for the ith item in the list
      @param i, an int for the index of the frame to return
      @return a string containing a scene from the film
   */
   string MovieLinkedList::getFrame(int i){
   
     //TODO: implement this
    
     return "EXAMPLE FRAME";
   }
   

4. Check to see if your class compiles, fix any errors before proceeding. Now, begin implementing one method at a time. I suggest starting with insertAtHead or insertAtTail. Your procedure should be: implement one method, compile, and then test it in testLinkedList.cpp
5. Implement the destructor last. Carefully consider every possible way that your class might allocate memory on the heap, and be sure that there is a corresponding call to delete for each call to new.

At this point you should have a complete working MovieLinkedList class.

You should not under any circumstances begin the movie player implementation until you have thoroughly verified the correctness of your MovieLinkedList class. Any bugs in your MovieLinkedList class will hinder progress on the main program. Begin working on player.cpp by implementing and testing one feature of the program at a time. Be sure that your solution follows good design/modularity guidelines.

Throwing and Handling Exceptions

Your linked list should handle invalid usage by throwing a runtime_error. There is an example in the playFrom method in movieLinkedList.cpp as well is in the ArrayStringList implementation from class. For example, if you may want to handle an attempt to get an invalid item:

throw std::runtime_error("Attempt to get out of bounds");

Here is an example of handling a runtime_error (not required in this lab):

try{
  //do something dangerous
} catch (runtime_error& exc){
  cerr << "Warning: " << exc.what() << endl;
  cerr << "Ignoring illegal behavior." << endl;
}

Don't forget to include the stdexcept library when handling or throwing exceptions.

Once you are satisfied with your program, hand it in by typing handin35 at the unix prompt.

You may run handin35 as many times as you like, and only the most recent submission will be recorded. This is useful if you realize after handing in some programs that you'd like to make a few more changes to them. Only one partner should hand in the code for the lab.