Highlight fix for Basic

public/css/style.css

@@ -708,10 +708,18 @@ a:hover {
   font-size: var(--code-size);
 }
 
+/* Wrapper that stretches to the widest line so highlighted rows fill the full
+   scroll width even on narrow / mobile viewports. */
+.code-lines {
+  display: inline-block; /* shrinks to max-content, but… */
+  min-width: 100%;       /* …never narrower than the scroll container */
+}
+
 .code-line {
   display: flex;
   align-items: flex-start;
   min-height: 1.6em;
+  min-width: 100%;       /* fill .code-lines width so background spans full row */
   padding: 0 0.5rem;
   cursor: pointer;
 }

public/js/app.js

@@ -344,7 +344,7 @@ function renderSection({ lines, startLine, enhancement, highlighted }, highlight
 
   let html = '';
   if (lines.length > 0) {
-    html += `<div class="code-section"><div class="code-block">${codeHtml}</div></div>`;
+    html += `<div class="code-section"><div class="code-block"><div class="code-lines">${codeHtml}</div></div></div>`;
   }
 
   if (enhancement) {

public/programs/doom/am-map-c.md

@@ -63,7 +63,7 @@ enhancements:
     content: "This section handles user input for the automap, allowing players to pan, zoom, mark locations, and toggle features like gridlines. The key bindings were designed for intuitive use, leveraging common keys like arrow keys and 'TAB'. The responsiveness of these controls was a testament to id Software's focus on player experience. The ability to mark and clear points on the map was particularly innovative, giving players a way to track objectives visually. This feature influenced later games, where interactive maps became a staple of open-world and RPG genres."
   - id: "zooming-mechanics"
     line_start: 737
-    line_end: 758
+    line_end: 753
     title: "Zooming Into the World of DOOM"
     wikipedia_url: "https://en.wikipedia.org/wiki/Zoom_lens"
     image_url: ""
@@ -103,7 +103,7 @@ enhancements:
     content: "The `AM_drawFline` function uses Bresenham's line-drawing algorithm to render lines on the automap's frame buffer. This algorithm calculates the optimal path for a line between two points, minimizing computational overhead by avoiding floating-point arithmetic. DOOM's implementation includes optimizations for speed, such as precomputing increments and using inline macros for pixel placement. Bresenham's algorithm was widely adopted in computer graphics, and its use in DOOM demonstrated how classic techniques could be adapted for real-time applications, influencing later game engines like Unreal Engine."
   - id: "automap-grid-rendering"
     line_start: 1067
-    line_end: 1115
+    line_end: 1110
     title: "Rendering a grid aligned to game geometry"
     wikipedia_url: "https://doomwiki.org/wiki/Automap"
     image_url: ""

public/programs/doom/d-main-c.md

@@ -86,8 +86,8 @@ enhancements:
     image_caption: ""
     content: "FindResponseFile processes command-line arguments to locate and parse response files, which contain additional arguments for the game. It reads the file into memory, appends its contents to the argument list, and displays the updated arguments for debugging purposes. This feature allows users to specify complex configurations without typing lengthy command lines. In the early 1990s, command-line interfaces were a common way to configure software. Response files provided a convenient way to manage complex setups, especially for developers and advanced users. DOOM's implementation reflects id Software's focus on flexibility and user empowerment. Response files influenced later tools and engines, which adopted similar mechanisms for batch processing and configuration. They remain relevant in modern development workflows, where scripts and configuration files are used to automate tasks. DOOM's code serves as a historical example of how to balance usability with technical sophistication."
   - id: "command-line-options-flexibility"
-    line_start: 792
-    line_end: 935
+    line_start: 807
+    line_end: 934
     title: "How Command-Line Arguments Shaped Gameplay"
     wikipedia_url: "https://en.wikipedia.org/wiki/Command-line_interface"
     image_url: ""
@@ -102,7 +102,7 @@ enhancements:
     image_caption: ""
     content: "DOOM's support for custom WAD files revolutionized gaming by enabling user-generated content. This section adds WAD files specified via the '-file' command-line argument to the game's resource list, marking the game as 'modified.' The code even includes a hack to allow '-wart' commands to load specific maps. In the 1990s, modding was in its infancy, and DOOM's modular file structure made it a pioneer. Players could create and share custom levels, fostering a vibrant community. This openness inspired later games like Quake and Half-Life, which built on DOOM's modding legacy. Today, modding is a cornerstone of PC gaming, with tools and platforms like Steam Workshop making it accessible to millions."
   - id: "subsystem-initialization"
-    line_start: 1009
+    line_start: 1011
     line_end: 1112
     title: "Why Modular Engines Win Every Time"
     wikipedia_url: "https://en.wikipedia.org/wiki/Modular_programming"

public/programs/doom/d-net-c.md

@@ -32,8 +32,8 @@ enhancements:
     image_caption: ""
     content: "This section defines key data structures used for DOOM's networking functionality, including `doomcom_t` and `doomdata_t`. These structures store information about the state of the network, such as player commands (`ticcmd_t`), game ticks, and node statuses. The `nettics` array tracks the progress of each player, ensuring synchronization across nodes. Multiplayer gaming in 1993 was still in its infancy, and DOOM's approach to managing state and communication was groundbreaking. John Carmack's focus on efficiency and simplicity allowed the game to run smoothly even on modest hardware. These data structures laid the groundwork for future multiplayer protocols, influencing games like Quake and Unreal Tournament."
   - id: "netbuffer-checksum"
-    line_start: 94
-    line_end: 113
+    line_start: 220
+    line_end: 258
     title: "How DOOM Verified Multiplayer Packets"
     wikipedia_url: "https://en.wikipedia.org/wiki/Checksum"
     image_url: ""

public/programs/doom/f-finale-c.md

@@ -24,48 +24,48 @@ summary:
 
 enhancements:
   - id: "finale-stage-logic"
-    line_start: 27
-    line_end: 56
+    line_start: 240
+    line_end: 247
     title: "How DOOM Decides Its Finale Stage"
     wikipedia_url: "https://doomwiki.org/wiki/Finale"
     image_url: ""
     image_caption: ""
     content: "This section defines the stages of the finale sequence: text display, art screens, and the monster cast roll. The variable `finalestage` acts as a state machine, transitioning between these stages based on player progress and timing. In 1993, this kind of state-driven design was common in games, as it allowed developers to create dynamic sequences without hardcoding every frame. By abstracting the stages, DOOM could adapt its finale logic for different game modes and expansions, such as DOOM II or The Ultimate DOOM. This modularity influenced later games, which adopted similar state-driven approaches for cutscenes and endgame sequences."
   - id: "finale-text-selection"
-    line_start: 58
-    line_end: 82
+    line_start: 240
+    line_end: 247
     title: "Dynamic Text Selection for DOOM’s Endings"
     wikipedia_url: "https://doomwiki.org/wiki/Endings"
     image_url: ""
     image_caption: ""
     content: "This section defines pointers to various text strings (`e1text`, `e2text`, etc.) that correspond to different episodes and game modes. The finale dynamically selects the appropriate text based on the player's progress and game mode. This design reflects the modularity of DOOM's engine, which was built to accommodate expansions and modifications. By separating text definitions from the rendering logic, id Software ensured that new content could be added without altering core code. This technique became a standard in game development, enabling easier localization and content updates."
   - id: "start-finale-sequence"
-    line_start: 92
-    line_end: 190
+    line_start: 240
+    line_end: 247
     title: "The Code That Starts DOOM’s Finale"
     wikipedia_url: "https://doomwiki.org/wiki/Finale"
     image_url: ""
     image_caption: ""
     content: "The `F_StartFinale` function initializes the finale sequence, setting the game state to `GS_FINALE` and disabling gameplay elements like the automap. It dynamically selects the background texture (`finaleflat`) and text (`finaletext`) based on the game mode and episode. This function showcases id Software's attention to detail, ensuring that each ending feels tailored to the player's journey. The modular design allowed DOOM to support multiple game modes and expansions seamlessly. This approach influenced later games with branching narratives and dynamic endings, such as the Mass Effect series."
   - id: "monster-cast-roll"
-    line_start: 328
-    line_end: 337
+    line_start: 240
+    line_end: 247
     title: "The Monster Cast Roll: A DOOM Icon"
     wikipedia_url: "https://doomwiki.org/wiki/Cast_roll"
     image_url: ""
     image_caption: ""
     content: "The `castorder` array defines the sequence of monsters displayed during the cast roll, including their names and types. This feature was a playful way for id Software to showcase the game's iconic enemies while adding a cinematic touch to the finale. The cast roll became a memorable part of DOOM's identity, influencing other games to include similar sequences, such as character or enemy showcases in fighting games and RPGs. It also highlights the developers' sense of humor, as the cast roll ends with the player character listed as 'HERO.'"
   - id: "cast-animation-ticker"
-    line_start: 391
-    line_end: 494
+    line_start: 240
+    line_end: 247
     title: "Animating DOOM’s Monster Cast Roll"
     wikipedia_url: "https://doomwiki.org/wiki/Sprite_animation"
     image_url: ""
     image_caption: ""
     content: "The `F_CastTicker` function drives the animations for the monster cast roll, transitioning between states and synchronizing sounds. It includes clever hacks, such as manually resetting attack frames (`goto stopattack`) and handling sound effects for specific states. These techniques reflect the constraints of 1993 hardware, where developers had to optimize every frame and byte. The cast roll's fluid animation and sound synchronization were groundbreaking at the time, influencing sprite-based animation systems in later games, including platformers and 2D RPGs."
   - id: "bunny-scroll-ending"
-    line_start: 640
-    line_end: 693
+    line_start: 240
+    line_end: 247
     title: "The Bunny Scroll: DOOM’s Quirky Finale"
     wikipedia_url: "https://doomwiki.org/wiki/Bunny_scroll"
     image_url: ""

public/programs/doom/f-wipe-c.md

@@ -24,48 +24,48 @@ summary:
 
 enhancements:
   - id: "shitty-col-major-transform"
-    line_start: 49
-    line_end: 69
+    line_start: 270
+    line_end: 274
     title: "Why Call It 'ShittyColMajorXform'?"
     wikipedia_url: "https://en.wikipedia.org/wiki/Column-major_order"
     image_url: ""
     image_caption: ""
     content: "This function performs a column-major transformation on a 2D array, rearranging its memory layout to optimize access patterns for certain operations. The name 'shittyColMajorXform' reflects a candid, informal naming style often seen in development teams under pressure. At the time, DOOM's developers were working on hardware with limited memory bandwidth and CPU power, so optimizing memory access was critical. Column-major order, while less intuitive for row-major programmers, could reduce cache misses and improve performance in specific scenarios. The function uses dynamic memory allocation to create a temporary buffer, performs the transformation, and then copies the result back to the original array. This technique, though labeled 'shitty,' was effective enough to be used in the game's wipe effects, demonstrating the pragmatic trade-offs developers made to meet deadlines. The approach influenced later games and engines, where memory layout optimization became a standard practice in high-performance graphics programming."
   - id: "color-xform-initialization"
-    line_start: 71
-    line_end: 79
+    line_start: 270
+    line_end: 274
     title: "Setting Up for a Smooth Transition"
     wikipedia_url: "https://en.wikipedia.org/wiki/Screen_transition"
     image_url: ""
     image_caption: ""
     content: "The `wipe_initColorXForm` function initializes the color transformation wipe effect by copying the starting screen into a working buffer. This setup ensures that the wipe effect begins with a clean slate, ready to interpolate between the start and end screens. In 1993, screen transitions were a novel way to enhance the visual experience of games, making level changes feel more fluid and immersive. DOOM's developers leveraged this technique to mask loading times and maintain the game's fast-paced rhythm. The function's simplicity reflects the constraints of the era, where memory and CPU cycles were precious resources. By preloading the start screen into a buffer, the game could perform incremental updates without re-reading data, a technique that influenced later real-time graphics systems."
   - id: "color-xform-execution"
-    line_start: 81
-    line_end: 125
+    line_start: 270
+    line_end: 274
     title: "Pixel by Pixel: How DOOM Wipes Screens"
     wikipedia_url: "https://en.wikipedia.org/wiki/Double_buffering"
     image_url: ""
     image_caption: ""
     content: "The `wipe_doColorXForm` function executes the color transformation wipe effect, gradually interpolating pixel values between the start and end screens. It uses a loop to traverse each pixel, adjusting its value based on the difference between the current and target states. If the current pixel is brighter or darker than its target, it increments or decrements the value by a fixed amount (`ticks`), ensuring a smooth transition. This approach was a clever workaround for the lack of hardware acceleration in 1993, relying entirely on CPU calculations to produce visually appealing effects. The algorithm's simplicity and efficiency were critical for DOOM's performance on consumer-grade PCs. Later graphics engines adopted similar techniques, often enhanced with hardware support, to create seamless transitions in games and applications."
   - id: "melt-initialization"
-    line_start: 139
-    line_end: 168
+    line_start: 270
+    line_end: 274
     title: "Randomized Melt: A Dynamic Screen Transition"
     wikipedia_url: "https://en.wikipedia.org/wiki/Screen_transition"
     image_url: ""
     image_caption: ""
     content: "The `wipe_initMelt` function initializes the 'melt' screen wipe effect, setting up column positions and randomizing their starting states. This randomness adds a dynamic, organic feel to the transition, making it visually distinct from other wipes. The function also converts the start and end screens to column-major format, optimizing memory access for the subsequent operations. Randomization was a hallmark of DOOM's design philosophy, used not just for gameplay but also for visual effects, creating an unpredictable and engaging experience. By combining randomness with memory layout optimization, the developers achieved a balance between aesthetic appeal and performance. The melt effect became iconic, influencing later games that sought to replicate DOOM's immersive transitions."
   - id: "melt-execution"
-    line_start: 170
-    line_end: 223
+    line_start: 270
+    line_end: 274
     title: "Melting Pixels: A Column-Based Transition"
     wikipedia_url: "https://en.wikipedia.org/wiki/Screen_transition"
     image_url: ""
     image_caption: ""
     content: "The `wipe_doMelt` function executes the 'melt' screen wipe effect, simulating columns of pixels sliding downward to reveal the next screen. It uses a combination of incremental updates and memory manipulation to achieve the effect. Each column's position is tracked, and pixels are copied from the end screen to the working buffer as the column progresses downward. The function also handles the transition from the start screen to the working buffer, ensuring a seamless visual effect. This technique was a testament to DOOM's developers' ingenuity, as they created visually striking effects with limited hardware capabilities. The melt effect became a memorable part of DOOM's aesthetic, inspiring similar transitions in later games and multimedia applications."
   - id: "screenwipe-controller"
-    line_start: 260
-    line_end: 301
+    line_start: 270
+    line_end: 274
     title: "The Master Switch for Screen Wipes"
     wikipedia_url: "https://en.wikipedia.org/wiki/Screen_transition"
     image_url: ""

public/programs/doom/i-sound-c.md

@@ -39,23 +39,23 @@ enhancements:
     content: "This section defines the global sound mixing buffer and the parameters for handling multiple sound channels simultaneously. The buffer is sized to accommodate 512 samples per channel, with stereo output requiring two hardware channels. At the time, consumer-grade sound cards like the Sound Blaster were common, and DOOM's sound system was designed to work within their constraints. By mixing audio from up to eight channels into a single buffer, the game could produce complex soundscapes, such as overlapping gunfire and monster growls. This approach influenced later game engines, which adopted similar techniques for real-time sound mixing."
   - id: "sound-data-loading"
     line_start: 180
-    line_end: 186
+    line_end: 249
     title: "The WAD File Trick for Fast Sound Access"
     wikipedia_url: "https://en.wikipedia.org/wiki/WAD_(file_format)"
     image_url: ""
     image_caption: ""
     content: "The `getsfx` function loads sound effects from DOOM's WAD files, padding them to ensure compatibility with the mixing buffer size. This design allowed the game to pre-cache sound data, reducing latency during gameplay. WAD files were a novel format at the time, enabling developers to bundle game assets like textures, levels, and sounds into a single file. This approach not only streamlined asset management but also inspired modding communities, as fans could easily replace or add custom sounds. The concept of bundling assets in a single file became standard practice in game development."
   - id: "sound-channel-management"
     line_start: 256
-    line_end: 394
+    line_end: 379
     title: "How DOOM Prioritized Chainsaw Sounds"
     wikipedia_url: "https://en.wikipedia.org/wiki/DOOM_(1993_video_game)"
     image_url: ""
     image_caption: ""
     content: "The `addsfx` function manages active sound channels, ensuring that only a limited number of sounds play simultaneously. It prioritizes sounds based on their age and uniqueness, with special handling for effects like the chainsaw, which are restricted to one instance at a time. This was crucial for maintaining performance on hardware with limited audio capabilities. By dynamically assigning channels and adjusting stereo separation, DOOM achieved immersive soundscapes that enhanced its gameplay. This technique influenced later games, which adopted similar methods for sound prioritization and channel management."
   - id: "sound-mixing-loop"
     line_start: 525
-    line_end: 653
+    line_end: 651
     title: "The Loop That Mixed DOOM's Audio"
     wikipedia_url: "https://en.wikipedia.org/wiki/Sound_card"
     image_url: ""
@@ -71,7 +71,7 @@ enhancements:
     content: "The `I_InitSound` function initializes DOOM's sound system, configuring the Linux OSS (Open Sound System) for audio output. It sets parameters like sample rate, stereo mode, and fragment size, ensuring compatibility with the `/dev/dsp` device. This was a significant adaptation for the Linux port, as the original DOS version relied on different APIs. By pre-caching sound data and zeroing the mixing buffer, the function prepared the system for efficient runtime audio handling. This approach demonstrated how games could adapt to diverse operating systems, paving the way for cross-platform development."
   - id: "timer-interrupts"
     line_start: 915
-    line_end: 939
+    line_end: 974
     title: "Experimental Timer Interrupts for Sound"
     wikipedia_url: "https://en.wikipedia.org/wiki/Interrupt"
     image_url: ""