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.

Cross the language bridge

SKETCHBOOK / 01 Copper Orchard · 2-week chapter

Page 1 of 5: The orchard has two doorways

Keep the renderer in C++

The orchard has two doorways

Copper Orchard is a small arrangement of luminous fruit and moving pollen. You already know the ideas: vertices, shaders, buffers, submissions, and completion. Metal gives those ideas a different API contract. Apple’s metal-cpp exposes Metal through C++ interfaces so scene data, math, resource policy, and rendering decisions can remain in C++. A small Objective-C++ file can own the Cocoa window, view, application delegate, and event callbacks. Keep this boundary narrow and name the borrowed objects crossing it.

Create one implementation translation unit for metal-cpp’s implementation macros, then include its ordinary headers elsewhere. Link the required Apple frameworks. Do not put the implementation macros in a commonly included header; multiple definitions are a build-structure error, not a rendering problem. Keep platform events flowing on their required thread and hand the renderer a clear frame/resize request rather than letting every Cocoa callback mutate GPU state.

The supplied SDK-only orchard_probe.mm is a command-line compute check, not the full orchard window and not a metal-cpp implementation. It uses Objective-C++ and ARC to run with the installed SDK alone. The separate metal_cpp_device.cpp demonstrates the C++ ownership boundary and requires Apple’s headers. This distinction lets you verify the local GPU immediately while building the intended C++ renderer deliberately.

TRY IT IN YOUR STUDIO

Draw three boxes: portable scene/math, metal-cpp renderer, Cocoa window bridge. Place every proposed responsibility in exactly one box.

From the page to your own work

Your studio assignment.

Create a device/queue ownership diagram and verify the actual M4 Pro capability report.

A finish line you can see

A Mac passport, a narrow platform-boundary sketch, and an ownership table for every factory used.

  1. Label the SDK-only probe separately from the intended metal-cpp renderer.
  2. Distinguish owned and autoreleased return values.
  3. Place implementation macros in exactly one translation unit.
  4. Handle absent device and failed object creation with useful diagnostics.
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.

Why does enabling ARC for a platform .mm file not solve metal-cpp ownership everywhere?
  • metal-cpp uses C++ objects/pointers that are not eligible for ARC.
  • Cocoa factory ownership still determines adopt versus retain.
  • Scoped C++ owners and autorelease pools express different responsibilities.

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

A small creative variation ↗

Add a renderer label containing only the project name and selected device.

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

Coming back after a break? ↩

Run the device probe unchanged, then identify one owned and one borrowed return value.

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 7 files