Table of Contents

Corning Community College

CSCS1730 UNIX/Linux Fundamentals

PROJECT

PROJECT: Encoding Sprite Fun (esf0)

Objective

To configure an existing program that renders an image of a sprite to display a custom sprite.

Background

For this project, you will be working with C source code to alter the output of a given program.

Program

The program will be an exercise in exploration: you will be given some example code that does something. You should poke at it to gain deeper understanding. Then you will, taking out the demo graphics, lay out sprite:

  • 32×32
    • each symbol is a unique render (if you had 2 letter M's, both M's should look different)
    • the symbols are arranged to comfortably fill and fit within a canvas of 1280×1024 pixels
      • I don't want swaths of unused space
    • the image will utilize no fewer than 8 different colours
    • letters are to be entirely constructed out of blocks (filled but square rectangles), no smaller than 32×32 pixels a piece and no larger than 64×64 pixels (all blocks must be the same size)

Restrictions:

  • I don't want to see all simple symbols (4 L's, 4 I's, etc.)

On your pi

Develop and test this program on your pi. Only when done, verify that it compiles on lab46.

To utilize the needed functionality for this project, you will need to ensure you have the following packages installed:

  • build-essential (hopefully you took care of this in ntr0)
  • libgd-dev
  • libgd-tools
  • libgd3

Specifications

Your program should:

  • have valid, descriptive variable names of length no shorter than 4 symbols
  • have consistent, well-defined indentation (no less than 4 spaces per level of indentation)
    • all code within the same scope aligned to its indentation level
  • have proximal comments explaining your rationale and what is going on, throughout your code
  • perform the intended operation, outputting the correct/accurate information in indicated format
  • at the end of your main() function, use a single return statement to conclude your code, return a 0 indicating successful operation

Grabbing project resources

I have prepared a grabit for resources related to this project. To obtain:

lab46:~/src/SEMESTER/desig$ grabit desig lob0
make: Entering directory '/var/public/SEMESTER/desig/lob0'
'/var/public/SEMESTER/desig/lob0/Makefile' -> '/home/user/src/SEMESTER/desig/lob0/Makefile'
'/var/public/SEMESTER/desig/lob0/lob0.c' -> '/home/user/src/SEMESTER/desig/lob0/lob0.c'
make: Leaving directory '/var/public/SEMESTER/desig/lob0'
lab46:~/src/SEMESTER/desig$ 

At which point you can change into the newly created and populated lob0 directory.

Be sure to add, commit, and push this to your lab46 clone of your repository.

Then, on your pi, pull and update to get the files available there.

Compiling

Since the grabit brought in a Makefile, you can compile your code simply by typing: make

Any compiler errors will go into a text file called errors

To do a full cleaning, run: make clean then make (or make debug)

If you'd like to see compiler messages as you compile, run: make debug

When done and ready to submit, on lab46: make submit

Restrictions

To ensure a level playing field (should some happen to have some programming experience), I would like to restrict you from using:

  • selection statements of any kind (you're just manually placing a bunch of differently colored blocks)
  • loops of any kind (place everything manually, the benefit is exposing yourself to the problem)

Strategy

As with any process you are looking to describe or automate (in this case, both), if YOU do not personally understand or appreciate the steps involved, you are going to have a hard time communicating a proficient list of instructions to the computer to carry out.

So, the FIRST order of business would be to, BY HAND, ON A SHEET OF GRAPH PAPER (consider this your PROTOTYPE):

  • START EARLY: perhaps even while you are working on week 2's “pct2” project. Don't WASTE the abundance of time made available to you. Waiting until the last minute will only preserve frustration and confusion.
  • decide what letters/symbols you would like to “render”
  • practice plotting them out, figuring out which “squares” on the graph paper grid you would like to fill in
  • determine what a good ratio of blocks to screen size would be (holding a 11“x8.5” sheet of graph paper in landscape orientation would be a good fit for the 1280×1024 image you are placing everything within).
    • Figure out what blocks you need to fill in order to “best fit” your symbols within the allocated space (ie the sheet of graph paper representing your image size)
  • mark up your appropriately sized and filled out symbols with the different colors the project calls for
  • ONCE you have worked out your scheme by hand, you can THEN proceed to start playing with the provided code
    • determine what shapes are being rendered (view it in a web browser or image viewer)
    • make changes to the shapes. Experiment and develop an understanding of the coordinate system and how you can predictably impact the shape as it is rendered in the image
    • once you understand how to manipulate the shapes, remove the demo shapes and start laying down your own shapes
  • the provided code infrastructure may not be adequate for the demands of the project, and will need to be expanded in some areas
    • see if you understand the patterns of the existing infrastructure, and explore attempts to expand it to support your project aims
    • ASK QUESTIONS so as to maintain an understanding of what is going on

How to view the picture

Depending on your computing setup, choose the most practical means of viewing your program's image output:

Raspberry Pi desktop

You've got a monitor and keyboard hooked up to your pi that you are using (preferred method for class).

Open a file browser, web browser, or image viewer and navigate to/open up your lob0.png image in your ~/src/SEMESTER/desig/lob0/ directory.

Rinse and repeat as you go through revisions.

Raspberry Pi command-line via SSH/MOSH

You don't have a monitor, so you are logging into your pi remotely (doable, and good intra-system practice)

We start by running a successfully-compiled lob0:

yourpi:~/src/SEMESTER/desig/lob0$ ./lob0

… which will produce an image (lob0.png); You want to put this in your web space (with the proper permissions set), so you can view it in a web browser:

yourpi:~/src/SEMESTER/desig/lob0$ scp lob0.png yourusername@lab46.g7n.org:public_html/

Note that you will be prompted for your lab46 password.

Then over on lab46, run this:

lab46:~$ chmod 0644 ~/public_html/lob0.png

Then, point a web browser at the following URL:

NOTE: sometimes the web browser caches previous results, you may have to refresh a few times on revisions to get changes to manifest.

Submission

To successfully complete this project, the following criteria must be met:

  • Code must compile cleanly (no notes, warnings, nor errors)
  • Output must be correct, and match the form given in the sample output above.
  • Code must be nicely and consistently indented
  • Code must be well commented
  • Do NOT double space your code. Group like statements together.
  • Output Formatting (including spacing) of program must conform to the provided output (see above).
  • Track/version the source code in a repository
  • Submit a copy of your source code to me using the submit tool.

To submit this program to me using the submit tool, run the following command at your lab46 prompt:

lab46:~/src/SEMESTER/desig/lob0$ make submit

You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.

What I'll be looking for:

26:lob0:final tally of results (26/26)
*:lob0:post picture of prototype to #desig discord channel [6/6] 
*:lob0:post picture to #desig by Sunday before deadline [1/1]
*:lob0:grabit the code on lab46 by Sunday before deadline [1/1]
*:lob0:code is pushed to lab46 semester repository [6/6]
*:lob0:no negative compiler messages for program [6/6]
*:lob0:proper output formatting per specifications [6/6]

Additionally:

  • Solutions not abiding by spirit of project will be subject to a 25% overall deduction
  • Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
  • Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction
  • Solutions not organized and easy to read are subject to a 25% overall deduction
2022/01/24 20:23 · wedge