Jezzball

subglobal1 link | subglobal1 link | subglobal1 link | subglobal1 link | subglobal1 link | subglobal1 link | subglobal1 link
subglobal2 link | subglobal2 link | subglobal2 link | subglobal2 link | subglobal2 link | subglobal2 link | subglobal2 link
subglobal3 link | subglobal3 link | subglobal3 link | subglobal3 link | subglobal3 link | subglobal3 link | subglobal3 link
subglobal4 link | subglobal4 link | subglobal4 link | subglobal4 link | subglobal4 link | subglobal4 link | subglobal4 link
subglobal5 link | subglobal5 link | subglobal5 link | subglobal5 link | subglobal5 link | subglobal5 link | subglobal5 link
subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link
subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link

Results

small logo

Speed of Execution and Accuracy:

Overall our program works well no issues of flickering or artifacts on the screen. There is no noticeable delay from the point that the user moves the mouse to the moving of the mouse on the screen. There is a limit in the processing time on the TV MCU; we know that we never crossed the limit (which includes the time it takes to transmit the data from the mouse via the SPI) because everything draws fine on the TV. When we did need to go over the limit of doing more logic than we could, we staggered the computations over multiple frames. Since each frame is 1/60 of a second, this provides a way of drawing multiple lines quickly while not taking too long. Since we are sending 3 bytes of data from the mouse MCU to the game MCU 60 times a second, we are able to achieve a very accurate mouse pointer.

Safety and Interference

Our project is very safe. We use a standard black and white television which has its own safety considerations due to the possibility of causing seizures but we do not use any flashing effects so this effect is very minimal. The only other safety concern would be possibly from the wiring of the mouse to MCU and MCU to MCU wiring. We tried to minimize the amount of loose wiring/exposed wiring to reduce the risk of electric shock. As you can see from the screen shots of our circuits, our wiring is done as neatly as possible and we put as many components on the board (ie the small circuit needed to generate the TV signals) so that it limits the amount of exposed metal. Also, our circuit runs at 5 volts so even in the unlikely event of a shock from our circuit would cause minimal injury.

Our circuit does not generate any R/F noise and did not interfere with anybody else’s project in the lab while we were testing. The only possibility of interference would be from the television and the MCU CPU. However, these are very minimal and we did not notice any interference with other projects.

Usability

Our project is very usable. It can be used to provide entertainment for hours. We’ve enjoyed playing this game many years ago and we believe our implementation of the game provides a similar amount of playing use.

The mouse is intuitive to use and our simple design only utilizes the left and the right mouse click. It is very simple to pick up and anyone who tries our game will be able to play within minutes even if they have never played Jezzball before. We start with a menu screen and cursor to select options. The user knows which option they are currently on by an arrow on the left side. When the user clicks start, the game begins and they can begin playing. The left mouse button will generate a cut in the current orientation and the right mouse button changes the direction of the cursor. The user clicks on the left mouse button to progress through certain screens (like the win/lose screens).

ECE 476 Yewen Ying, Arthur Zhang