Sergio’s Slime Sprite:
From Novice Sketch to Teaching Showcase

A hiring manager reviewing this file would count ten distinct unnamed numeric literals scattered across five functions. In the refactored version, every one of these becomes a named constant in an organized constants section at the top of the file. Here is the complete inventory:

The most instructionally valuable thing in the entire app is this line inside drawPlayer():

image(idle, x, y, this.size*1.2, this.size*1.2,
      idle.height * floor(this.frame), 0,
      idle.height, idle.height);

This is the nine-parameter form of p5.js image() — the sprite-sheet crop technique. It says: “draw the idle image at position (x, y), sized to this.size × 1.2 on screen, but crop from the source image starting at x = idle.height × floor(this.frame), y = 0, for a region idle.height wide and idle.height tall.”

This assumes the sprite sheet has square frames (width = height per frame), and that frames are arranged left-to-right. The variable this.frame advances from 0 to 1.9 in steps of 0.05, and floor() snaps it to frame index 0 or 1 — giving a two-frame animation. This technique is the primary CS concept the refactored sketch teaches. In v2, it has zero comments. The refactored Player.js will explain it completely.

When the Player class is ported to Java and Python, these constants become the primary reference for anyone translating the behavior. Named constants survive translation; magic numbers require re-discovery in every language.

When this sketch is ported to Java Processing and Python Processing, the following concepts must be visible and named in the JavaScript version so translators can find the equivalent in each language:

Note: Python Processing has no built-in PVector equivalent; positions and velocities become plain float variables or a simple custom class. This is itself a cross-training lesson: the same concept (velocity-based movement) is expressed differently depending on what the language provides.

The showcase page has two independent code display panels. The primary panel shows sergiosUpdatedSlimeSketch.js (canvas setup, keyboard input, draw order). The secondary panel shows Player.js (the breathing trick, sprite-sheet crop, named constants). Separating them makes each concept independently findable.

The original uses four separate if(vel > 3) blocks to clamp velocity. The refactored version uses constrain(player.vel.x, -PLAYER_SPEED, PLAYER_SPEED). Two lines replace eight. constrain() is identical in p5.js, Java Processing, and Python Processing, making this a direct cross-training translation.

The original always called this.drawPlayer(this.pos.x, this.pos.y) — the external parameters were always this.pos. The refactored version uses this.pos directly inside the method. Better encapsulation: the Player knows where it is; callers do not need to tell it.

The root cause is that the div has no intrinsic width before the canvas is inserted. Adding width: 100% to the CSS rule tells the browser to fill the available column width regardless of whether the div has any content yet:

/* sergiosUpdatedSlimeStyles.css */
#sketchContentDiv { width: 100%; text-align: center; }

After this fix, clientWidth returns the true column width when setup() runs, and the canvas sizes correctly on the first frame. This is the primary fix — the one that actually resolves the problem.

If the CSS is somehow not applied (cold load, cached file, browser quirk), the guard catches the zero before it reaches createCanvas():

var myWidth = CANVAS_FILL_RATIO * contentDiv.clientWidth;
// Guard: if clientWidth is still 0, fall back to a known-good size
if (!myWidth || myWidth < SMALL_SCREEN_SIZE) { myWidth = CANVAS_MAX; }

This does not go into myResizeCanvas() — by the time a resize event fires, the canvas is already present and clientWidth is non-zero. The guard is only needed at first creation.

This one is independent of the canvas-size bug but surfaced during the same debugging pass. The background was being drawn without setting imageMode explicitly. On the very first frame, imageMode defaults to CORNER; on every subsequent frame, drawPlayer() had already set it to CENTER. The result was that the grass background was positioned differently on frame 1 than on all later frames — a one-frame inconsistency that most users would never notice but which violated the “explicit over implicit” principle of the teaching edition:

// draw() — Layer 2
imageMode(CENTER);   // explicit — drawPlayer() also changes this
image(bg, width / 2, height / 2, width * 2, height);

Named and intentional is always better than “happens to work because of call order.”

window.addEventListener('keydown', function(e) {
    if (e.keyCode >= 37 && e.keyCode <= 40) {
        e.preventDefault();
    }
});

Pro: three lines, completely eliminates the scroll conflict.
Con: arrow keys can no longer scroll the page at all, even before the user has interacted with the sketch. This is the problem klp identified — it removes a natural navigation affordance from the page.

Verdict: appropriate for full-page games; wrong for a showcase page where the sketch shares space with code panels and a footer.

var mouseOverCanvas = false;
// in setup():
myCanvas.elt.addEventListener('mouseover', function() { mouseOverCanvas = true; });
myCanvas.elt.addEventListener('mouseout',  function() { mouseOverCanvas = false; });
window.addEventListener('keydown', function(e) {
    if (mouseOverCanvas && e.keyCode >= 37 && e.keyCode <= 40) {
        e.preventDefault();
    }
});

Pro: no extra HTML attribute needed; intuitive “hover to activate” metaphor; preserves page scrolling until mouse enters canvas.
Con: mouse position and keyboard focus are independent — the user can hover off-canvas while still holding an arrow key, causing a simultaneous scroll + slime-move. Also: a keyboard-only user cannot play without triggering scroll regardless of what the mouse does.

Verdict: works for most casual use; has a real edge case under normal play conditions. Acceptable but not robust.

// In sergiosUpdatedSlimeSketch.js — end of setup():
contentDiv.setAttribute('tabindex', '0');
contentDiv.style.outline = 'none';   // suppress focus ring (canvas has its own border)

// Auto-focus when user clicks the sketch area
myCanvas.elt.addEventListener('click', function() { contentDiv.focus(); });

// Prevent scroll only while the sketch container has keyboard focus
contentDiv.addEventListener('keydown', function(e) {
    if (e.keyCode >= 37 && e.keyCode <= 40) {
        e.preventDefault();
    }
});

How it works: giving #sketchContentDiv a tabindex makes it a focusable element. When the user clicks the canvas, contentDiv.focus() is called, transferring keyboard focus there. The keydown listener on contentDiv then catches arrow keys and cancels their default scroll. When the user clicks anywhere else on the page, focus leaves contentDiv and normal arrow-key scrolling resumes.

Why this is right: focus is the correct semantic signal for “this element currently owns keyboard input.” It is how the browser already distinguishes between a text field and the rest of the page. p5.js’s keyIsDown() listens on the window object and is unaffected — the sketch still receives all key events. The preventDefault() call only cancels the browser’s scroll action, not the keypress itself.

Pro: precise, predictable, no edge cases, semantically correct, accessible (keyboard-only users can Tab to the canvas to focus it).
Con: requires a one-time click to “activate” the sketch; a first-time visitor might not realize this. A subtle “click to play” hint in the canvas caption addresses this.

Verdict: the industry standard for browser-embedded games. This is how every serious browser game handles the scroll conflict.

The user’s proposal correctly identifies that unconditional prevention is too broad. The intuition to scope the prevention to the canvas area is exactly right — the implementation just needs to use focus rather than mouse position. Focus answers the question “does this element currently own keyboard input?” Mouse position answers the question “where is the pointer right now?” These are different questions, and only the first one is the right condition for intercepting keyboard events.

// ── Focus-based arrow key fix
// Attaching keydown to contentDiv means preventDefault() only fires
// while the sketch has keyboard focus — leaving page scroll intact elsewhere.
contentDiv.setAttribute('tabindex', '0');
contentDiv.style.outline = 'none';  // canvas border already provides visual focus cue
myCanvas.elt.addEventListener('click', function() { contentDiv.focus(); });
contentDiv.addEventListener('keydown', function(e) {
    if (e.keyCode >= 37 && e.keyCode <= 40) { e.preventDefault(); }
});

The outline: none suppresses the browser’s default focus ring (a dotted or colored border that appears when a tabindex element gains focus). The canvas already has its own visual boundary inside the panel, so the default ring would be redundant and visually jarring.

<h1 class="hero-title">
    <img src="images/slimeOnGrass.gif"
         alt="animated slime on grass"
         style="height:1.15em; vertical-align:middle;
                margin-right:0.3em; image-rendering:pixelated;">
    Sergio&rsquo;s Slime:<br>Teaching Edition
</h1>

height: 1.15em scales the image relative to the heading’s computed font size, so it stays proportional as the clamp() font size adjusts across viewport widths. vertical-align: middle aligns it with the cap-height of the first line of text.

// Layer 2: grass background (fallback if Grass_Sample.png is not loaded)
imageMode(CENTER);
if (bg) {
    image(bg, width / 2, height / 2, width * 2, height);
} else {
    background(120, 60, 30);  // HSB dark-green — approximates grass palette
}

In p5.js, a failed loadImage() produces a blank p5.Image object (not null), so the guard uses if (bg) which evaluates true for a valid loaded image and false for the blank fallback object. The sprite images (slimeSprite.png, slimeBack.png) are handled the same way by p5.js — a failed load produces an invisible blank sprite rather than a crash, so they require no additional guard.

The guard makes the line safe to run in any JavaScript environment: window exists in browsers but not in Node.js or Processing.py. Since the sketch only runs in a browser, the guard always evaluates true here — it is a defensive pattern that costs nothing and prevents a crash if the file is ever run in a non-browser context (e.g., a test suite or server-side renderer).

If the window export feels like a workaround, the other option is to paste the full Player.js source at the bottom of sketch.js and use only one file in the editor. The class must appear after all the sketch code (or at least after any code that uses class Player but before setup() runs) to satisfy the class declaration timing rule. This is the simplest possible approach and is sometimes the right choice for novices who are not yet comfortable with multi-file projects.

1. Download sketch.js and Player.js from the showcase page.
2. Open editor.p5js.org. Leave the project as a single-file project (no need to add Player.js as a separate file).
3. Open sketch.js in a text editor locally. Open Player.js in a text editor locally. Copy everything in Player.js and paste it at the very bottom of sketch.js (after the last line of myResizeCanvas()).
4. Paste the combined content into the editor’s single sketch.js tab.
5. In Sketch Files, create an images folder and upload Grass_Sample.png, slimeSprite.png, and slimeBack.png.
6. Click Run ▶. The slime should appear.

Verdict: the Java port is the most straightforward of the three. The only non-trivial adaptation is keyboard polling, which has a textbook solution. Estimated new code: ~10 lines for the key-tracking set; everything else is syntax translation.

Verdict: achievable, but Python requires the most structural rethinking because of the vector situation. That rethinking is itself pedagogically valuable — it shows students that the concept (velocity-based movement) survives even when the language tool (PVector) does not. The keyboard adaptation is the same as Java. No new unknowns.

This is the most significant logic change. p5.js provides keyIsDown(n) — a polling function you can call anywhere in draw() to ask whether key n is currently held. Java Processing has no such function. It fires keyPressed() and keyReleased() events, but these events do not give you a way to query key state mid-frame.

The standard Java solution is a HashSet<Integer> that acts as a snapshot of currently held keys:

HashSet<Integer> heldKeys = new HashSet<Integer>();

void keyPressed()  { heldKeys.add(keyCode); }
void keyReleased() { heldKeys.remove(keyCode); }

// In draw() — exact equivalent of p5.js keyIsDown():
if (heldKeys.contains(KEY_D) || heldKeys.contains(RIGHT)) { ... }

The key codes are identical between JavaScript and Java. Arrow key codes (LEFT=37, RIGHT=39, UP=38, DOWN=40) are the same in both environments. Letter keys use their uppercase ASCII values (A=65, D=68, W=87, S=83) in both. The only code that changes is the mechanism for querying them.

Session 7 stated: “Sprite-sheet crop: image(img,dx,dy,dw,dh,sx,sy,sw,sh) is the same API. No changes.” This turns out to be incorrect. The destination parameters are the same. The source parameters are not.

The translation is one extra calculation: u2 = sx + sw. For this sketch, where each frame is idle.height pixels wide:

// p5.js (offset + SIZE):
image(idle, pos.x, pos.y, displaySize, displaySize,
      srcX, 0, idle.height, idle.height);

// Java Processing (top-left + BOTTOM-RIGHT CORNER):
int srcX2 = srcX + idle.height;   // one extra line
image(idle, pos.x, pos.y, displaySize, displaySize,
      srcX, 0, srcX2, idle.height);

This difference is invisible when the frame is cropped from the very top-left of the sheet (srcX=0), because u2 = 0 + idle.height = idle.height and the original sw = idle.height look the same. The bug only appears for frame 1 (srcX > 0), where p5.js’s sw = idle.height gives the correct width but Java’s u2 = idle.height would also point to the boundary between frames — wrong.

Why it matters for cross-training: students porting code between p5.js and Java Processing could silently produce a broken animation that shows the correct sprite for frame 0 and the wrong region for frame 1. The breathing would still appear to “work” on close inspection but the crop coordinates would be off by exactly srcX pixels. This is the kind of subtle off-by-one that is very hard to diagnose without knowing the convention difference.

The left-facing mirror uses a coordinate flip: scale(-1, 1) combined with a negated x position. The save/restore pair that wraps this flip is a single word change:

// p5.js:
push();
  scale(-1, 1);
  image(idle, -this.pos.x, this.pos.y, ...);
pop();

// Java Processing:
pushMatrix();
  scale(-1, 1);
  image(idle, -pos.x, pos.y, ...);
popMatrix();

The behavioral difference is scope: p5.js push() saves both the transformation matrix and the drawing style (including imageMode). Java pushMatrix() saves only the matrix. This is fine here because drawPlayer() always sets imageMode(CENTER) at its own top — the explicit approach means the code is correct regardless of which save/restore semantics are in play.

Java Processing’s loadImage() looks for files in a data/ subfolder by default. The slime images live at images/, one level above the scripts/ folder. Using sketchPath("../images/...") constructs an absolute path from the sketch’s own directory and navigates up one level:

// sketchPath() returns the absolute path to this .pde file's folder.
// Appending "../images/..." navigates up to the shared images/ folder.
idle = loadImage(sketchPath("../images/slimeSprite.png"));

This keeps the images in one location and avoids duplicating them into a data/ subfolder. If the relative navigation ever fails (some systems handle .. differently), the fallback is to copy the three image files into scripts/data/ and use plain filenames.

Teaching note: this asset-loading simplification is one of the genuine advantages of the desktop IDE over a browser environment. No CDN, no CORS headers, no asset server — just a path on disk.

In Java Processing, a class defined in the same .pde file as the main sketch is compiled as an inner class of the sketch’s generated PApplet subclass. This means the Player class can directly access all top-level constants (PLAYER_SIZE, ANIM_SPEED, etc.) and global images (idle, back) without any parameters or imports — the same reason the JavaScript version could access globals declared in sketch.js from inside Player.js.

// p5.js: constants declared in sketch.js, accessed in Player.js (shared global scope)
const PLAYER_SIZE = 50;

// Java: final fields at sketch level, accessed inside Player class (inner class scope)
final float PLAYER_SIZE = 50;
// Player() constructor can read PLAYER_SIZE directly — no parameter needed

The cross-training lesson: both versions rely on a shared outer scope, but the mechanism differs. In JavaScript (plain script tags) it is the window object. In Java Processing it is the inner-class/outer-class relationship. In a future refactoring, both could be given constructor parameters instead — which would make each version more self-contained and testable.

The breathing trick, movement math, braking, boundary checking, direction logic, and color mode are all word-for-word identical. The core algorithm survives the language crossing completely intact — only the input mechanism and one image-crop convention required non-trivial thought.

The loadImage() calls were updated from the sketchPath() relative-path approach to plain filenames — the Processing standard:

// Before (sketchPath approach — unreliable when IDE relocates the sketch):
idle = loadImage(sketchPath("../images/slimeSprite.png"));

// After (plain filename — Processing always finds it in data/):
idle = loadImage("slimeSprite.png");

The file header was also updated to document Option A as the primary setup method, with Option B (manual data/ folder) as the fallback.

Session 7 predicted this would be “the most structural rethinking” of the Python port. In the Java version, pos and vel are PVector objects with .x and .y fields. In Python, the cleaner approach is to replace them with four plain floats: pos_x, pos_y, vel_x, vel_y.

The movement algorithm — add velocity to position each frame, zero velocity at the end — is completely unchanged. What changed is the container: PVector is absent, replaced by explicit components. This is the cross-training insight Session 7 identified: the concept travels; the library support is language-specific.

Python’s built-in set() is the shortest path from the Java solution. The behavior is identical; the syntax is simpler:

// Java:
HashSet<Integer> heldKeys = new HashSet<Integer>();
void keyPressed()  { heldKeys.add(keyCode); }
void keyReleased() { heldKeys.remove(keyCode); }
if (heldKeys.contains(KEY_D)) { ... }

# Python:
held_keys = set()
def keyPressed():  held_keys.add(keyCode)
def keyReleased(): held_keys.discard(keyCode)   # discard() is safe if absent
if KEY_D in held_keys: ...

One meaningful difference: discard() instead of remove(). Java’s HashSet.remove() silently succeeds whether or not the element exists. Python’s set.remove() raises a KeyError if the element is absent; set.discard() does not. In a sketch that can lose window focus mid-key-hold, discard() is the safer choice — a dropped focus event means keyReleased() never fires for the held key, but the next key-down/up cycle should still work cleanly without an exception.

Python requires an explicit global declaration when a function reassigns a module-level name. Reading or calling methods on module-level objects does not need global.

# Reassignment → needs global
def setup():
    global idle, back, bg, player   # we assign new objects to these names
    idle = loadImage("slimeSprite.png")
    player = Player(width / 2.0, height / 2.0)

# Attribute modification → no global needed
def draw():
    player.vel_x += PLAYER_SPEED   # modifying an attribute, not reassigning player

# Set method call → no global needed
def keyPressed():
    held_keys.add(keyCode)          # calling .add() on the existing set object

Java and JavaScript never needed this distinction because both use reference semantics with no scoping penalty: any variable declared in the outer scope (or at class level) is automatically accessible for both reading and reassignment inside a function, as long as it was declared before the function runs. Python enforces the separation explicitly.

Python Processing is Jython calling directly into Java Processing’s compiled classes. This means the 9-parameter image() uses the same convention as Java — top-left corner + bottom-right corner, not p5.js’s offset + size:

# Python Processing (same as Java):
src_x  = idle.height * frame_index
src_x2 = src_x + idle.height       # bottom-right corner
image(idle, self.pos_x, self.pos_y, display_size, display_size,
      src_x, 0, src_x2, idle.height)

The Python Processing official reference only documents the 4-parameter form of image() because it is the most common. The 9-parameter overload is available because Python Processing is calling Java Processing’s PApplet.image() directly. The rule: if you are calling a Processing function from Python Processing, look at the Java Processing reference for the complete signature, not just the Python reference.

The twinkling stars cross-training page embeds all three code strings as String.raw template literals directly in the HTML. The slime files are substantially longer (~250–300 lines each), so embedding all three inline would produce an unwieldy HTML file. The slime showcase page already uses fetch() successfully, so the same pattern was applied here:

// Global vars — populated by fetch(), read by copyRaw()
var JS_CODE = '', JAVA_CODE = '', PY_CODE = '';

fetch('scripts/sergiosUpdatedSlimeSketch.js')
    .then(function(r) { return r.text(); })
    .then(function(code) {
        JS_CODE = code;                            // stored for copyRaw()
        buildCodeDisplay(code, 'jsCodeList', highlightJS);
    });

Each copy button calls copyRaw(this, JS_CODE) — reading from the stored raw variable, never from DOM textContent. This follows the rule in the TNT code-display note: DOM reading strips HTML entities inconsistently across browsers.

Both files are fetched in parallel and joined with a visible separator comment before being stored in JS_CODE and passed to buildCodeDisplay():

Promise.all([
    fetch('scripts/sergiosUpdatedSlimeSketch.js').then(function(r) { return r.text(); }),
    fetch('scripts/Player.js').then(function(r) { return r.text(); })
]).then(function(parts) {
    JS_CODE = parts[0]
        + '\n\n// ─────────────────────────────────────────────────────────\n'
        + '// Player.js  (companion file — combined here for editor use)\n'
        + '// ─────────────────────────────────────────────────────────\n\n'
        + parts[1];
    buildCodeDisplay(JS_CODE, 'jsCodeList', highlightJS);
});

The separator comment makes the join point obvious to anyone reading the panel. copyRaw(this, JS_CODE) copies the full combined string — paste directly into the p5.js editor, upload the three images, and run.