diff --git a/en/03_Drawing_a_triangle/01_Presentation/01_Swap_chain.adoc b/en/03_Drawing_a_triangle/01_Presentation/01_Swap_chain.adoc
index 5047177f..21206674 100644
--- a/en/03_Drawing_a_triangle/01_Presentation/01_Swap_chain.adoc
+++ b/en/03_Drawing_a_triangle/01_Presentation/01_Swap_chain.adoc
@@ -41,34 +41,11 @@ std::vector<const char*> requiredDeviceExtension = {
 
 It should be noted that the availability of a presentation queue,
 as we checked in the previous chapter, implies that the swap chain extension
-must be supported. However, the extension does have to be explicitly enabled.
-
-== Enabling device extensions
-
-Using a swapchain requires enabling the `VK_KHR_swapchain` extension first.
-Enabling the extension just requires a small change to the logical device
-creation structure:
-
-[,c++]
-----
-deviceCreateInfo.enabledExtensionCount = requiredDeviceExtension.size();
-deviceCreateInfo.ppEnabledExtensionNames = requiredDeviceExtension.data();
-----
-
-Alternatively, we can do this at the construction and keep this very succinct:
-
-[,c++]
-----
-std::vector requiredDeviceExtension = { vk::KHRSwapchainExtensionName };
-
-float                     queuePriority = 0.5f;
-vk::DeviceQueueCreateInfo deviceQueueCreateInfo{.queueFamilyIndex = queueIndex, .queueCount = 1, .pQueuePriorities = &queuePriority};
-vk::DeviceCreateInfo      deviceCreateInfo{.pNext                   = &featureChain.get<vk::PhysicalDeviceFeatures2>(),
-                                           .queueCreateInfoCount    = 1,
-                                           .pQueueCreateInfos       = &deviceQueueCreateInfo,
-                                           .enabledExtensionCount   = static_cast<uint32_t>(requiredDeviceExtension.size()),
-                                           .ppEnabledExtensionNames = requiredDeviceExtension.data()};
-----
+must be supported. We already passed `requiredDeviceExtension` to
+`vk::DeviceCreateInfo` when
+xref:../00_Setup/04_Logical_device_and_queues.adoc[creating the logical device],
+so the extension is enabled and there's no further device-creation code
+needed here.
 
 == Querying details of swap chain support
 
diff --git a/en/03_Drawing_a_triangle/03_Drawing/03_Frames_in_flight.adoc b/en/03_Drawing_a_triangle/03_Drawing/03_Frames_in_flight.adoc
index 6d68ce01..767e8a6b 100644
--- a/en/03_Drawing_a_triangle/03_Drawing/03_Frames_in_flight.adoc
+++ b/en/03_Drawing_a_triangle/03_Drawing/03_Frames_in_flight.adoc
@@ -28,7 +28,9 @@ Generally, extra latency isn't desired.
 But giving the application control over the number of frames in flight is another example of Vulkan being explicit.
 
 Each frame should have its own command buffer, set of semaphores, and fence.
-Rename and then change them to be ``std::vector``s of the objects:
+Rename and then change them to be ``std::vector``s of the objects. The single
+fence, previously called `drawFence`, becomes `inFlightFences` here rather
+than just gaining an `s`, since we now have one fence per frame in flight:
 
 [,c++]
 ----
@@ -83,6 +85,19 @@ We will use a frame index for that purpose:
 uint32_t frameIndex = 0;
 ----
 
+`commandBuffer` is now a vector too, so `recordCommandBuffer` can no longer
+use it directly - add a local reference to the buffer for the current frame
+at the top of the function:
+
+[,c++]
+----
+void recordCommandBuffer(uint32_t imageIndex)
+{
+    auto &commandBuffer = commandBuffers[frameIndex];
+    ...
+}
+----
+
 The `drawFrame` function can now be modified to use the right objects:
 
 [,c++]