User Tools

Site Tools


Sidebar

projects

wcp1 (due 20250129)
abc0 (due 20250205)
btt0 (due 20250205)
pct0 (bonus; due 20250205)
pct1 (bonus; due 20250205)
pct2 (due 20250205)
wcp2 (due 20250205)
mtb0 (due 20250212)
pct3 (bonus; due 20250212)
wcp3 (due 20250212)
mtb1 (due 20250219)
pct4 (due 20250219)
wcp4 (due 20250219)
pct5 (bonus; due 20250226)
wcp5 (due 20250226)
mtb2 (due 20250227)
dap0 (due 20250305)
gfo0 (due 20250305)
pct6 (due 20250305)
wcp6 (due 20250305)
dap1 (due 20250312)
pct7 (bonus; due 20250312)
wcp7 (due 20250312)
bwp1 (bonus; due 20250326)
dap2 (due 20250326)
pct8 (due 20250326)
wcp8 (due 20250326)
mtb3 (due 20250402)
pct9 (bonus; due 20250402)
wcp9 (due 20250402)
haas:spring2025:comporg:projects:mtb0

Corning Community College

CSCS2650 Computer Organization

PROJECT: Move The Block (MTB0)

OBJECTIVE

Using the Vircon32 Development Tools, write a C program, compile, assemble, and pack a cartridge that uses a custom texture to display a block that moves around the screen (block changes in some attribute) as a result of directional keypresses.

EDIT

You will want to go here to edit and fill in the various sections of the document:

MTB0

NOTE: this is a collaborative document between a couple of my classes this semester. That means more people editing. Be mindful that only one person can edit the document at a time.

Only task headings have been provided. You are not expected to know how to do the task given by just that description (although in some cases it can be adequately figured out). Instead, if no further information is yet present, ASK FOR DETAILS on the discord, then contribute that clarity here.

If something is present but needs polish: spruce it up.

If something is present but is incorrect: please fix it.

This is intended to be an informative, useful document that all can benefit from.

Those with prior experience, please be mindful not to gobble up all the low-hanging fruit from the newcomers.

Design your sprites / custom texture

Designing your own sprites is how you can really make your project yours.
There are many tools you can use to create custom sprites
If you are willing to buy it or build it from source Aesprite is a great option
Another great option for those with Steam is Pixel Studio, which is free, although it does have some quirks to work around. (This is what i personally use and it works great)

Specifying Texture in XML

To get any textures into your cartridge other than the BIOS texture, you will need to add them into your .xml file
Adding textures will always follow the pattern of:

<textures>
    <texture path="FILENAME0.vtex" />
    <texture path="FILENAME1.vtex" />
    <texture path="FILENAME2.vtex" />
    ...
    <texture path="FILENAMEX.vtex" />
</textures>

When you go to use these textures in your code, the texture_id will follow the order of where they are in the xml, ie FILENAME0.vtex will have the texture_id 0
Note: In your directory you will have png files, not vtex, as they are an intermediate step between the files and the cartridge, so if you have 0_FirstImage.png, the xml will be:

<texture path="0_FirstImage.vtex" />
Selecting Texture

Vircon32 has built in functionality for working with any textures specified in the xml
To draw anything to the screen you need a few things:

  • Texture
  • Region
  • Location

The easiest portion to set up is the texture, as you only need the command

select_texture(texture_id);

where texture_id is the id of the texture you are using, which is determined by its position in the xml file

Defining Region

The next step to drawing a sprite to the screen is selecting the region of the texture you want to use.

Because regions are specified portions of a texture, you can use many commands to define them in different ways, however, all of the commands will follow a similar structure

The simplest command you can use is define_region_center(), which follows the structure:

define_region_center(min_x, min_y, max_x, max_y );

Where each argument corresponds to a coordinate on the .png file, that together draw a box containing your region.

As stated above, this command is not the only one, so you should also try experimenting with some of the others, which can be found in the C API reference on the Vircon32 website

Specifically this section:https://www.vircon32.com/api/video.html#Definition%20of%20texture%20regions

Selecting Region

It is simple to select a region. Use the command select_region() and pass the identifier of that region, ie. select_region(0);

Region Software

If you need more help visualizing the region process, the software provided by the creator of vircon32, linked below, can help. It visualizes the Region selection within an image that is provided to the software, and can even generate a header file for automation given the different parameters one would provide it. https://github.com/vircon32/ComputerSoftware/releases/tag/regioneditor-v25.1.6

Check for keypresses

Selecting joystick

In VirCon32 you can select a gamepad with

select_gamepad(int gamepad_id);

So for example:

select_gamepad(0);
Reading joystick value

You can get the X and Y values using:

int DirectionX, DirectionY;
gamepad_direction(&DirectionX, &DirectionY);
translating read joystick value into X and Y

You can also check explicitly for certain button presses instead of using gamepad_direction() with the gamepad functions, most pertinent to this project would be gamepad_left(), gamepad_right(), gamepad_up(), and gamepad_down().
These functions return a value based on how long the button is being pressed/how long it has been unpressed, decreasing starting from -1 every frame it is unpressed, and increasing starting from 1 every frame it is pressed; The value returned is never zero

Playfield bounds checking

Vircon32 screen resolution

Vircon32 has a screen resolution of 640×360, that is, 640 pixels across and 360 pixels vertically

How to check if our sprite has reached a bound

First, it is required to figure out what the bounds of the screen are. Within the video.h header, there are 2 provided definitions. screen_height, and screen_width. These are the borders of the screen.

Next, one needs to figure out how the coordinate plane is organized. The coordinate plane viewed within Vircon32 is within the confines of the first quadrant of the Cartesian plane, but there is a catch. 0,0 is at the top left, and the y-axis is flipped from what you would expect. Y increases as you move from top to bottom, and decreases as you move from bottom to top. X goes positive as you move to the right, and negative to the left.

How to limit our sprite from leaving the playfield

We can create minimum and maximum values that our box position can have (e. g. BoxMinX, BoxMaxY, etc…) and check to see if the box has reached these values or not in our main function. By creating another function and calling it after the Box's X and Y position have been calculated but BEFORE the box has been drawn we can update the box's position to ensure it does not leave our bounds. This separate function would compare the calculated X and Y values to the min and max values and update accordingly if the box has exceeded these values. Keep in mind if you want the sprite fully visible on screen you must account for that and slightly adjust your bounds from the standard screen_width and screen_height.

How to cause our sprite to wrap-around on the playfield
 

SUBMISSION

To be successful in this project, the following criteria (or their equivalent) must be met:

  • Project must be submit on time, by the deadline.
    • Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline.
  • Executed programs must display in a manner similar to provided output
    • output formatted, where applicable, must match that of project requirements
  • Processing must be correct based on input given and output requested
  • Output, if applicable, must be correct based on values input
  • Code must be nicely and consistently indented
  • Code must be consistently written, to strive for readability from having a consistent style throughout
  • Code must be commented
    • Any “to be implemented” comments MUST be removed
      • these “to be implemented” comments, if still present at evaluation time, will result in points being deducted.
      • Sufficient comments explaining the point of provided logic MUST be present
  • No global variables (without instructor approval), no goto statements, no calling of main()!
  • Track/version the source code in your lab46 semester repository
  • Submit a copy of your source code to me using the submit tool by the deadline.

Submit Tool Usage

Let's say you have completed work on the project, and are ready to submit, you would do the following:

lab46:~/src/SEMESTER/DESIG/PROJECT$ submit DESIG PROJECT file1 file2 file3 ... fileN

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.

RUBRIC

I'll be evaluating the project based on the following criteria:

78:mtb0:final tally of results (78/78)
*:mtb0:submitted Vircon32 cartridge [13/13]
*:mtb0:submitted XML and build script [13/13]
*:mtb0:displays unique block that moves based on direction [13/13]
*:mtb0:cartridge is NOT added to repository [13/13]
*:mtb0:an attempt at bounds check and block adjustment [13/13]
*:mtb0:committed project related changes to semester repo [13/13]

Pertaining to the collaborative authoring of project documentation

  • each class member is to participate in the contribution of relevant information and formatting of the documentation
    • minimal member contributions consist of:
      • near the class average edits (a value of at least four productive edits)
      • near the average class content change average (a value of at least 1024 bytes (absolute value of data content change))
      • no zero-sum commits (adding in one commit then later removing in its entirety for the sake of satisfying edit requirements)
    • adding and formatting data in an organized fashion, aiming to create an informative and readable document that anyone in the class can reference
    • content contributions will be factored into a documentation coefficient, a value multiplied against your actual project submission to influence the end result:
      • no contributions, co-efficient is 0.50
      • less than minimum contributions is 0.75
      • met minimum contribution threshold is 1.00

Additionally

  • Solutions not abiding by spirit of project will be subject to a 50% 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 or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction
  • Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction
  • Individuals who have not participated at least 50% will be subject to a 50% overall deduction.
2025/02/01 16:33
haas/spring2025/comporg/projects/mtb0.txt · Last modified: 2025/02/01 16:37 by 127.0.0.1