Theme Catppuccin
Make yourself at homeCatppuccin

A softer light for long learning sessions.

Appearance

Loading your preference…

Dark palette

Choose a dark palette to try it.

Light uses Latte. Your choices stay in this browser.

Open Signal Garden

SKETCHBOOK / 08 Signal Garden · 2-week chapter

Page 1 of 3: Debug by reducing the question

A capture is evidence

Debug by reducing the question

When the garden turns black, resist changing several constants. First ask whether a frame was acquired and submitted. Then inspect the target attachment, draw count, pipeline, vertex input, descriptor ranges, and shader output in that order. A graphics capture lets you inspect a particular frame and the resources behind it. Validation output answers API-contract questions; a capture answers many state and data questions; an independent numeric test answers mathematical questions. Keep those evidence types separate.

Label passes and objects with useful names such as seed-update, stem-depth, and petal-color. Avoid labels containing private work data; this portfolio project can use entirely synthetic scenes. Save the smallest reproducible scene that exhibits a bug. Turn one fixed defect into a regression: a host boundary test, a shader comparison, or a documented capture procedure, whichever can actually detect that defect.

If device loss or allocation failure occurs, report the failed operation and stop submitting through invalid state. Do not promise transparent recovery before implementing and testing a complete recovery policy. A clear exit with preserved diagnostics is a legitimate first product contract.

From the page to your own work

Your studio assignment.

Finish Signal Garden as a small original graphics installation you can defend technically.

A finish line you can see

A runnable Linux project, short demo, annotated capture, measured experiment, and honest case study.

  1. Document tested hardware/driver and required features.
  2. Demonstrate resize, pause, reset, unsupported configuration, and a bounded workload.
  3. Include a clean validation session and explain its limits.
  4. Separate supplied references, your work, and unimplemented extensions.
Keep the evidence in your weekly notebook ↗
Explain it like an engineer

Try answering aloud before opening the review notes. Use your own implementation as evidence.

How would you investigate a frame-rate regression without guessing?
  • Reproduce a fixed workload and record environment/build details.
  • Separate CPU and GPU measurements and identify the affected pass.
  • Test one hypothesis, preserve correctness/quality, and report variation and limits.

These prompts support practice; they are not an automatic assessment of your work.

A small creative variation ↗

Make a second palette and composition using the same resource budget; finish it in one session.

Optional. Save it for later if this chapter already feels full.

Coming back after a break? ↩

Run the last stable scene and choose one remaining acceptance criterion. Finish only that criterion today.

Books & principles behind this study +

Original Parallax explanations and assignments, with these works for further reading.

YOUR MARGIN NOTES

Leave yourself a good question.

What changed your mind? What would you try next?

Notes are private to this browser and saved as you write.

A CHECKPOINT, NOT A SCORE

Can you explain the idea and try the exercise yourself?

Completion records your own assessment. It does not compile or test your C++.
Companion source 2 files