Building Creative Cross Training
Sessions 1–10: Architecture, Mystic Shield, Hub Launch, Home Page Wiring, Cross-Linking, Interactive Shield, Henry’s Ghost Saga, Explore Page Inclusion, & Sergio’s Slime Sprite
How a Processing sketch became TNT’s creative-coding cross-language pathway
This is the development diary for TNT Creative Cross Training — the sister area to the existing concept-centric Cross Training hub. The focus here is creative coding in the Processing ecosystem: one visual sketch, rebuilt in p5.js, Java Processing, and Python Processing.
The log follows the S.P.A.R.K. method: Set goal → Prompt thoughtfully → Analyze the response → Refine → Know what you built.
Session 1 summarizes the markdown discussion that separated Creative Cross Training from the CS Concepts Cross Training area.
Session 2 captures the Mystic Shield work: debugging Python Processing, refactoring all three language versions to HSB, and launching the p5.js showcase.
Session 3 records the code-display rules that became canonical after the Twinkling Stars and Mystic Shield copy bugs.
Session 4 documents the Creative Cross Training home page and its first live entry.
Session 5 documents ecosystem wiring: the TNT home page card, the compact Explore entry, and reciprocal links between the two Cross Training hubs.
Session 6 adds Interactive Mystic Shield: a mouse-reactive p5.js app that uses a finished AI/robot image as the base layer and overlays live shield geometry.
Session 7 creates Interactive Mystic Shield 2 as a safe duplicate with a held-mouse perspective effect that compresses the shield into a vertical ellipse.
Session 8 documents the arrival of Henry’s Ghost Saga as Creative Cross Training Entry #2, the saga home page, the Ghost Wrangler on the Processing apps page, the Twinkling Stars decision, and the CCT reference link added to the Processing apps intro section.
Session 9 analyzes whether the Mystic Shield and Ghost Wrangler belong on the Explore page, addresses the Simulation category question for the Mystic Shield, and documents the decision to add both to the S.P.A.R.K. and Processing offcanvases.
Session 10 documents the arrival of Sergio’s Slime Sprite as Creative Cross Training Entry #3: the professional refactoring of a 2023 novice p5.js app, the Java and Python Processing ports, the cross-training comparison page, and the Piskel cheat sheet that teaches students how the sprite was made.
We want a place for Processing Cross Training apps: p5.js sketches translated into Java Processing and Python Processing. The markdown notes argue this is related to Cross Training, but not the same teaching path.
Creative Cross Training gets its own hub because its audience intent, page rhythm, and project shape are different. Students arrive through visual curiosity: How does that sketch work? The answer is still cross-language learning, but the path starts with canvas, color, geometry, and motion.
The two areas remain visibly connected: CS Concepts Cross Training handles algorithmic concepts; Creative Cross Training handles Processing sketches and visual design patterns.
The p5.js version is the live browser experience. Java Processing and Python Processing are comparison targets and downloadable/source-study versions. This asymmetry is intentional: the web page can show p5.js immediately, while Java and Python Processing require local Processing tools.
SketchWave is an abstraction layer, so it should not be the first stop. The learning sequence is: raw Processing API first, cross-language visual patterns second, then higher-level SketchWave/PyWave abstractions when students understand what is being wrapped.
The Mystic Shield sketch is our best candidate for the first Creative Cross Training entry — it already has fire/amber character and all three language versions. Can we get all three running and consistent? The Python version isn’t rendering at all when I open it in Python Processing.
The first Python Processing version appeared to do nothing. Root cause: size(800, 600, P2D) was inside setup(). In Python Processing, renderer-backed sketches must declare size() in settings(); otherwise Processing may silently fail to open the canvas.
After the renderer fix, the sketch appeared frozen because print() calls were still inside functions called from draw(). In the Jython-based Python Processing runtime, console I/O is expensive enough to crush animation. Per-frame prints were removed; the one-time setup() breadcrumb stayed.
Mystic Shield was refactored to use colorMode(HSB, 360, 100, 100, 100) in all three languages. The fire palette became portable design data rather than arbitrary RGB triples: deep amber backgrounds, orange boundary rings, golden satellite sigils, and randomized spark hues.
Alpha values moved from the RGB 0–255 range to the HSB 0–100 range. That required proportional changes such as lifeRatio * 255 becoming lifeRatio * 100 and alphaOffset shrinking from random(0, 100) to random(0, 40).
The page MysticShield/mysticShield2.html became the first live showcase. It runs the p5.js sketch in-browser, displays source code in a fire/amber greenbar, and links to the Java and Python source files for the coming full comparison page.
Something’s wrong with the copy button on the code panel. When I paste what it copies I’m getting HTML markup mixed in with the source code — span tags, class attributes like class=“ms-string”. The code I paste into an editor is broken. How is this happening and what’s the fix?
The string highlighter wrapped code fragments in spans, then later keyword matching saw the word class inside <span class="...">. Browser error recovery made the displayed HTML unpredictable, and copying textContent preserved the mess.
All future code-display pages should use copyRaw(btn, RAW_CODE_VARIABLE). Copy buttons read from the original source string, never from the highlighted DOM.
Keyword and number highlighting helpers must avoid matches inside HTML tags by checking whether the match occurs after the most recent < and before the next >. The helper pattern now belongs to both Mystic Shield and the earlier Twinkling Stars comparison page.
Let’s build the Creative Cross Training home page. It should feel like a sibling to the CS Concepts Cross Training hub but with its own identity. The fire/amber Mystic Shield aesthetic seems like the right direction. Mystic Shield should be the first live entry card, with room for future entries below it.
The hub was created as creativeCrossTrainingHome.html with styling in creativeCrossTrainingStyles.css. The hero uses ../images/aiRobotMentoringHuman.jpg, while the first entry card points to MysticShield/mysticShield2.html.
The first card is Mystic Shield, labeled Entry #1 and tagged for p5.js, Java Processing, and Python Processing. The entry text emphasizes the reusable creative-coding patterns: HSB color mode, polar motion, layered transforms, and particle classes.
The Mystic Shield card preview now uses MysticShield/images/strangeShield-background.gif, matching the teacher-provided animated preview when saved into the project. The older static mysticShield.png remains the source image for the showcase page hero assets.
The hub is live with the Mystic Shield. Time to wire it into TNT: a feature card on the home page, a compact card in the Explore All Sections grid, and reciprocal links between the two Cross Training hubs. Also — the existing Cross Training card should be clearer that it covers CS Concepts, so visitors immediately understand the difference between the two doors.
The main index.html page gained a new featured destination card for Creative Cross Training, using images/aiRobotMentoringHuman.jpg as the background. The existing Cross Training card was clarified as Cross Training: CS Concepts so visitors can distinguish the two doors immediately.
The Explore All Sections grid on index.html gained a compact Creative CT card immediately beside the CS Cross Training card. This mirrors the two-card relationship in the featured destinations section.
CrossTraining/crossTrainingHome.html now points to Creative Cross Training with an Also: Creative Cross Training link. The Creative Cross Training home page points back with Also: CS Concepts Cross Training. The goal is one-click recovery if a student enters the wrong cross-training doorway.
| CreativeCrossTraining/creativeCrossTrainingHome.html | Created hub page; later linked to this chatlog and CS Concepts Cross Training. |
| CreativeCrossTraining/creativeCrossTrainingStyles.css | Created fire/amber creative-coding hub styling. |
| CreativeCrossTraining/creativeCrossTrainingChatlog.html | Created this S.P.A.R.K. development log. |
| CreativeCrossTraining/creativeCrossTrainingChatlogStyles.css | Created standalone chatlog styling. |
| CreativeCrossTraining/MysticShield/mysticShield2.html | Built the first live p5.js showcase entry. |
| CreativeCrossTraining/MysticShield/src/MysticShield2.py | Created Python Processing HSB version. |
| CreativeCrossTraining/MysticShield/src/MysticShield2Sketch.js | Created/refined p5.js HSB version and browser canvas attachment. |
| CreativeCrossTraining/MysticShield/src/MysticShield2.pde | Created Java Processing HSB version. |
| index.html | Added Creative Cross Training feature card and compact Explore entry; clarified CS Concepts Cross Training. |
| CrossTraining/crossTrainingHome.html | Added reciprocal link to Creative Cross Training. |
- Build
MysticShield/mysticShield2CTraining.htmlas the full three-language comparison page. Completed 2026-09-25. - Build
MysticShield/interactiveMysticShield.htmlas a mouse-reactive p5.js image-augmentation app. Completed 2026-09-26. - Build
MysticShield/interactiveMysticShield2.htmlas a safe perspective-tilt experiment. Completed 2026-09-26. - Add Henry’s Ghost Saga as CCT Entry #2 with saga home page and cross-training page. Completed 2026-09-28.
- Feature Ghost Wrangler on the Processing apps page and add CCT reference to the intro callout. Completed 2026-09-28.
- Build Stage 3: Full Ghost Rebuild with constants, OOP, and improved stars backdrop. In queue.
- Continue tracking Python Processing rules: renderer-backed
size()belongs insettings(), and per-frame print calls are off limits.
I want to build an interactive version of the Mystic Shield where mouse movement controls the shield’s scale and rotation intensity — so the user feels like they’re conjuring it. I also have an AI-generated photograph of a robot mentoring a human that I’d like to use as the background layer. The shield geometry should appear as a live overlay on that image.
A new p5.js showcase interactiveMysticShield.html places the Mystic Shield geometry over a real AI-generated robot-and-human photograph. Moving the mouse controls the shield’s scale and rotation intensity. The photograph is a static CSS background; the live sketch renders only the geometric overlay. This separates static imagery from dynamic Processing output at the architecture level — not as a technical trick, but as a reusable pattern for any sketch that augments a photograph.
I want to experiment with a perspective-tilt effect: when you hold the mouse button down, the shield should compress as if you’re viewing it from a sharp angle rather than straight on. But I don’t want to break the working v1. What’s the safest approach to trying something that might not work?
Rather than modifying the working v1 showcase, a safe duplicate interactiveMysticShield2.html adds a held-mouse mode that compresses the shield geometry into a vertical ellipse — a perspective-tilt effect using scale(1.0, yScale). The v1 page is preserved intact. The pattern of creating a numbered sibling file for experimental additions is now established TNT practice and should be followed for any sketch evolution that might break a working demo.
Henry’s Ghost Wrangler is running in p5.js, Java, and Python, and we’ve extracted and improved the Twinkling Stars backdrop as a separate educational piece. The bigger idea is an evolutionary design showcase — showing how a working first draft becomes quality code, component by component. Let’s add Henry’s Ghost Saga to Creative Cross Training as Entry #2 with a dedicated saga home page. Also feature the Ghost Wrangler on the Processing apps page. And I’d like your opinion: should we feature the Twinkling Stars on the Processing page too, or hold it?
Henry’s Ghost Wrangler and its saga of component improvements join the Creative Cross Training gallery as Entry #2. Unlike Entry #1 (Mystic Shield), which is a single polished design, Entry #2 is explicitly framed as an evolutionary design showcase — students can watch a real student design evolve from working first draft to quality code. A dedicated saga home page (henrysGhostSagaHome.html) was created as the entry point, with stage cards for Ghost Wrangler (Stage 1), Twinkling Stars (Stage 2), and a queued Full Rebuild (Stage 3).
The Ghost Wrangler is a complete, interactive, student-authored sketch that stands alone without any cross-training context. It was added to processing_apps.html alongside the Mystic Shield. The figcaption includes a “Saga Home” inline link so visitors can move from the app grid into the full educational context with one click. The ghost animated GIF serves as the icon.
The twinkling star field was extracted from the Ghost Wrangler backdrop for educational comparison purposes. Its identity is a component under study, not a standalone app. Featuring it separately on the Processing page would fragment the Ghost story without the Saga context that makes the extraction meaningful. It will be reconsidered when Stage 3 (Full Ghost Rebuild) is complete: at that point the rebuilt ghost app — which incorporates the improved star field — can be featured as a single coherent product.
The Processing apps page already explains the three-language personality of Processing. Adding a “Compare All Three Languages” block inside the existing proc-stat-callout creates a natural companion to the “Looking for the Classics?” block. A visitor reading about p5.js, Java Processing, and Python Processing is exactly the right audience for a link to Creative Cross Training — the reference appears at the moment of maximum relevance, not buried in the app grid.
We have added the Mystic Shield and Henry’s Ghost Wrangler to the Processing page, but not yet to the Explore page. For consistency, I think we should — although they are in a slightly different class since they are part of Creative Cross Training. What is your view? I’m thinking S.P.A.R.K. and Processing. The Mystic Shield could fall under Simulation since it looks like a simulation of Dr. Strange’s shield. What is your view on this inclusion?
The CCT framing is a context distinction, not an exclusion criterion. Every other student Processing sketch in Creative Cross Training — Ethan’s Crazed Emoji, Grayson’s Bicolor Orb, Jayden’s Jammin’ Emoji — already appears in both the S.P.A.R.K. and Processing offcanvases on Explore. Mystic Shield and Ghost Wrangler are richer apps by any measure: more complete chatlogs, cross-training comparison pages, and genuinely interactive live sketches. Leaving them off Explore while including those student sketches would create an inconsistency that the page does not currently have. They belong there.
S.P.A.R.K. and Processing are the correct categories. The Simulation question needs a direct answer.
CCT membership is additional framing, not a different classification. The Explore page is a catalog; it should contain everything TNT has built. These apps having a richer home in the CCT ecosystem is a reason to feature them in Explore, not to omit them. A student browsing Explore should find the Mystic Shield and the Ghost Wrangler. The fact that each link leads into a full saga or cross-training ecosystem is a discovery bonus, not a navigation complication.
The Simulations category description reads: “Mimicking the real world: snowflakes, random walks, Langton’s ant, alien invasions.” The Mystic Shield does not model a real-world phenomenon. It is a creative coding piece — rotating polar geometry, layered transforms, particle sparks. The visual resemblance to Dr. Strange’s shield is thematic framing, not a simulation of a physical system.
W.O.P.R. belongs in Simulations because it models a functional process: a CRT terminal interface and a probabilistic character-locking algorithm with defined state transitions. The Mystic Shield generates geometry — there is no process, no state, no physics. The same reasoning applies to the Ghost Wrangler: its floating animation and twinkling stars are creative coding decisions, not a model of gravitational or atmospheric phenomena. Processing is the correct home for both.
Interactive Mystic Shield 2: added to the S.P.A.R.K. and Processing offcanvases on Explore. This chatlog (Creative Cross Training S.P.A.R.K. Chat Log) is linked from the S.P.A.R.K. entry as the development record for Sessions 6–7. Added to the offcanvases only — not the Processing card’s featured link list. The Processing apps page and the CCT ecosystem are the primary discovery paths; Explore offcanvas is the secondary catalog.
Henry’s Ghost Wrangler: added to the S.P.A.R.K. and Processing offcanvases on Explore. The Ghost Saga chatlog is linked from the S.P.A.R.K. entry. Same reasoning: offcanvas only. Not added to Simulation.
Sergio Z built a p5.js slime sprite app in 2023 with WASD movement and a breathing animation. The breathing trick is completely invisible in the code — unnamed numbers, no comments, no explanation of how the two-frame sprite sheet works. Let’s refactor it into a teaching edition and add it to Creative Cross Training as Entry #3. I also want Java and Python ports and a full three-language comparison page.
Sergio’s original sketch works — the slime breathes, moves, and faces the correct direction. What is invisible is how. A floating frame counter advances in increments of 0.05 per frame; floor() converts it to 0 or 1; the nine-parameter image() crops the correct half of a horizontal sprite sheet. The refactored Teaching Edition names every constant (ANIM_SPEED, ANIM_FRAME_MAX, PLAYER_SIZE, SPRITE_SCALE), separates the Player class into its own companion Player.js file, and opens that file with a step-by-step diagram explaining the breathing trick before a single line of sketch code appears. That diagram — not the code itself — is the entry point for students arriving at the showcase for the first time.
Session 7 of the app chatlog predicted the Java port would be straightforward. It was — with one exception that Session 7 got wrong: the nine-parameter image() call is not identical across languages. p5.js takes offset + size for the source region; Java and Python Processing take top-left + bottom-right corner. For frame 0 (srcX = 0) the difference is invisible; for frame 1 it produces a silent off-by-one that crops the wrong region. One extra line — srcX2 = srcX + idle.height — fixes it in both Java and Python. The Java keyboard input required a HashSet<Integer> replacing p5.js’s built-in keyIsDown(). The Python port replaced PVector with four plain floats and used set.discard() instead of remove() for key-release safety. The breathing algorithm itself is word-for-word identical in all three languages.
Sergio built the sprite one pixel at a time in Piskel, a free browser-based pixel art editor. Documenting the tool that made the sprite became its own resource: a seven-section cheat sheet covering quick start, interface guide, drawing tools, a “Build the Slime” hands-on tutorial, export guide, tips and gotchas, and an honest assessment of when Piskel is and is not the right tool. The cheat sheet lives in resources/, links out to piskelapp.com, and is now the landing point for the Piskel card in Resources → Code Tools & Playgrounds. It is also linked from the CCT home card for Entry #3 so a student who asks “how do I make my own sprite?” can find the answer in one click.
The Creative Cross Training home card for Entry #3 links to the live p5.js showcase (sergiosUpdatedSlime.html), not directly to the App Comparison page. A novice arriving at the gallery should play the sketch first — the comparison page is one spark-bar click away once they are hooked. The card description names Piskel; the source links include a “Piskel guide” link alongside the live sketch, comparison page, original sketch, and chat log. This closes the creative loop: the student can discover the sprite, play with it, view the code in three languages, and learn to build their own sprite without leaving the CCT ecosystem.