Wolfenstein raycaster · laguna-s-2.1

Let me start by understanding the task. I need to build a first-person raycasting maze shooter in Wolfenstein style, all in a single self-contained `index.html` file with inline CSS and JavaScript, no external assets.

Let me plan out the key components:

1. **Raycaster**: Cast rays for each column, compute wall distance, pick a texture column, scale to wall height. Use a grid-based maze.

2. **Textures**: Procedurally generated wall textures (e.g., brick pattern), floor/ceiling maybe.

3. **Sprites/Enemies**: Billboarding enemies, with occlusion testing against walls (depth buffer).

4. **Movement**: W/S forward/back, A/D strafe, arrows turn, space shoot.

5. **Collision**: Solid wall collision using a grid.

6. **Level**: Small grid maze with exit and 3+ enemies.

7. **Health system**: Player health, enemies damage player under clear attack rule (can't damage through walls).

8. **Game states**: Playing, game over, win. Restart button.

9. **UI**: Controls display, health, enemy count.

Let me think about the structure.

**Maze/grid**: I'll define a 2D grid array. 1 = wall, 0 = empty. Place player somewhere, exit somewhere, enemies at positions.

**Raycasting**: For each ray:
- Use DDA (digital differential analysis) to walk through the grid.
- Compute perp wall distance to avoid fish-eye.
- Determine which wall texture and which side (for shading).
- Compute wall height on screen.
- Draw texture column.

**Depth buffer**: Store per-column distance so sprites know whether they're behind walls.

**Sprites**: For each enemy, compute position relative to player, sort by distance, project to screen, test against depth buffer for occlusion, draw if not occluded.

**Weapon/fire feedback**: Shoot, maybe a muzzle flash or ray. Check if hit enemy (with wall occlusion between player and enemy).

**Enemy damage to player**: When enemy is close enough and has clear line of sight (no wall between), damage player.

Let me think about the procedural textures. I can generate them on a canvas or as ImageData. A brick wall texture: red bricks with mortar. Let me create a noise/brick function.

Let me write a function to generate textures using canvas.

Actually, let me create textures as small canvases (e.g., 64x64) and fill them with procedural patterns.

Let me think about the rendering loop. I'll use requestAnimationFrame.

**Camera**: pos.x, pos.y, dir.x, dir.y (direction vector), plane.x, plane.y (camera plane for FOV). Standard raycasting setup from Lodevint's tutorial.

Let me structure the code:

```js
const canvas = document.getElementById('canvas');
const ctx = canvas.getContext('2d');
// set size
canvas.width = 800; canvas.height = 600;

// Textures
const TEX_SIZE = 64;
function makeWallTexture() { ... }
function makeFloorTexture() { ... }

// Level
const level = [
  [1,1,1,1,1,1,1,1,1,1],
  [1,0,0,0,0,1,0,0,0,1],
  ...
];

// Player
const player = { x, y, dir, ... };

// Enemies
const enemies = [ {x, y, health, state} ];

// Game state
let gameState = 'playing';
let playerHealth = 100;
let shots;

// Main loop
function loop() {
  update();
  render();
  requestAnimationFrame(loop);
}
```

Let me think about the level design. I want a small level where the player starts, must defeat 3+ enemies, then reach exit.

Let me design a simple level:

```
1 1 1 1 1 1 1 1 1 1
1 0 0 0 0 0 0 0 0 1
1 0 1 0 1 1 0 1 0 1
1 0 1 0 0 0 0 1 0 1
1 0 0 0 0 0 0 0 E 1
1 1 0 1 1 0 1 1 1 1
1 0 0 0 0 0 0 0 0 1
1 0 1 1 0 0 1 1 0 1
1 P 0 0 0 0 0 0 0 1
1 1 1 1 1 1 1 1 1 1
```

Hmm, let me make it simpler and clearly reachable. Actually the requirement is "small level with a reachable exit and at least three enemies". Let me make a moderately sized grid.

Let me think about coordinates. Player at some cell, enemies at cells, exit at a cell.

Let me make a 12x12 level.

Actually, let me write the code carefully. Let me think about each part.

**Raycasting details** (Lodevint approach):

```
for each x from 0 to screenWidth:
  // calculate ray position and direction
  cameraX = 2 * x / screenWidth - 1  // x-coordinate in camera space
  rayDirX = dirX + planeX * cameraX
  rayDirY = dirY + planeY * cameraX

  // which box of the map we're in
  mapX = floor(posX)
  mapY = floor(posY)

  // length of ray from current position to next x/y-side
  deltaDistX = abs(1/rayDirX)
  deltaDistY = abs(1/rayDirY)

  // DDA
  if rayDirX < 0:
    stepX = -1
    sideDistX = (posX - mapX) * deltaDistX
  else:
    stepX = 1
    sideDistX = (mapX + 1 - posX) * deltaDistX
  similarly for Y

  // perform DDA
  while (hit == 0):
    if sideDistX < sideDistY:
      sideDistX += deltaDistX
      mapX += stepX
      side = 0  // vertical wall
    else:
      sideDistY += deltaDistY
      mapY += stepY
      side = 1  // horizontal wall
    if map[mapY][mapY] > 0: hit = 1

  // calculate distance projected on camera direction
  if side == 0: perpWallDist = (mapX - posX + (1-stepX)/2) / rayDirX
  else: perpWallDist = (mapY - posY + (1-stepY)/2) / rayDirY

  // calculate line height
  lineHeight = floor(screenHeight / perpWallDist)

  // calculate walls to draw
  drawStart = -lineHeight/2 + screenHeight/2
  drawEnd = lineHeight/2 + screenHeight/2

  // texture
  wallTexture = map[mapY][mapX] - 1
  // compute texture x coordinate
  if side == 0: wallX = posY + perpWallDist * rayDirY
  else: wallX = posX + perpWallDist * rayDirX
  wallX -= floor(wallX)
  texX = floor(wallX * texWidth)
  if side == 0 and rayDirX > 0: texX = texWidth - texX - 1
  if side == 1 and rayDirY < 0: texX = texWidth - texX - 1

  // draw vertical slice
  for y from drawStart to drawEnd:
    texY = ((y - screenHeight/2 + lineHeight/2) * texHeight) / lineHeight
    color = texture[wallTexture][texX][texY]
    if side == 1: color = color / 2  // darken horizontal walls
    if side == 0: color = color * 3/4  // or based on side
    framebuffer[x, y] = color
```

This is a lot to do pixel by pixel on a 2D canvas (it'd be slow). Instead, I'll use putImageData to draw the whole framebuffer, or draw wall slices using ctx.drawImage with a 1-column wide source and scaling.

Actually a common efficient approach: draw columns using a pre-generated ImageData and putImageData, or use ctx.drawImage with the texture and a 1px-wide source slice scaled to wall height.

Let me use a framebuffer Uint32Array representing pixels, then use ImageData + putImageData once per frame. For a 800x600 screen that's 480000 pixels, which is fine with Uint32Array and putImageData.

Actually let me reconsider. Drawing 800 columns, each requiring a putImageData of the column would be slow. Let me use a full framebuffer approach.

Let me create:
- `framebuffer = new Uint32Array(screenWidth * screenHeight)`
- For each x, fill the column pixels in the framebuffer array.
- At end, create ImageData, fill in, putImageData once.

For floor casting (optional), I'd fill below walls. I can do a simple flat-shaded floor/ceiling. Let me add a floor texture too for nicer look, but it's optional. Let me do a simple colored floor with a floor texture for style.

Actually let me keep it focused: walls textured, floor/ceiling solid or simple texture. Let me do a floor texture using a basic floor casting or just a dark color. Wolfenstein had a floor. Let me do floor casting with a texture for authenticity. Actually, let me keep it simpler to ensure performance and correctness: solid floor color with maybe vertical gradient. But the task says "rendered a textured grid maze through a ray caster, with perspective wall heights and visible enemies. Generate textures procedurally". So walls need textures. Floor/Ceiling not strictly required but nice. Let me do a simple textured floor using floor casting.

Let me reconsider scope due to 15 min budget. Let me do:
- Textured walls (procedural brick).
- Solid floor/ceiling with gradient (or simple floor texture).
- Sprites/enemies with textures (procedural face, like a wolfenstein guard).
- Weapon sprite.
- UI overlay.

Let me think about sprites:
- Each sprite has x, y, and a texture.
- For each sprite: compute relative position (DX, DY), transform with camera matrix.
- Compute sprite screen position and size.
- Draw vertical slices, with occlusion test using ZBuffer (depth per column).
- Sort sprites back to front.

For occlusion of shots: when shooting, cast a ray from player toward a direction (mouse aim? or center?). Since mouse turning is optional and we have arrow turning, the "forward" direction is where player faces. Shoot along forward direction. Check if there's a hit on an enemy: for each enemy, cast ray, check distance to wall vs distance to enemy. If enemy is closer than the wall hit, the enemy is visible and can be hit.

Actually for shooting, I need to determine which enemy the crosshair points at. Simpler: cast a ray along the center (player's facing direction). For each enemy, check if the ray passes near the enemy's center, and whether the ray hits the enemy before hitting any wall.

Let me implement a line-of-sight / ray-to-enemy check:
- Cast ray from player position in direction of (rayDirX, rayDirY).
- Walk with DDA. If we hit a wall, record distance. 
- For each enemy, compute if the ray comes within a radius of the enemy's position at a distance less than the wall hit distance.

Hmm, that's a bit complex. Let me simplify: iterate over enemies, for each, compute angle between player-forward and enemy direction. If within some angle and the enemy is visible (no wall between player and enemy via a separate DDA line-of-sight check), then the enemy is the closest visible target. Actually shooting should target the enemy directly in the line of fire.

Let me do this approach for shooting:
- rayDir = player forward direction (or slightly toward center).
- Use DDA to find wall distance along that ray.
- For each enemy, compute the distance from player to enemy, and check if enemy is within the ray's "cone" (close to the ray). Compute closest approach of ray to enemy position. If closest approach < enemyRadius and enemy distance < wallDistance, enemy is hit.
- Among hit enemies, pick nearest.

For enemy damaging player:
- For each enemy within a certain range and with clear line of sight (no wall between enemy and player), if within attack range, damage player. Use a cooldown.

Let me define clear attack rule: enemy damages player if within distance D (e.g., 3.0 units) AND no wall blocks line between enemy and player. Maybe enemies also approach the player. For simplicity, I can have enemies move toward the player (seek) or stay in place. Let me have them stay in place but damage when close and visible. Actually, to make it more dynamic, let me have enemies wander/pursue. But let me keep it simple: enemies stay in place, damage player when within range and visible. Player kills them with shooting. This is a shooter maze. 

But if enemies stay in place and player can just shoot from distance, that's fine. But to make occlusion matter (can't shoot through walls), the player might need to move to a position where enemy is visible.

Hmm, but if enemies are static and visible from the start, then player can just shoot them from afar. But there should be walls separating them so player must navigate. Let me place enemies around corners so the player must move to get line of sight.

Actually, let me make enemies that pursue the player. They move toward the player via simple pathing (or just move toward player position ignoring collisions among themselves). When within range and visible, they attack. This makes it more engaging. But pathing near walls could be tricky and time-consuming. Let me do a simpler pursuit: enemy moves toward player's direction with DDA-based movement, stopping if a wall blocks. Actually let me keep enemies mostly static but allow them to move toward player using a simple "move toward player if path is clear" to add dynamism, with collision against walls.

Given time constraints, let me make enemies pursue the player: each frame, attempt to move enemy toward player by a small step if the next cell is walkable. This uses grid collision. Enemies won't collide with each other (can overlap) but that's fine for a simple game. Actually let me at least prevent enemies from moving through walls.

Let me reconsider—I think a good balance: enemies move toward player (simple direct movement using float positions and wall collision check), within the maze corridors. They attack when close and have line of sight. This makes an engaging shooter.

Let me think about enemy line-of-sight to player (for both attacking and for shooting visibility):
- Function `raycastVisible(px, py, ex, ey)`: cast ray from (px,py) to (ex,ey), DDA, return first wall hit distance, or whether line hits enemy first.

Actually for "can enemy see player", I'll check if any wall is between them. Compute direction to player, DDA, if first hit is a wall closer than enemy-to-player distance, blocked.

Let me just implement a helper: `castRay(px, py, dx, dy)` returning `{dist, hitX, hitY, mapX, mapY, side}` of first wall hit.

Then for enemy-to-player visibility: compute dx,dy from enemy to player, dist = sqrt(dx²+dy²). Cast ray enemy→player. If wallDist (distance to first wall) < dist... wait, need to handle the ray reaching the player position. Let me cast the ray and check if the distance to the first wall hit is greater than the enemy-to-player distance (meaning no wall between). Actually if the ray hits a wall before reaching the player distance, it's blocked.

Let me implement: 
```
function castRay(px, py, dx, dy) {
  // normalize dx,dy maybe not needed for DDA
  ...
  return {dist: perpWallDist, ...};
}
```

For enemy seeing player:
```
let dx = player.x - enemy.x, dy = player.y - enemy.y;
let dist = Math.hypot(dx, dy);
let stepX = dx/dist, stepY = dy/dist;
let res = castRay(enemy.x, enemy.y, stepX, stepY);
if (res.dist > dist - enemyRadius*0.5) { /* no wall in between, visible */ }
```

Hmm, but player is a point, enemy has radius. Let me just check if the ray reaches approximately the player distance without hitting a wall. So if res.dist >= dist (wall is beyond player), visible.

For shooting the enemy: similar, cast ray from player forward, find nearest enemy along that ray that's visible.

Let me simplify the shooting: I'll check all enemies: for each enemy, compute the angle to it relative to player facing. If angle within weapon spread (say ±2 degrees) and the enemy is within weapon range with clear line of sight, it's a candidate. Pick the nearest. That's a reasonable "aimed shot". But simpler: use a ray and check closest approach.

Let me use the closest-approach method:
```
function shoot() {
  let hit = null;
  let aimX = dirX, aimY = dirY; // forward
  let wallDist = castRay(player.x, player.y, aimX, aimY).dist;
  let bestDist = wallDist;
  for each enemy alive:
    // closest approach of ray from player to enemy
    let ex = enemy.x - player.x, ey = enemy.y - player.y;
    let t = ex*aimX + ey*aimY; // projection along ray
    if t <= 0: continue; // behind
    let perp = Math.abs(ex*aimY - ey*aimX); // perpendicular distance
    if perp < enemyRadius:
      if t < bestDist:
        bestDist = t;
        hit = enemy;
  if (hit) { hit.health--; if dead, remove; }
}
```

Wait, this needs the ray direction normalized. dirX, dirY should be normalized (unit vector). Let me ensure dir is normalized.

Also need to make sure the enemy is actually within wallDist (not behind a wall). Since bestDist starts at wallDist and we find t < bestDist, that means enemy distance t is less than wall distance, so enemy is in front of the wall (visible). Good. But I should also confirm there's no wall between player and enemy closer than t. The wallDist is the distance to the first wall in the aim direction; if enemy distance t < wallDist, then enemy is before the wall, so visible. But the enemy might not be exactly on the ray—there's perpendicular offset. The wallDist is along the ray centerline. If enemy is offset, the actual wall could be closer. For simplicity this is acceptable; enemies have some radius and the player aims generally. Actually, to be more correct, I should cast a ray to the enemy position. But closest-approach is a reasonable approximation. Let me make enemy radius small (0.3) and aim reasonably. Actually, let me make shooting snap to center and check each enemy's exact line of sight.

Let me reconsider to be robust: For shooting, iterate enemies, for each alive enemy:
- Check if enemy is within forward cone (angle between player forward and enemy direction < some spread).
- Check line of sight: castRay(player.x,player.y toward enemy) and see if first wall is beyond enemy.

Then pick nearest visible enemy in cone as the target. That's clear and correct (no wall). Let me do that.

For the cone: since mouse aiming isn't required and we aim forward, let me give a small spread based on... actually let me just aim exactly forward and check if enemy is roughly on the ray. But enemies standing still exactly on the forward ray is rare. Hmm.

Let me reconsider: maybe the player should aim with the mouse position? But mouse turning is optional. Let me allow optional mouse-look-free aiming: the weapon shoots straight ahead along forward direction, but with a generous hit detection (closest approach within enemy radius). That works if enemies are positioned where the forward ray passes near them. But the player might aim at an enemy not centered.

I think closest-approach with a decent radius is the cleanest. Let me use enemy radius 0.4 and ensure the ray-to-enemy check passes if perpendicular distance < enemy radius AND enemy distance < wall distance along that perpendicular line. To be fully correct about walls, cast a ray from player toward the enemy's exact position; if the distance to first wall > distance to enemy, enemy is visible. Then pick the nearest visible enemy whose angle from forward is within weapon spread.

Let me combine: 
```
shoot forward ray (aimX, aimY).
for each alive enemy:
  compute dx=ex-px, dy=ey-py, dist.
  angle = atan2(dy,dx); angleDiff = wrap angle - playerAngle; |angleDiff| < spread? 
  visible = castRay(px,py, dx/dist,dy/dist).dist > dist (no wall before enemy)
  if in spread and visible and dist < bestDist: target=enemy, bestDist=dist
```
This is robust. Weapon spread ~ the crosshair. Let me set spread to a moderate value, like player can hit enemies fairly centered. Actually let me make spread fairly wide (e.g., 8 degrees) so it's playable, or even just "the enemy is roughly in front". Hmm, but then players could hit enemies far to the side. For a simple game that's fine. Let me use a crosshair and a focused shot: spread of about the crosshair size. Let me make spread ~5° to keep it shooter-like but forgiving.

Hmm, let me reconsider. Actually since aiming is fixed forward (no mouse), let's make the weapon fire a hitscan straight forward. For gameplay, enemies should be positioned so the player can face them and shoot. With closest-approach checking, a radius of 0.5 means the enemy occupies a chunk of the ray's path. Let me make this work.

Actually you know what, let me allow mouse aiming optionally—if the user moves the mouse, aim slightly. But the task says mouse turning optional and must not be required. Aiming forward is the default. Let me support: mouse movement rotates the view (optional enhancement) but it's not required to play. The crosshair is at center; shooting goes straight forward.

For shooting with forward-only aim, I'll use closest approach within a small distance and ensure no wall before the enemy. Let me pick enemy radius ~0.6 for easier hits and check visibility via raycast. Actually with enemies pursuing the player, when they get close they're near the forward direction likely. Good enough.

Let me not over-engineer. Let me make enemies pursue, and shooting uses closest-approach + line-of-sight. Let me set the hit tolerance to a reasonable value.

OK here's another consideration: performance. requestAnimationFrame at 60fps, raycasting 800 columns each frame on a Uint32 screen = 480k pixel writes + putImageData. That's fine. Plus sprite rendering and floor. Let me target maybe 640x480 or 800x600. Let me do 800x600.

Let me also add a floor: floor casting. For each y below the horizon, compute floor distance and sample floor texture. This is a lot of per-pixel work but doable with Int32Array (fixed-point). Lodevint floor casting is reasonably fast. But to keep it simpler and ensure performance, let me do a simpler floor: a horizontal gradient or a checker/textured strip. Actually, let me do a proper-ish floor texture with floor casting for the styled look. If performance is an issue, I can fall back.

Hmm, time budget is tight (15 min). Let me prioritize core gameplay and ensure it runs. Let me include:
- Textured walls (brick).
- Solid dark floor with gradient toward horizon + maybe a simple floor texture.
- Sprites (enemies, weapon Bob? weapon is a sprite at bottom).

Let me do a flat floor with color based on distance (darker far) and a ceiling color. Actually a procedural floor texture would look better. Let me do floor casting with a simple floor texture (e.g., a tiled floor pattern). I'll generate a floor texture canvas.

Let me think about what looks good and runs well. I'll implement floor casting using fixed-point arithmetic similar to Lodevint, sampling a floor texture. This is the classic look. Let me do it but keep floor texture resolution moderate (64x64).

Actually, let me reconsider the whole rendering approach for performance and simplicity. An alternative: render to an offscreen canvas with a smaller resolution (e.g., 400x300) and scale up. This gives retro pixelated look and ensures performance. Wolfenstein was low-res. Let me render at, say, 320x240 or 400x300 and upscale with image-rendering: pixelated. That ensures smooth performance and a retro feel. But the UI needs to overlay. Let me render the 3D view at a scaled resolution onto the main canvas, then draw UI on top.

Hmm, mixing scaled canvas and UI. Let me do: canvas at full size (e.g., 800x600) but render 3D at a base resolution scaled up. Actually simpler: render full 800x600 framebuffer. Modern JS can handle 800 columns DDA easily. The putImageData of 480k pixels is ~1.9MB, done every frame, should be fine for 60fps but maybe a bit heavy. Let me render at a base res and scale up via drawImage with pixelated scaling. 

Decision: Render 3D scene into an offscreen framebuffer of width W (e.g., 320) and full height matching aspect. Actually let me render to offscreen canvas of 320x240, then drawImage scaled to canvas 800x600 with 'pixelated'. Then overlay UI. This is efficient and gives retro style. But sprites would be small at 320. That's fine, classic.

Wait, but I want enemies to be visible and the game to look decent. 320x240 upscaled to 800x600 is fine and retro. Let me do 400x300 upscaled to 800x600 (2x). Or render directly to screen at 640x480. Let me just pick canvas 960x600 (16:10) and render framebuffer at 320x200 (that's 4.8 ratio, hmm). Let me keep aspect: render res 480x320, upscale 2x to 960x640. Good.

Actually, let me simplify and just render to the main canvas at 800x600 directly using a Uint32Array framebuffer and putImageData. 480000 pixels * 60 = 28.8M operations/frame for the framebuffer clear (fill whole), plus wall columns (800 columns, each ~height 300 on average = 240k pixel writes), plus floor. Should be OK in JS, maybe ~60fps or close. But putImageData on 480k each frame might be ~30-60fps. To be safe and ensure smoothness, let me render at lower resolution and upscale. I'll go with render resolution 480x320 drawn to offscreen canvas, scaled 2x to 960x640 (I'll set canvas 960x640). Hmm, 960x640 display. Fine. Let me actually keep canvas at 800x600 and render res 400x300 scaled 2x.

Let me go with: canvas display 800x600, render framebuffer 400x300, scaled up 2x with image-rendering pixelated.

For the offscreen, I'll create an ImageData of 400x300 and use ctx (on main canvas) to drawImage the ImageData scaled... Actually, drawing an ImageData scaled: I can putImageData then... no, putImageData places pixels 1:1. To scale up an ImageData, I'd drawImage the offscreen canvas to main canvas. So I need two canvases: offscreen (400x300) with its own 2D context for putImageData, and main canvas context drawImage offscreen scaled.

Plan:
- Create offscreen canvas `off = document.createElement('canvas'); off.width=400; off.height=300; offctx = off.getContext('2d');`
- framebuffer via offctx.getImageData(0,0,400,300).
- Each frame: compute framebuffer into the ImageData's Uint32Array, then offctx.putImageData, then mainCtx.drawImage(off, 0,0,800,600).
- Then UI drawn on mainCtx.

This works. Good.

Hmm, but actually, getImageData then putImageData each frame—fine.

Alternatively use main canvas ImageData directly and skip scaling (render at 800x600). Given complexity, let me just render at the display resolution 800x600 directly. Let me estimate performance: For each column, DDA walks maybe ~10-30 cells, fast. Then drawing the textured wall column to framebuffer: ~wallHeight ~ 100-400 pixels, *800 columns = ~320k writes. Floor casting: for each y from horizon to bottom, ~300 rows * 800 cols = 240k, with texture sampling. That's a lot (~560k per frame). Could be slow-ish but probably ~40-60fps. To be safe, render at 400x300 (quarter pixels) → 140k writes for walls + 120k for floor = 260k... still, but putImageData of 120k is much cheaper. And scaling 2x looks nice and retro.

Let me go with render at 400x300 upscaled 2x. Decided.

Wait, but UI text would be tiny at 400x300 if I draw UI on the offscreen. Let me draw UI (health, enemy count, controls) on the main canvas AFTER upscaling, at 800x600 resolution, so text is crisp. The 3D view is upscaled, UI is hi-res on top. That's fine visually.

Hmm, the upscaled 3D view + hi-res UI on top might look slightly inconsistent but that's OK and common in retro games.

Actually, to keep consistent, let me draw UI also scaled. Eh, let me just draw UI at native main canvas res. It's fine.

Let me now also handle the weapon: I'll draw a weapon sprite (procedurally a gun shape) at the bottom center of the screen, shown during play, with muzzle flash on shoot. This is the "weapon feedback".

Let me also handle crosshair.

Let me now write the code. Let me structure functions:

1. `initTextures()` - create wall, floor, enemy, weapon textures as canvases.
2. `initLevel()` - define level grid, player start, enemies, exit.
3. `resetGame()` - reset player, enemies, health, state.
4. `castRay(px, py, dx, dy)` - DDA returning wall hit info + perp distance.
5. `castRayTo(px,py, dx, dy)` maybe for visibility.
6. `update()` - movement, enemy AI, shooting, game logic.
7. `render()` - clear, floor casting, wall raycasting, sprites, then UI, then upscale.
8. Input handling.

Let me think about textures generation:
- Wall (brick): a function making a 64x64 canvas with red bricks.
- Floor (stone tiles): 64x64 pattern, maybe a dark tile.
- Enemy sprite: a face. Procedural, maybe a yellow/red wolfenstein guard-ish. I'll make a 64x64 enemy texture (or 128x128) with a face.
- Weapon: I'll just draw a simple gun shape procedurally on canvas (e.g., a pistol shape using fillRect/polygon) rather than a textured sprite. Or a texture sprite. Let me draw the weapon with canvas shapes directly at screen position (cheaper, and it's always visible). A simple pistol silhouette. On shoot, draw muzzle flash lines.

Actually, "visible enemies" need a sprite texture (enemies). Weapon can be a drawn shape. Let me do that.

Let me reconsider enemy rendering with occlusion. The Z-buffer approach: store `zBuffer[x]` = perpWallDist for each column (distance to wall). For sprite drawing, for each column of the sprite on screen, compare sprite distance to zBuffer[col]; if sprite is closer (smaller perp distance), draw the pixel. Standard.

For enemies, I'll give each a texture (a face). Enemies are points at (x,y) with a height; they billboard. Their distance from player = sqrt((x-px)²+(y-py)²). For zBuffer comparison, I need the perpendicular distance. Sprite distance perpendicular = spriteDist * cos(angle) roughly, or use the transform's side distance. Lodevint computes `perpWallDist = (transformY)` something. Let me follow Lodevint:

```
for sprite:
  dx = sprite.x - player.x
  dy = sprite.y - player.y
  // transform sprite with camera matrix
  invDet = 1 / (planeX*dirY - dirX*planeY)
  transformX = invDet * (dirY*dx - dirX*dy)
  transformY = invDet * (-planeY*dx + planeX*dy)  // distance to sprite, perpendicular
  // if behind, skip if transformY <= 0
  spriteScreenX = (int)(w/2) * (1 + transformX/transformY)
  spriteScreenY = ... 
  // perpDist = transformY (perpendicular distance)
```

The transformY is the perpendicular distance. Use that for zBuffer comparison and sorting.

The sprite's apparent size: `spriteHeight = abs(int(h / transformY))`. The sprite occupies screenY to screenY+spriteHeight.

Then for drawing each column:
```
for texX in spriteWidth:
  for y in spriteHeight:
    // sample sprite texture
    if (perpDist < zBuffer[screenX + texX]): draw pixel
```

Actually more precisely, compare transformY to zBuffer. Let me store zBuffer as the perp distance per column. Good.

I'll sort sprites by transformY (furthest first) and draw back to front.

Now, enemy as a point but should occupy a floor position; the sprite represents the enemy's body. Fine.

Let me make sure enemies are occluded: since we compare against zBuffer from walls, if a wall is closer than the enemy in a given column, the enemy pixel isn't drawn. Good. But the enemy also shouldn't be drawn when completely behind wall. If transformY > zBuffer everywhere across the sprite's columns, nothing draws. Good.

But subtle: an enemy partially behind a wall should be partially drawn up to the wall. The per-column depth check handles that, drawing the enemy up to where the wall is. That requires drawing from the near edge... actually the standard approach draws all sprite pixels and lets depth test hide the far ones. So enemy pixels that should be hidden by a nearer wall are hidden, and visible ones show. That gives the right effect (enemy appears in front of a wall only where the wall is farther). But physically, if a wall is in front, the enemy behind it shouldn't show at all. Since we use the wall's zBuffer which is the first wall hit distance, and enemy behind wall has transformY > wallDist in those columns → hidden. For columns where enemy is in front of wall (visible), drawn. This is correct enough. Good.

Now let me consider the exit: when all enemies defeated, the exit becomes active (e.g., glows, open door). Reaching it (player steps on exit cell) → win.

Let me define the exit cell and detect collision: if player inside exit cell region, win. Need player close to exit.

Level design: ensure exit is reachable and there's a path to all enemies and back. Let me design carefully with a small open-ish maze.

Let me design a level (grid, 0=empty, 1=wall). I'll mark P player, E enemy, X exit. Dimensions ~16x16 or 12x12. Let me make a navigable one.

Let me sketch a 16x16:

```
Row 0:  1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
Row 1:  1 0 0 0 1 0 0 0 0 0 1 0 0 0 0 1
Row 2:  1 0 1 0 1 0 1 1 1 0 1 0 1 1 0 1
Row 3:  1 0 1 0 0 0 0 0 1 0 0 0 0 0 1 1  (hmm)
```

This is getting complex; let me simplify to a 12x12 with clear rooms and corridors. Let me design so enemies are around corners.

Let me define a level that's essentially a few rooms connected. Let me hand-design:

Grid 12x12 (indices 0..11). I'll place walls.

Let me write the level as:
```
1 1 1 1 1 1 1 1 1 1 1 1
1 0 0 0 0 1 0 0 0 0 0 1
1 0 1 1 0 0 0 0 1 1 0 1
1 0 1 0 0 0 0 0 0 1 0 1
1 0 0 0 0 0 0 0 0 0 0 1
1 1 0 0 1 1 1 1 1 1 1 1
1 0 0 0 0 0 0 0 0 0 0 1
1 0 1 1 0 0 0 0 1 1 0 1
1 0 0 0 0 0 0 0 0 0 0 1
1 1 1 1 0 0 X 0 0 1 1 1   (X=exit)
1 P 0 0 0 0 0 0 0 0 1    (P=player)
1 1 1 1 1 1 1 1 1 1 1 1
```

Hmm the last row player at (1,10)? Wait indexing. Let me just place coordinates in code.

Actually let me make it cleaner. Let me use a 13x13 grid with a central arena and corridors. But let me not hand-design too carefully; the key constraints:
- Player starts at a place with a clear path.
- Exit reachable only after enemies defeated.
- 3 enemies, each reachable but possibly behind walls from other positions (so shooting-through-walls matters).

Let me just make a simple open-ish level with some walls so line-of-sight matters. Even if enemies are mostly visible, the occlusion rule (no shooting through walls) is still enforced in code.

Let me design a level where enemies are in separate rooms connected by doorways—so to shoot an enemy, the player must be in the same room or have clear sight. Good.

Let me create a level:
```
grid (y from top=0):
y0: 1 1 1 1 1 1 1 1 1 1 1 1 1
y1: 1 0 0 0 0 0 1 0 0 0 0 0 1
y2: 1 0 1 1 1 0 1 0 1 1 1 1 1   (room wall)
y3: 1 0 1 E 1 0 0 0 0 0 0 0 1   (E enemy at (3,3))
y4: 1 0 1 0 1 0 1 1 1 1 0 0 1
y5: 1 0 0 0 0 0 1 0 0 0 0 0 1
y6: 1 1 1 1 1 0 0 0 0 0 0 0 1  ... 
```

This is getting complicated. Let me just write the level as a 2D array in code, keep it modest, and verify by running. I'll iterate.

Let me settle on a 15x15-ish level with rooms. Actually, let me keep 13x13.

I'll define it and place:
Player at (1,1) facing east (dirX=1).

Let me build levels that have:
- Starting area (room with player).
- Corridors to enemy positions.
- Exit in a final room.

Let me write the level now. I'll make it and tweak after testing.

Let me define cells (x,y), x is column (0=left), y is row (0=top). 1=wall.

Level 13x13:
```
y0  1 1 1 1 1 1 1 1 1 1 1 1 1
y1  1 0 0 0 0 0 1 0 0 0 0 0 1
y2  1 0 1 1 0 0 1 0 0 1 1 0 1
y3  1 0 1 0 0 0 0 0 0 0 1 0 1
y4  1 0 1 1 1 1 0 1 1 1 1 0 1
y5  1 0 0 0 0 0 0 0 0 0 0 0 1
y6  1 1 0 0 1 1 1 1 1 0 0 1 1
y7  1 0 0 0 0 0 0 0 0 0 0 0 1
y8  1 0 1 1 0 1 0 1 0 1 1 0 1
y9  1 0 0 0 0 0 0 0 0 0 0 0 1
y10 1 1 1 0 0 0 0 0 0 0 0 0 1   ... hmm
```

I'll finalize in code. Let me place 3 enemies at distinct reachable cells and the exit in a cell reachable only after a path.

Actually, let me simplify: I'll make a level and just ensure connectivity by testing movement. Let me not overthink; I'll create a reasonable level, run it, move around, and adjust if a wall blocks movement to exit.

Let me decide final structure and write code. I'll aim for robust code.

Let me now also handle controls display: an overlay showing "W/S move, A/D strafe, Arrows turn, Space shoot". Display in top-left or bottom.

Health: show hearts or a number. Enemy count: show "Enemies: N".

Game over: overlay text + restart button. Win: overlay + restart.

Restart button: a DOM button positioned over canvas (or drawn and clickable). Easier: a DOM button element. But the task wants it in index.html self-contained; DOM elements are fine. Let me add a restart button that's shown on game over/win, and maybe always accessible. I'll create it via HTML/DOM button and style it.

Actually, since everything is in index.html, I can include a <button id="restartBtn"> in HTML and show/hide it. Or draw a restart button on canvas and handle click. DOM button is simpler for reliability. Let me include DOM button and also a key (R) to restart.

Let me set up HTML structure:
```html
<canvas id="c"></canvas>
<div id="ui"> health, enemies, controls </div>
<button id="restartBtn">Restart</button>
```
And maybe a start screen. I'll handle game states with overlays drawn on canvas too. Let me keep overlays on canvas (drawn) for the win/lose, plus a DOM restart button. Simpler: draw everything on canvas including buttons? Click detection for buttons on canvas is doable. But DOM button is more reliable for "Restart to restore". Let me use a DOM button positioned with CSS, hidden by default, shown on win/lose. And also R key.

Let me write the code now. I'll be careful.

Let me write helper for fixed timestep update (e.g., 60Hz) and interpolate. Actually simpler: update on key state each frame with deltaTime. Movement speed * dt.

Input: track pressed keys in a set.

Let me define:
```js
const keys = {};
window.addEventListener('keydown', e => keys[e.code]=true);
window.addEventListener('keyup', e => keys[e.code]=false);
```
Codes: KeyW, KeyS, KeyA, KeyD, ArrowLeft, ArrowRight, Space. Also KeyR for restart, KeyM? no.

Also pointer lock for mouse? Optional. Let me add optional mouse turning: on mousemove with button held, rotate. But not required. I'll add a subtle mouse-look that's optional and disabled by default (needs pointer lock click). Actually to avoid complications, let me skip mouse entirely (it's optional). I'll mention mouse optional. Keep it arrow keys only. Good—simpler and meets "mouse turning is optional and must not be required".

Wait, requirement: "A/D to strafe, Left/Right arrows to turn". So arrows turn, A/D strafe, W/S forward/back. Let me implement exactly that. Space to shoot.

Let me write movement:
```js
function update(dt) {
  const rotSpeed = 2.0 * dt;
  const moveSpeed = 3.0 * dt; // per second, cells
  if keys.ArrowLeft: player.angle += rotSpeed; (or dir/plane rotation)
  if keys.ArrowRight: player.angle -= rotSpeed;
  // move
  if keys.KeyW: move(forward)
  if keys.KeyS: move(back)
  if keys.KeyA: move(left strafe)
  if keys.KeyD: move(right strafe)
  if keys.Space: shoot(); (with cooldown)
  // enemies
  updateEnemies(dt);
  // check win / game over
}
```

I'll represent player with pos (x,y) and angle, plus dirX/dirY derived. Let me store dirX,dirY,planeX,planeY and rotate the vectors directly (avoid angle wrap). Rotation by angle: 
```
newDirX = dirX*cos - dirY*sin
newDirY = dirX*sin + dirY*cos
newPlaneX = planeX*cos - planeY*sin
newPlaneY = planeX*sin + planeY*cos
```
Where cos/sin from rotSpeed. This is the standard.

Movement with collision: compute new pos, check if new pos collides with wall (the cell at that position). Use a small radius for player. Check the four corners or sample. I'll check that the cells around new pos are empty. Simple: if map cell at floor(newX) and floor(newY) is wall, block. But need to allow moving along walls. I'll check using a player radius: check the cells the player's bounding box would occupy. Let me check multiple points (e.g., player radius 0.3): for each corner of the box at new position, if that cell is a wall, block that axis.

Let me implement a `movePlayer(dx, dy, moveSpeed)`:
```
let nx = player.x + dx*moveSpeed;
let ny = player.y + dy*moveSpeed;
// collision: check cells around
let r = 0.25;
if (!cellSolid(nx+r, ny) && !cellSolid(nx-r, ny)) player.x = nx; // allow movement along
... 
```
Hmm standard approach: separate X and Y movement, check collision on the moved axis only:
```
function tryMove(mxv, myv) {
  let nx = player.x + mxv;
  let ny = player.y + myv;
  let r = 0.25;
  // X
  if (!solid(nx+r, player.y) && !solid(nx-r, player.y)) player.x = nx;
  if (!solid(player.x, ny+r) && !solid(player.x, ny-r)) player.y = ny;
}
```
where solid(x,y) checks map cell. This allows sliding along walls. Good.

For enemies moving toward player, similar collision.

Now shooting: on Space, with cooldown (e.g., 0.3s between shots). On fire, set weapon state (muzzle flash) and call hit detection. Also maybe recoil. Let me set a `player.shootTimer` and `player.state` to show weapon firing.

Weapon feedback: muzzle flash at muzzle position (bottom center). I'll draw the weapon sprite; when firing, overlay a flash and play... no audio (no external? audio is fine generated via Web Audio, but let me skip audio to keep simple, or add simple beep via oscillator—optional). Let me skip audio. Visual muzzle flash suffices for "weapon feedback".

Let me also add a crosshair at center.

Now let me think about textures again to make them look Wolfenstein-y:
- Wall texture: red brick with dark mortar, vertical brick offset on alternate rows. I'll generate with a noise-ish or pattern.
- Enemy texture: a face. Wolfenstein guards are tan with black. I'll generate a simple face: tan background, eyes, teeth, hat. Hard to do nicely procedurally but doable.
- Floor texture: maybe a simple tile. Or floor casting with a floor texture that's a dark stone.

Let me generate textures via canvas 2D drawing procedurally (no external images).

Let me write `makeBrickTexture(size)`:
```
const c = document.createElement('canvas'); c.width=c.height=size;
const ctx = c.getContext('2d');
// base
ctx.fillStyle = '#8B0000'; ctx.fillRect(0,0,size,size);
// bricks
const brickW = size/4, brickH = size/2;
ctx.fillStyle = '#A00000'; // slightly lighter bricks
// draw bricks with mortar
for rows... 
```
Let me do a proper brick pattern: each row offset by half brick every other row. Mortar = dark lines.

Actually let me make brickW = size/4, brickH = size/8, so 8 rows of 4 bricks. Mortar gaps of 1px. Alternate rows offset by brickW/2. Color bricks with slight random variation for richness. Let me add perlin-like noise? Simpler: random tint per brick.

Let me generate:
```
for (let y=0;y<size;y+=brickH) {
  let offset = ((y/brickH) % 2) ? brickW/2 : 0;
  for (let x=0;x<size;x+=brickW) {
    ctx.fillStyle = random shade of red;
    ctx.fillRect(x+offset, y, brickW-1, brickH-1);
  }
}
```
That gives brick look. Good enough.

Let me also add a second wall texture variant (e.g., a different color) for variety, and use different textures for different walls. Actually requirement just needs textured maze; one texture is fine but variety is nice. Let me make 2-3 wall textures: brick red, stone gray, dark. I'll map wall type to texture. Since my level uses 1 for wall, let me encode texture id in the cell value: 1,2,3 for different textures. I'll design level with mixed textures. Let me keep it: use texture based on cell value mod something. Let me make all walls a brick texture to be safe, plus maybe a variation. I'll add a couple textures and assign by position (e.g., (x+y)%2 picks one of two brick colors). Actually let me just have 2 textures and pick `(x+y)%2` for variety, or based on cell==1 → brick, cell==2 → stone.

Let me keep level using 1 for wall (brick) and 2 for wall (stone) and 3 for wall (dark). I'll place some stone walls for the exit room for visual distinction. The exit room walls = special texture (e.g., cracked/open). When exit is locked, render exit walls as solid; when unlocked, render as open gate or different.

Hmm, let me make the exit a distinct door that opens. Exit is at a cell; the cell where exit is located is empty (0) but surrounded by walls; when all enemies dead, the exit cell shows a glowing portal or the door opens. Reaching the exit cell triggers win. Let me make the exit always there (empty cell) but only "active" (win triggers) when enemies are gone. To show it's locked, I'll render a closed door (a wall segment with door texture) that becomes open when unlocked. Simpler: keep exit cell as empty but draw a portal sprite/portal effect when unlocked, and when locked draw a locked door in that cell. When player reaches the cell while unlocked, win.

Let me implement exit as a cell with a "door" that's open when unlocked. The door is just a wall with a door texture; when unlocked I set that cell to 0 (empty) so the player can walk through and reach... hmm if it's open the player walks through it. Let me define exitCell; when locked, treat that cell as a wall (impassable) with door texture; when unlocked, set to empty so path opens and reaching the center triggers win. Actually the exit should be a destination the player walks into.

Let me simplify: The exit is located at a cell that is normally passable (empty) but only "active" (win) when all enemies are dead. To communicate locked state visually, when locked, I'll draw a locked-door sprite/portal on that cell (a billboarded sprite or a floor marker) but the cell remains walkable... no, if walkable player could exit early. 

OK let me make it concrete: 
- Exit cell is a special cell value `2`? No, 2 = wall. Let me use a separate structure: exitX, exitY. The cell at (exitX,exitY) is normally `0` (empty). When the player's position is within the exit cell (floor rounding) AND exit is unlocked → win. When exit locked, render a "closed" door (draw a door quad on the floor / a wall texture at that cell). 

To prevent walking out early while locked, when locked I'll make that cell solid (impassable) by checking in solid(): if cell is exit cell and locked → solid. Then when unlocked, cell becomes passable and the player can enter to win. And I render a door wall at that cell when locked, and remove it when unlocked.

So: a cell-value-based map plus dynamic exit cell. The exit cell is empty in the map (0) but my collision function returns solid if (x==exitX && y==exitY && !exitUnlocked). When locked, render an extra wall quad at that cell with door texture. When unlocked, render nothing (open) and player can walk in to win. 

That works nicely: closed door blocks passage; unlock opens it; walk in → win.

Let me implement exit rendering: when locked, treat the exit cell as a wall for raycasting and drawing. Actually simplest: incorporate into raycast—when the DDA steps into the exit cell while locked, treat as wall with door texture. I can modify solid/raycast to check exit condition. Let me make a function `cell(x,y)` that returns what to treat: if (x,y)==exit and locked → 1 (wall) for raycasting, else map value. For rendering texture, door texture if exit cell locked.

Let me just handle it: in raycast, after computing mapX,mapY, check `if (mapX==exitX && mapY==exitY && !exitUnlocked) { hit, texture=door }`. And the map cell value there in `level` could be 0; we override.

For collision (player/enemy movement), solid check: return true if cell is wall OR (cell is exit and locked). Good.

Now let me write the code. Let me also handle player start: ensure not in wall.

Let me now actually write the full index.html.

Let me think about the rendering pipeline in `render()`:

```
function render() {
  // 1. clear framebuffer (floor/ceiling) - do floor casting which fills everything outside walls
  // 2. raycast walls column by column into framebuffer, fill zBuffer
  // 3. floor casting for floor/ceiling (do before walls so walls overwrite)
  // 4. sprites (enemies) back to front, compare zBuffer
  // 5. draw weapon + crosshair + UI
}
```

Order: clear; floor+ceiling; walls (with zBuffer); sprites; then upscale to main canvas; then UI.

For floor casting, I'll do it after walls actually it doesn't matter much, but typical: clear with ceiling color, floor cast floor, then walls on top, then sprites. Let me:
- Fill framebuffer ceiling (top half) with a color (or cast ceiling texture).
- Floor cast floor (bottom half) with texture + z.
- Walls (overwrite with texture, set zBuffer).
- Sprites (depth test against zBuffer).

Let me implement floor casting: For each y scanline below the horizon (the midpoint is where wall is; but walls of varying heights, floor starts at max wall drawEnd for each column? Classic floor casting uses a per-column "floor start" which is the bottom of the wall slice. To keep simple, I'll cast floor from a fixed horizon line (center of screen) down. This means floor casting draws up to the horizon regardless of wall height; walls drawn afterward on top. But walls have varying heights, and floor should start just below the wall bottom. Using fixed horizon = floor starts at screen middle; walls drawn on top cover the area up to wall height. But the area between wall bottom and horizon would be floor color—wrong, should be wall base. Hmm. Actually for floor casting you should only cast floor for pixels below the wall's drawn bottom, per column. 

To keep it correct but simpler, let me compute wall heights first into an array `wallBottom[x]`, then cast floor for each column from wallBottom[x] down to bottom. That's the correct approach but floor casting with varying start per column is fine.

But floor casting per column per pixel with texture sampling is heavy. At 400x300 that's 200*400=80k pixels with divisions. Might be okay. Let me do a simpler floor: just a solid color with a vertical gradient (darker at horizon). Actually a textured floor looks much better. Let me do floor casting but only for columns, using fixed-point. Let me attempt and see performance; if slow, degrade.

Actually, let me reduce render res to 320x240 to ensure performance, upscaled 2x (with canvas at 640x480, but I wanted 800x600). Let me set main canvas 640x480 and render res 320x240 upscaled 2x. That gives good perf and retro look. Or 800x600 canvas with 400x300 res up by 2x. Let me go 800x600 canvas, 400x300 render res. I think 400x300 floor casting is fine.

Hold on, let me reconsider floor casting necessity. The requirement: "Render a textured grid maze through a raycaster, with perspective wall heights and visible enemies. Generate textures procedurally". Floor texture not required. To ensure performance and reduce risk, let me do a **simple floor**: solid dark color with a gradient based on row (darker at top = far). And a ceiling solid color (darker). This avoids floor-casting math and is fast, still looks decent. Actually a flat floor with no texture looks plain but is acceptable; the requirement is walls textured + enemies. But "Wolfenstein-inspired style" suggests floor textures. Hmm.

Let me compromise: do floor casting but keep it efficient using the standard Lodevint approach operating on a separate floor framebuffer only for the bottom half. Actually, let me just attempt the full textured floor casting; if performance acceptable, keep; else simplify. Given I'll test in browser, I can judge FPS and adjust. But time is limited. Let me implement a reasonably efficient floor casting and also be ready to simplify.

Let me estimate: 400 wide × ~160 rows below midpoint = 64k floor pixels. Each needs: compute floor distance via fixed point (division), sample texture, combine with light. That's ~64k * (a few ops) per frame. JS ~ 64k iterations is trivial (<5ms). Plus 400 wall columns with DDA (~10-30 steps each = ~8k steps) and texture vertical slice drawing (sum of wall heights ~ 400 × ~200 = 80k pixel writes). Plus sprites. Total maybe ~150k operations. Should be ~20-40fps. Acceptable. At 320x240 even faster. Let me maybe render at 400x300 but if I see perf issues, I'll lower. Let me also keep the option to disable floor texture (flat) if needed.

Let me just implement and test. I'll make render resolution configurable.

Decision: render at 640x480? Let me do 640x480 canvas and render res 320x240 upscaled 2x. Simpler numbers, fast. Actually 800x600 is a more standard window. Let me do canvas 800x600, render 400x300. I'll commit.

Let me now also reconsider: the framebuffer Uint32 for 400x300 = 120k pixels, putImageData once/frame to offscreen, then drawImage upscale. Good.

Let me write the floor casting. Standard approach:
```
const horiz = RHALF; // row of horizon (3/4? actually floor starts below wall bottoms; let's use the midpoint = 160 for a 320-height... but walls extend from middle. Let me use HORIZON = 240 (center of 300? no, 300/2=150). For 400x300, center=150.
// We'll draw floor from row = max wall bottom per column? Use fixed: floorRows from 150..300? But walls above 150 too. Let me compute wallBottom[x] first.
```
Let me do: after raycasting walls, store wallBottom[x] = drawEnd. For columns where no wall draws to the bottom (drawEnd = floor bottom of wall, which for distant walls is small and there's gap below wall to floor). So floor should be cast from wallBottom[x] down to bottom. For columns with wall drawEnd < bottom. For close walls drawEnd ≈ bottom.

So floor cast per column from wallBottom[x] to H-1. Let me implement:

```
for x in 0..W:
  for y = wallBottom[x]..H-1:
    // floor casting: compute floor coordinate from y
```

But floor casting usually iterates by row for efficiency using the distance interpolation. The Lodevint floor casting iterates per row with left/right distance. Let me do the per-row approach for speed:

For each row y from HORIZON (=H/2) to H-1:
  // compute perpendicular distance to floor point at this row (assuming floor at distance... the row corresponds to a floor distance)
 Actually Lodevint: for row y, the distance is `dist = (distWall) / (H/2 - y)` style but using a reference. Let me recall floor casting algorithm:

```
for y = H/2 + 1 to H-1:
  // find distance of the first non-empty point for this row (using wall zBuffer? or just use a reference distance)
  int dirX = rayDirX; ... 
  // For floor casting we use the formula based on the row's distance.
  // The distance to the point on the floor at row y (with camera at height):
  p = y - H/2;
  // we use a fixed "distance" using a reference. Lodevint uses:
  // for each row, find a "distance" derived from the player's view.
```

Actually the standard floor casting finds, for each y, the distance to the wall column at that y (from zBuffer), then interpolates floor distances between current row and a row above (the wall's bottom). It's iterative. This is the efficient approach. Let me recall properly from Lodevint's "Floor casting" tutorial.

Lodevint floor casting:
```
// Get the distance to the first non-empty point in current column, i.e., the first point on the wall at this y.
// It stores distances in zBuffer.
p = y - h/2;  // p is the position of the current row on the view plane
// We store distWall = zBuffer[x] if we want, but the algorithm:
for (int y = h/2 + 1; y < h; y++)
{
    // ... compute floor step using dist to current row
}
```

Let me just recall the actual code from Lodevint (textured floor):

```
// FLOOR CASTING
for(int y = h/2 + 1; y < h; y++) {
    // Determine the left point and right point, and the distance of each
    // ...
    // The formula uses: row = 2*y - h; (since y from h/2)
    // We use distWall = zBuffer[x] (distance of the wall at this column) 
    ...
    int p = y - h/2; // p is the position on the view plane
    // ... floorDist interpolation
}
```

Actually, the precise Lodevint floor casting code:

```c
for (int y = h/2 + 1; y < h; y++) {
  // Trace ray in direction (dirX, dirY) with a slope based on y...
  // Left point:
  // ...
}
```

The actual Lodevint code:
```c
// FLOOR CASTING
for (int y = h/2 + 1; y < h; y++) {
  // determine left and right point of the floor line at this y
  int p = y - h/2; // p is the position on the view plane
  // find distance to the first non-empty point in current column
  float distWall = zBuffer[x]; // (not x-loop)

  ...
}
```

Hmm, let me recall more concretely. The floor casting in Lodevint (the textured version) is:

```c
  // FLOOR CASTING
  for (int y = h / 2 + 1; y < h; y++) {
    // Determine the left and right end points of the floor line
    // with vanishing point in the center.
    int p = y - h / 2; // p is the position on the view plane

    // ...
  }
```

Actually, let me just use a simpler floor casting: for each row y from floorStart to H-1, compute the floor distance directly and use a ray from player along forward direction with the row's slope, then walk and sample. But per-column iteration of floor pixels with a single ray is the simplest conceptually:

For each column x (0..W):
  cameraX = 2*x/W - 1
  rayDirX = dirX + planeX*cameraX
  rayDirY = dirY + planeY*cameraX
  // floor casting for this column:
  // the wall's perp distance at this column:
  distWall = zBuffer[x]
  // row of the wall bottom:
  // floor starts at wallBottom[x]. We cast floor from row wallBottom[x]+1 down, 
  // using interpolation between the wall distance (at wallBottom row) and a far distance.

This is getting complicated per-column. The classic per-row method is more efficient. Let me implement the per-row method properly. Let me recall the canonical code (I've seen it):

```
for (y = h/2 + 1 to h-1):
    // The distance to the first non-empty point on this row is needed.
    // We use a "row" distance computation:
    rowDistance = (playerHeight) * (W_H)  ...
```

Let me look at the actual algorithm from memory more carefully:

The standard Lodevint floor casting (vertical floor, single point light per row):

```c
for (int y = h / 2 + 1; y < h; y++) {
  // Set left and right point, and distance, using the player's direction
  // and the current row.
  // p is how far above the center this row is
  // ...
}
```

OK instead of recalling imperfectly, let me derive a correct floor casting myself:

For a point on the floor, given screen row y (from center horizon), the ray from player camera (at height 0 for floor, but we are on the floor plane) through screen point (x, y) hits the floor at some distance. Using the camera plane: a point (x,y) on screen corresponds to a ray direction `dir + plane * (2x/W-1)` with a vertical slope. The vertical direction is encoded by... hmm, the 2D raycaster uses only horizontal FOV (the plane). There's no vertical direction vector because it's a 2D map; vertical is handled by choosing wall heights. For floor casting we need the vertical component.

Lodevint handles this by: the distance to a floor point at row y is `playerDist = (playerHeight) / (y - h/2)`... wait.

The relationship: a floor point at distance D perpendicular to the view direction appears at screen row `y = h/2 + (playerHeight/D) * (h/2)` (with player at height `playerHeight` above the floor). So `D = playerHeight * (h/2) / (y - h/2)`. Then the floor point in world = playerPos + D * rayDir (horizontal). So for each row y and column x, the floor point distance D = playerHeight * h/2 / (y - h/2). Note it's the same for all x only if we ignore the horizontal component; but horizontal is per x via rayDir. Actually the perpendicular distance to the floor point is the same for all columns at a given y only if the floor point lies along the center ray? No.

Let me be careful. The floor is a plane at height = playerY (we stand on it, height ~0, but to avoid looking exactly from the floor, player eye height is like 0.5 but let's say the floor plane is at height 0 and player eye at height playerHeight). A point (xScreen, yScreen) maps to a world floor point. The standard trick (Lodevint) computes for each row a single "row distance" using the wall distance at the center column? No.

Let me recall the actual Lodevint "floor casting" section precisely. The code:

```c
// FLOOR CASTING
for (int y = h / 2 + 1; y < h; y++) {
  // determine left and right point of the floor line at this y
  // with vanishing point in the center
  int p = y - h / 2; // p is the position on the view plane

  // The floor line spans the whole width; for each column we need the
  // distance to the wall at this row to bound it. We use zBuffer to get
  // the distance of the wall at this column, then interpolate the floor
  // distance between the wall's bottom (closer, = wall dist) and a far
  // point (the floor at the horizon = infinity, approximated by a far distance).
  // Actually the per-column distance is obtained from interpolating.

  // ...
}
```

Honestly, let me just implement a correct, slightly less optimized floor casting that I'm confident about:

For each column x in 0..W-1:
  - Compute rayDir for this column: (dx, dy) normalized? Use dirX+planeX*cameraX etc., not necessarily normalized.
  - For the floor, we want, for each screen row y below the wall bottom for this column, the world floor point and its distance.
  - The horizon (center) is at y = H/2. For a given y (y>H/2), the distance to the floor point along the ray's horizontal direction is:
    D = playerHeight * (H/2) / (y - H/2)  ... but this uses playerHeight. 
  Actually the geometry: camera plane is at y_screen, and vertical maps via similar triangles. The distance from camera to the floor point on the center ray: floorDist = playerHeight / tan(vertAngle). And vertAngle for a row y is such that (y - H/2) corresponds to. If we assume the vertical FOV equals horizontal FOV (i.e., plane length matches), then the vertical "plane" half-length = playerHeight... hmm.

Let me set it concretely: Lodevint sets playerHeight = 0? No, Lodevint's floor casting uses the ray distance directly. Let me recall the Lodevint code one more time, I'm fairly sure it's:

```c
  // FLOOR CASTING
  for (int y = h / 2 + 1; y < h; y++) {
    // left and right point of the floor line at y
    // distance to the first non-empty point (wall) at column x is zBuffer[x]
    // ...
  }
```

You know, let me just reference the known Lodevint textured floor casting code that I remember reasonably:

```c
for (int y = h / 2 + 1; y < h; y++) {
    // Find the distance to the wall at this y for the left and right
    // This uses: for each y, the perpendicular distance to a point on the floor.
    // p = y - h/2
    // ...

    // Lodevint computes:
    // int p = y - h / 2;
    // int dist = ...;
}
```

I'll go with the derived correct formula, confident it's right:

The camera looks along dir. The view plane has horizontal half-extent given by `plane` vector (planeX). Vertical FOV: in a pure 2D raycaster there's no vertical plane vector; vertical is simulated. For floor casting, assume the vertical FOV such that the screen center row corresponds to looking horizontally (toward horizon at eye height, but since we're on the floor plane and eye height >0, the horizon is at center). A floor point at perpendicular distance `dist` along the horizontal ray appears at row:
`y = H/2 + (playerHeight / dist) * (H/2)`  [if vert FOV matches horiz FOV and eye height = playerHeight, with the plane extending H/2]. Wait, this means a point at distance `dist = playerHeight` is at row H/2 + H/2 = H (bottom), and at infinity at row H/2 (center). For y between H/2 and H, dist between infinity and playerHeight.

So `dist = playerHeight * (H/2) / (y - H/2)`. Let me define `playerHeight` as a value such that dist at bottom row = playerHeight*... at y=H: dist = playerHeight*(H/2)/(H/2)=playerHeight. So a floor point at perpendicular distance = playerHeight appears at the very bottom row. Hmm that means playerHeight should be small (~0.5) so the floor right in front is visible at bottom. OK.

So set playerHeight = 0.5. Then for row y>H/2: dist = 0.5*(H/2)/(y-H/2).

Then the world floor point along the center ray at that dist: floorX = player.x + dist*dirX, floorY = player.y + dist*dirY. For column x, we use the ray direction for that column: rayDir = dir + plane*cameraX, normalized-ish. Actually the perpendicular distance used above is along the center ray (cameraX=0). For off-center columns, the floor point is along that column's ray direction, and the perpendicular distance (distance to the plane perpendicular to forward) differs. The simple Lodevint method handles this by: compute the distance at the left and right edges of the floor line, then interpolate per pixel. 

For simplicity, let me compute per-column floor casting using this method:

For column x:
  cameraX = 2x/W - 1
  rayDirX = dirX + planeX*cameraX
  rayDirY = dirY + planeY*cameraX
  // normalize rayDir for the column so dist is perpendicular? In Lodevint, deltaDist and perpDist are perpendicular (accounted by plane scaling). For floor, I want the perpendicular distance = dist such that the point is at (player + dist * rayDirNormalized). The row formula uses perpendicular distance (distance in the forward direction). Hmm.

Actually, the row formula `dist = playerHeight*(H/2)/(y-H/2)` gives the perpendicular distance (distance along forward direction to the floor point that projects to row y) — this is per row, same for all columns IF the floor point is the projection along the forward direction. But each column's ray hits a different floor point at a different perpendicular distance? No—the perpendicular distance is measured along the forward (view) direction; a given screen row corresponds to a specific perpendicular distance only along the center. For other columns, the same row corresponds to points at the same perpendicular distance (since perpendicular distance = distance measured along forward axis; the row y maps to the plane perpendicular to view at that forward distance). Yes! The floor plane is sampled at a constant perpendicular distance for a given row, and then along the row, x selects the horizontal position via the rayDir. 

So: For row y (below center), perpDist = playerHeight*(H/2)/(y-H/2). The floor point at column x is: 
  floorX = player.x + perpDist * rayDirX (using the column's rayDir, but rayDir's forward component varies). Hmm, to be consistent, the horizontal position along the floor at perpendicular distance perpDist, for column x with angle, the world position = player + perpDist * forwardDir + offset. 

This is where Lodevint does the per-column interpolation using wall distance. Let me just do the straightforward (if slightly slower) per-pixel approach:

For column x:
  compute rayDirX, rayDirY (the unnormalized direction for column x).
  // The perpendicular distance to a floor point that projects to row y:
  // Since rayDir for column x has length > 1 (due to plane), the actual forward/perpendicular distance is (y formula) but the position along rayDir to reach perpendicular dist `d` is: the perpendicular distance = d corresponds to a position at distance along the ray = d / cos(angle) where angle is column's deviation. Equivalently worldPos = player + d * forwardUnit + d * (columnOffset)... 

Ugh. Let me simplify with the well-known clean method:

For column x and row y (y>H/2):
  cameraX = 2x/W -1
  rayDirX = dirX + planeX*cameraX
  rayDirY = dirY + planeY*cameraX
  // forward direction is (dirX, dirY) normalized (it is unit since we keep it unit)
  // The row y corresponds to a "wall distance" d = zBuffer[x] for that column (perpendicular distance to the wall along this column's ray). But for the floor, we need the perpendicular distance to the floor point at row y.
  
  // Relationship (assuming vertical FOV = horizontal FOV, i.e., playerHeight set so bottom row = some close distance):
  // perpDistFloor = playerHeight * (H/2) / (y - H/2)  (this is perpendicular distance along forward)
  // But for column x, the floor point is offset horizontally. The horizontal offset at perpendicular distance `d` for column x is d * (rayDirComponent perpendicular to forward). 

This is exactly what Lodevint solves with two endpoints:
- Left endpoint of the floor line (at row y, column x): but the floor line at row y spans the whole width; each column x maps to a point at perpendicular distance `d_y` (same d_y for the row) but different world X offset. Wait is d_y the same for all columns at row y? 

Yes, I believe perpendicular distance (forward distance) is constant per row. Let me verify: The screen row y corresponds to a specific vertical angle. Points on the floor at that vertical angle but different horizontal angles (columns) are at different distances. BUT perpendicular distance (forward-axis distance) of a floor point at vertical angle θ and horizontal angle φ is: the point is at forward distance = height / tan(θ). This is independent of φ! So yes, perpendicular (forward) distance is constant per row, = playerHeight/tan(θ). And the horizontal angle φ determines x-offset: worldPos = player + forwardDist*forwardUnit + forwardDist*tan(φ)*rightUnit, i.e., worldPos = player + forwardDist * (forwardUnit + tan(φ)*rightUnit) = player + forwardDist * rayDirNormalized-ish.

So for row y (hence forwardDist d), column x with rayDir (which encodes φ), the world floor point = player + d * normalized(rayDir)? Let's check: rayDir = forward + (cameraX)*plane. The direction with horizontal angle φ has, normalized, a forward component cos(φ) and horizontal component sin(φ). forwardDist*d gives forward component d. To get the actual position we need d/ cos(φ) along the normalized rayDir, equivalently position = player + d*(forwardUnit + tan(φ)*rightUnit). And rayDir normalized = (forwardUnit + tan(φ)*rightUnit)/sqrt(1+tan²φ)? No. Let me define rightUnit = perpendicular to forward. rayDir = forwardUnit * 1 + rightUnit * tan(φ)? Actually standard: rayDir = dir + plane*cameraX, with |dir|=1, plane perpendicular, |plane| = tan(FOV/2). cameraX in [-1,1]. So rayDir direction horizontal angle φ has tan(φ) = plane*cameraX / dir = (tan(FOV/2)*cameraX)/1. So tan(φ)=tan(FOV/2)*cameraX. The unit direction = (forwardUnit + rightUnit*tan(φ))/sec(φ) where sec(φ)=sqrt(1+tan²φ). Position at forward distance d (forward component = d): worldPos = player + d*forwardUnit + d*tan(φ)*rightUnit = player + d*(forwardUnit + tan(φ)*rightUnit) = player + d*sec(φ)*unitRayDir. So position = player + (d*sec(φ)) * unitRay, i.e., along rayDir (un-normalized) the scalar is d*sec(φ) but we can compute position as player + d*forwardUnit + (d*tan(φ))*rightUnit. 

Simplest: compute forwardUnit=(dirX,dirY), rightUnit = perpendicular. For column x, tanPhi = cameraX*tanH (tanH = |plane| = tan(FOV/2)). Then worldPos = player + d*forwardUnit + (d*tanPhi)*rightUnit. Where d = playerHeight*(H/2)/(y-H/2).

Then sample floor texture at (worldPos.x, worldPos.y) mod texSize. And apply distance-based darkening (light). Also we can use the wall's distance to cap the floor (stop at wall bottom per column). 

Hmm, but if a wall is close, the floor should start below the wall's bottom. Using per-column wallBottom: for column x, cast floor rows only from y = wallBottom[x]+1 to H-1... wait wallBottom is drawEnd which is the bottom of the wall slice (usually reaches near bottom for close walls). If wall is close, drawEnd ≈ H-1 (wall fills to bottom), so no floor visible (correct—wall right in front). For far walls, drawEnd < H-1, floor visible from drawEnd+1 to H-1. So per column, floor casting should start at wallBottom[x]+1.

But my d_y formula assumes the floor extends from center; for rows above wallBottom but below H/2, there's ceiling. Walls occupy some rows. For floor, only cast where below wall and below center. Since floor rows are y>H/2, and wallBottom[x] is typically ≥ H/2 (the wall bottom is below center), casting from wallBottom[x]+1 to H-1 is correct.

But the d_y formula gives d = playerHeight*(H/2)/(y-H/2). At y = H/2+1 (just below center/horizon), d huge (far). At y=H-1 (bottom), d small (near). That matches: near floor at bottom row, far at horizon. Good. And the wall's bottom row for a given column corresponds to wall distance; the floor at that row should start at that wall distance too. There might be a discontinuity but it's fine visually (Lodevint also has the wall as a hard bottom for floor).

Actually in Lodevint, the floor is cast only down to the wall bottoms by using the wall distance (zBuffer) as an upper bound and interpolating. My per-column approach with d_y is actually consistent: at y=wallBottom[x], the floor distance d_y equals the wall's perpendicular distance (since wall bottom row is determined by wall distance). Let me verify: wall bottom drawEnd = H/2 + lineHeight/2 where lineHeight = H/distWall (perpWallDist). So drawEnd ≈ H/2 + (H/(2*distWall)) => y - H/2 = H/(2*distWall) => distWall = H/(2*(y-H/2)) = (H/2)/(y-H/2). And floor d at that y = playerHeight*(H/2)/(y-H/2). These match (d = playerHeight*distWall). So at the wall bottom row, the floor point distance = playerHeight * wall distance. For this to align (floor starts right below wall), we want floor's d at wallBottom row to equal... actually the floor point at the wall's bottom row is at distance playerHeight*distWall, which is beyond the wall (wall is closer). The floor behind the wall shouldn't be drawn up to the wall (it's hidden). By starting floor casting at wallBottom[x]+1, we naturally hide floor behind wall. And the floor at row wallBottom+1 has d slightly > playerHeight*distWall, consistent. Good, the alignment works if playerHeight chosen as the eye height; Lodevint uses playerHeight to define the vertical FOV. Let me set playerHeight = 0.6 or so. Actually the relationship between playerHeight and vertical FOV: at row H-1 (bottom), d = playerHeight*(H/2)/(H-1-H/2) = playerHeight*(H/2)/(H/2 -1) ≈ playerHeight. So bottom row floor point is at distance ≈ playerHeight in front. If playerHeight=0.5, the floor point right in front (0.5 away) is at the bottom row. That seems too close (we'd see floor tile 0.5 away at bottom, reasonable). Let me use playerHeight ~ 0.5. Actually the eye height doesn't affect FOV; FOV is governed by plane. The vertical FOV matches horizontal FOV when the vertical plane half-size = eyeHeight? The relation: at the bottom row, the ray points downward at angle = verticalFOV/2. The floor point at the bottom row at distance d: eyeHeight/d = tan(verticalFOV/2)... and the row mapping y-H/2 relates. Standard: row y from center, with plane height H/2, the vertical tan = eyeHeight / d and also (y - H/2) = (H/2) * (eyeHeight/d) / tan?? I'm conflating.

I'll trust the formula `d = eyeHeight * (H/2) / (y-H/2)` is what Lodevint uses (with eyeHeight as a parameter, and it sets eyeHeight such that it equals the distance behavior). Actually Lodevint's floor casting code:

```c
// FLOOR CASTING
for (int y = h / 2 + 1; y < h; y++) {
    // Determine the left and right point of the floor line
    // with vanishing point at the center
    // ...
    // p = y - h/2
    // ...
    // The formula used: 
    //   rowDistance = (double)(playerHeight) * (h / 2.0) / (y - h / 2);
    // Wait that's not a per row? It is per y.
}
```

Hmm, I recall the formula `rowDistance = (playerHeight * h/2) / (y - h/2)` exactly. And Lodevint sets a constant `playerHeight`? Let me recall: in Lodevint floor casting, there's no playerHeight variable; instead the floor casting uses `rowDistance = (distWall)` interpolated. Argh.

OK let me just implement the per-column per-row method using my derived `d = eyeHeight * (H/2)/(y-H/2)` with eyeHeight chosen so the floor looks right, and per-column world offset. Let me define `EYE_HEIGHT = 0.5`. Then for column x, the ray direction determines the world position at perpendicular distance d. I'll compute:

```
const leftDir = normalize(dir+plane*(-1))  // cameraX=-1
const rightDir = normalize(dir+plane*(1))
```
Actually for per-column world position, use the column's rayDir direction but scaled to forward distance d. Let me use the approach: worldPos = player + d * dir + d * cameraX * planeUnit... let me derive in terms of dir and plane (plane is a vector perpendicular to dir with length = tan(FOV/2) * |dir|). Since |dir|=1, |plane| = tan(FOV/2). The rayDir = dir + cameraX*plane. The forward component (along dir) of rayDir is dir·rayDir/|dir| = 1 (since dir unit, rayDir·dir = 1 + cameraX*plane·dir =1 because plane·dir=0). So rayDir always has forward component 1. Its length = sqrt(1 + (cameraX|plane|)²). The position at perpendicular distance d (forward component = d) is: player + d*dir + d*cameraX*plane? Let me check: player + d*dir + d*cameraX*plane = player + d*(dir + cameraX*plane) = player + d*rayDir. Yes! Because rayDir = dir + cameraX*plane. So worldPos = player + d * rayDir. Beautiful. So I just use d (perpendicular/forward distance) times the column rayDir (as used for walls). And d = eyeHeight * (H/2) / (y-H/2).

Wait, but rayDir for walls used perpWallDist = (mapX - posX + (1-stepX)/2)/rayDirX. The perpWallDist is the perpendicular (forward-axis) distance. And the wall's world position uses perpWallDist*rayDir. Consistent! Great, so floor formula with d = eyeHeight*(H/2)/(y-H/2) is consistent, and to align floor bottom with wall bottom (so no gap), eyeHeight should be the player's eye height above the floor. Since walls are drawn from the floor up by lineHeight = H/perpWallDist using full height (the wall spans H/perpWallDist pixels, centered at H/2, so wall top and bottom correspond to the floor line). The wall bottom row = H/2 + lineHeight/2 = H/2 + H/(2*perpWallDist). Floor at row y has d = eyeHeight*(H/2)/(y-H/2); set d = perpWallDist => (y-H/2) = eyeHeight*(H/2)/perpWallDist => y = H/2 + eyeHeight*H/(2*perpWallDist). For this to equal wall bottom H/2 + H/(2*perpWallDist), we need eyeHeight = 1.0. So eyeHeight should be 1.0 (i.e., the player eye is 1.0 above the floor, and the "player height" parameter for floor casting = 1.0). That makes the floor bottom align with the wall bottom (wall base exactly on floor). 

So set EYE_HEIGHT = 1.0. But then the bottom row (y=H-1) floor point distance d = 1.0*(H/2)/(H/2-1) ≈ 1.0, i.e., floor point 1.0 cell in front is at the bottom row. That means we look down at our feet a bit (vertical FOV ~ 90° if H/2... let's check vertical FOV: bottom row at distance 1.0 => the downward angle to bottom row: tan(downAngle) = eyeHeight/d = 1/1 = 1 => downAngle=45°. So vertical FOV = 90° (45 up, 45 down)? But walls are centered at horizon (45° up would put ceiling). Hmm, with eyeHeight=1.0 and the horizon at center, looking horizontally at the center. The floor plane: downward angle to bottom row = 45°. Upward angle to top row (ceiling) = 45°? For ceiling we'd need a ceiling floor casting. I'll do ceiling too. Vertical FOV 90°. Horizontal FOV: plane length = tan(FOV/2). If I set FOV 60° (tan30=0.577), then vertical FOV 90° ≠ horizontal, causing aspect stretch. To make vertical FOV = horizontal FOV, plane length should equal eyeHeight? Since vertical half-extent = eyeHeight (1.0) and the formula, horizontal half-extent = plane length. For vertical FOV = horizontal FOV, plane length = eyeHeight = 1.0 => horizontal FOV = 2*atan(1.0)=90°. So both 90°. That's a wide FOV. Wolf3D uses ~90°? Actually it's more like... fine, 90° FOV is okay-ish (wide). Or I can pick a narrower FOV. Let me pick horizontal FOV = 60°, plane = tan(30)=0.5773. Then vertical FOV determined by eyeHeight: vertical half-angle = atan(eyeHeight / (H/2 in "world units of plane")). Hmm the vertical FOV in this setup: the top of screen corresponds to... the row y=0 maps to downward? Let me not worry; with eyeHeight=1.0 and H/2 as the half-height, the vertical half-angle = atan(eyeHeight / 1.0)? where "1.0" is the screen half-extent in normalized plane units. The horizontal half-angle = atan(plane/1.0)=atan(plane). For vertical FOV to match, eyeHeight should equal plane. So set eyeHeight = plane length. If plane=0.577 (FOV 60°), set eyeHeight=0.577. Then bottom row distance d=0.577 → floor point at 0.577 in front at bottom. Slightly close but okay. FOV 60° is more natural (less distortion). Let me use FOV 60° (plane = tan(30°) ≈ 0.57735) and EYE_HEIGHT = plane (so vertical=horizontal FOV). 

Hold on, but I want the alignment between floor and wall: with eyeHeight = plane, the wall bottom aligns with floor at d=perpWallDist? Using eyeHeight in floor formula: at wall bottom row y=H/2 + H/(2*perpWallDist), the floor d = eyeHeight*(H/2)/(y-H/2) = eyeHeight*(H/2) / (H/(2*perpWallDist)) = eyeHeight*perpWallDist. For alignment, we need d = perpWallDist (floor point at the wall's perpendicular distance right at wall bottom). So eyeHeight must = 1.0, NOT plane. Conflict!

Let me re-examine. The wall bottom row formula: drawEnd = H/2 + lineHeight/2, where lineHeight = H / perpWallDist. But wait, lineHeight uses perpWallDist and H; but the wall is the full height of an infinitely tall wall at distance perpWallDist. The wall's bottom on screen corresponds to the base of the wall, which is at the floor plane y=0 (the wall base). The wall base at distance perpWallDist projects to row H/2 + (H/2)*(eyeHeight/(...))? Hmm the wall base row = H/2 + (H/(2)) * (1/perpWallDist) ONLY if the vertical scale is set so that the top of screen is +90° and we use eyeHeight=?? Let me redo the wall projection.

Wall height on screen: lineHeight = H * (wallHeightWorld / perpWallDist) where wallHeightWorld = 1.0 (cell size) plus eye height above floor. Actually the wall is 1.0 tall (from floor y=0 to ceiling y=1). The viewer eye is at height eyeHeight above floor. The wall base is at floor (0), ceiling at 1. The wall top (ceiling) is at distance (eyeHeight to ceiling = 1.0 - eyeHeight above viewer) and wall bottom (floor) at (eyeHeight below viewer). So they project at different rows:
  top row = H/2 - (H/2) * ((1.0 - eyeHeight)/perpWallDist) * (scale) 
  bottom row = H/2 + (H/2) * (eyeHeight/perpWallDist) * scale
where scale relates angular to screen. In Lodevint's simple version, they assume eyeHeight doesn't matter for walls (they draw the wall centered at H/2 with full lineHeight covering from floor to ceiling, implicitly eyeHeight such that top and bottom extend equally). Actually Lodevint draws walls centered at H/2 (drawStart = -lineHeight/2 + H/2, drawEnd = lineHeight/2 + H/2) where lineHeight=H/perpWallDist. This means the wall spans from H/2 - H/(2*perpWallDist) to H/2 + H/(2*perpWallDist), i.e., symmetric about center. That corresponds to eyeHeight = wallHeightWorld/2 = 0.5 (eye in the middle of the wall vertically). So Lodevint treats the wall as full height and eye at vertical center—no floor/ceiling distinction for walls; the wall texture spans full height and is centered. The floor then is drawn below the wall bottom row, and the floor casting formula must use eyeHeight = 0.5 to align with this wall.

So: wall bottom row = H/2 + H/(2*perpWallDist). Floor at that row should be at perpendicular distance = perpWallDist (the wall). Floor formula d = eyeHeight*(H/2)/(y-H/2). At y=wallBottom=H/2+H/(2*perpWallDist): y-H/2 = H/(2*perpWallDist); d = eyeHeight*(H/2)/(H/(2*perpWallDist)) = eyeHeight*perpWallDist. To align d=perpWallDist, need eyeHeight=1.0. But the wall is centered assuming eyeHeight=0.5... 

The discrepancy: with eyeHeight=0.5 (Lodevint wall centering), the floor base plane is at the center, not at the viewer's feet. Actually the issue is Lodevint's wall rendering treats the floor as being at the viewer's vertical center (eyeHeight=0 effectively, floor at center row = 0? no). Let me reconsider: if eyeHeight=0 (viewer on the floor, looking horizontally at the horizon which is at center), then wall bottom row = H/2 + H/(2*perpWallDist) corresponds to distance d where floor formula d = 0*(...) = 0... no.

Hmm, I think the cleanest is the standard Lodevint floor casting where the floor and ceiling are both cast and the wall is drawn between them, with the viewer's eye at the wall's vertical center (so floor starts right at H/2? no).

Let me just recall Lodevint's exact floor casting code, which I'm now fairly confident about:

```c
// FLOOR CASTING
for (int y = h / 2 + 1; y < h; y++) {
    // Determine the left and right point of the floor line
    // using the current y and the wall distance zBuffer
    int p = y - h / 2; // p is the position of the row we're on

    // ...
    // The formula for row distance:
    // Lodevint uses: 
    //   double floorZ = 0.5 * h / (y - h/2);  // hmm not sure
}
```

Honestly, let me sidestep this complexity. I'll do a **simple floor**: fill the bottom half (y from H/2 to H) with a solid color that has a vertical gradient, OR a textured floor using a cheap per-column vertical stretch. Actually, the cleanest textured floor without complex geometry: do a textured floor by computing, for each column, the floor distance per row using the formula and sample the texture, but accept the "eyeHeight" choice to just look reasonable (slight mismatch at wall-floor edge is hard to notice if walls are textured and the floor is dark).

Alternatively, do floor casting with the formula `d = eyeHeight * (H/2) / (y - H/2)` where eyeHeight = 0.5*... let me just pick eyeHeight = 0.8 and accept minor seam. The seam (wall bottom vs floor) is usually not noticeable because the wall texture bottom often has mortar/dark color.

Actually, let me do the Lodevint approach correctly using zBuffer-based floor interpolation, which I'm now recalling better:

The real Lodevint floor casting code (texturedFloor):
```c
  // FLOOR CASTING
  for (int y = h / 2 + 1; y < h; y++) {
    // Determine the left and right end point of the floor line
    // with vanishing point in the center.
    // For each y, we find the distance to the first wall (zBuffer) 
    // but actually the code is:
    int p = y - h / 2; // ... 

    // The left and right floor point distance is determined by 
    // interpolating between the distance of the wall at this row 
    // and a far distance. But the canonical code:
    
    // leftX = ...;  // not
  }
```

OK I clearly don't remember it exactly. Let me just implement the direct per-pixel floor casting with my formula and pick eyeHeight to minimize seam, and only cast floor below walls. Let me set eyeHeight = 0.5 to match the wall centering (wall spans full height symmetrically about center). With eyeHeight=0.5, floor at row y>H/2: d = 0.5*(H/2)/(y-H/2). At wall bottom row y=H/2+H/(2*perpWallDist): y-H/2=H/(2*perpWallDist), d=0.5*(H/2)/(H/(2*perpWallDist))=0.5*perpWallDist. So floor starts at distance 0.5*perpWallDist, half the wall distance—not aligned with wall bottom. That means floor is drawn starting below wall bottom, but a small gap: at row wallBottom+1, the floor is slightly farther than the wall. The wall bottom is at the wall's base; floor just below should be at the wall's distance. With d=0.5*wallDist, the floor at wallBottom+1 is at distance 0.5*wallDist which is closer than the wall?? That's wrong (floor closer than wall behind it, should be at wall distance). 

This is getting too deep. Let me use the zBuffer-based floor casting which is robust and aligns exactly. Here's the correct Lodevint floor casting algorithm that I'm confident about now:

For each y in [H/2+1, H-1]:
  p = y - H/2
  // We need the left and right endpoint distances. Lodevint computes:
  // leftDist and rightDist = the perpendicular distances to the points 
  // where the row intersects the left/right view plane edges... 
Actually the standard Lodevint floor casting code (I'm now recalling the actual published code):

```c
  // FLOOR CASTING
  for (int y = h / 2 + 1; y < h; y++) {
    // left and right point, and distance
    // Determine the left and right end point of the floor line
    // ...
    // We use the wall distance zBuffer[x] to cap each column.
    // The distance is interpolated: from the wall distance at the bottom 
    // of a column to the far horizon distance.
  }
```

Argh. Let me just go with a pragmatic textured floor: per column, for each row below the wall's bottom and below center, compute d via `d = wallDistAtColumn * (y - wallBottomRow) / (H - wallBottomRow - 1) * something`... 

Actually, the simplest robust method that aligns: For column x, we know the wall's perpendicular distance dW = zBuffer[x] and the wall bottom row yW = drawEnd[x] (the row where wall ends, below which floor shows). For rows y in [max(yW, H/2)+1, H-1], interpolate the floor distance linearly from dW at row yW to a far distance (∞ or some farDist) at row H-1:
  d = dW * (H - 1 - yW) / (y - yW)  ... linear in 1/d? 

The correct interpolation is in 1/d (since distance varies as 1/(y-H/2)). But approximating linearly in d between dW and farDist gives a reasonable floor that aligns at the wall bottom. Since at row yW, d=dW (wall distance) — aligned with wall bottom! At bottom row H-1, d=farDist (small, e.g., close floor). Hmm wait bottom row should be nearest (small d). At yW (wall bottom), d=dW (the wall is at dW). Below that, floor is closer to camera (rows further down = nearer). So d decreases from dW at yW to a small value at H-1. So interpolate d from dW (at yW) down to dNear (at H-1). Linearly in d is a rough approximation but looks okay-ish for floor tiles? Actually floor tiles should get larger faster near the bottom (perspective), so linear in d is not physically correct, but for a quick version it's acceptable. Better: interpolate 1/d linearly, which is the correct perspective behavior.

Let me do the correct one: 
  at row yW: distance dW; at row H-1: distance dNear. We want, per row y, the distance d such that 1/d interpolates linearly between 1/dW and 1/dNear.
  rowFrac = (y - yW) / (H - 1 - yW)
  invD = (1/dW)*(1-rowFrac) + (1/dNear)*rowFrac
  d = 1/invD
This is correct perspective and aligns at yW (d=dW). Good. dNear = small distance like dW? Actually the bottom row should be close (dNear ~ a little less than dW, since it's just below the wall). Hmm if the wall is far, dW is large, dNear slightly smaller—floor barely visible below far wall. If wall is close (dW small, e.g., 1.0), bottom row dNear even smaller. The floor tile at the very bottom row would be at dNear. Let me set dNear = dW * 0.7 or so, or a fixed small minimum like the distance to the row. Actually simplest: dNear = (H-1-yW) related... 

Hmm, I realize for the standard approach, the bottom row corresponds to a floor distance that's consistent with the FOV. Let me set dNear based on FOV: at the bottom row (y=H-1), the perpendicular distance = eyeHeight / tan(bottomAngle). With eyeHeight=0.5 and bottomAngle=45°, dNear=0.5. With a 60° FOV the bottom angle is 30°, dNear = 0.5/tan(30)=0.5/0.577=0.866. Eh.

This is over-engineering. Let me just use the simple per-column formula d = eyeHeight*(H/2)/(y-H/2) with eyeHeight chosen = 0.5*... and ALSO cap floor rendering per column below wallBottom. The seam alignment: I'll accept a tiny seam or ensure eyeHeight=1.0 so wall bottom aligns (even if wall is "centered" assuming eyeHeight=0.5, actually the wall centering in Lodevint does NOT depend on eyeHeight—it just draws wall centered; the floor formula with eyeHeight=1.0 gives bottom-row distance = 1.0 which with plane=0.577... no). 

You know what, let me just go with the per-column d = eyeHeight*(H/2)/(y-H/2) formula, eyeHeight = 0.6, and NOT worry about perfect wall alignment—draw floor below ceiling. I'll cast ceiling on top half and floor on bottom half with this formula. The seam might be slightly off but with textured walls and the floor being dark, it won't be glaring. Let me try and visually check; if seam is bad, adjust.

Actually, simpler and guaranteed consistent: Let me NOT cast a textured floor. Let me do a **solid floor with vertical gradient** + maybe a simple repeating pattern applied via a different method. Wait, that fails "Wolfenstein style" but the requirement is walls textured + enemies + procedural textures; floor texture isn't mandated. However a solid color floor looks cheap. 

Compromise: do the per-column textured floor with the simple formula. Let me just implement it and check visually. Time to code.

Let me set parameters:
- canvas 800x600, render 400x300.
- FOV: I'll use plane length = 0.60 (≈ FOV 58°). Actually for the floor formula, vertical FOV = horizontal FOV requires eyeHeight=plane length? No—earlier I derived eyeHeight (in floor formula) should be the actual viewer height. The relationship between the floor formula's eyeHeight and the wall centering: The wall draws full-height (from floor to ceiling) centered at H/2, which implies the viewer's eye is at the wall's vertical midpoint, i.e., the floor-to-ceiling is symmetric → floor is at H/2 - (wallHeight/2)*... 

Hmm, the wall centered at H/2 means: the floor (bottom of wall) is at row H/2 + H/(2*perpWallDist) and ceiling at H/2 - H/(2*perpWallDist). This is symmetric around H/2, meaning the viewer is at vertical center (looking straight at the middle of the wall, eye in the middle of the wall height). That's the Lodevint convention: eye at 0.5 (middle of a 1.0-tall wall) but rendered with walls centered. Effectively the "floor" is at the viewer's eye level horizontally? No.

Let me reconcile by choosing the floor formula to match: At the wall bottom row yW = H/2 + H/(2*dW) (dW=perpWallDist), the floor distance should be dW (so floor point at the wall base distance). Floor formula: d = eyeHeight*(H/2)/(y-H/2). At y=yW: dW = eyeHeight*(H/2)/(H/(2*dW)) = eyeHeight * dW. So eyeHeight must = 1.0. Therefore, to align floor with wall bottoms exactly, set eyeHeight=1.0. This means the viewer's eye height = 1.0 (above floor) and the wall is drawn centered (symmetric) which would be inconsistent (wall should be from 0 to 1, viewer at 1.0 → wall top at viewer's feet??). 

I give up reconciling perfectly. I'll use eyeHeight=1.0 so the floor aligns with wall bottoms (no seam between wall base and floor), and the ceiling I'll align with wall top using a similar formula or just a solid gradient ceiling. The slight vertical FOV mismatch is acceptable. Let me set:
- plane length (horizontal) = 0.65 (~FOV 57°).
- For floor: d = 1.0 * (H/2) / (y - H/2). 
- For ceiling: d = 1.0 * (H/2) / (H/2 - y) for y < H/2 (symmetric).
- Wall bottom = H/2 + H/(2*dW) aligns with floor at y where d=dW → 1.0*(H/2)/(y-H/2)=dW → y-H/2 = (H/2)/dW → y=H/2+H/(2*dW) ✓ yes with eyeHeight=1.0 it aligns! 

So eyeHeight=1.0 aligns floor with wall base. And ceiling aligns with wall top (ceiling at y=H/2-H/(2*dW), floor formula inverted gives same). So walls are drawn as full-height from floor to ceiling, viewer eye at height 1.0, and floor/ceiling casting uses eyeHeight=1.0 → walls exactly span floor-to-ceiling with the floor starting at the wall base. This is internally consistent! The viewer eye at height 1.0 above floor, looking straight (horizon at H/2 = eye level). The vertical FOV: bottom row distance d=1.0*(H/2)/(H-1-H/2)=1.0*(H/2)/(H/2-1)≈1.0. The bottom row floor point at distance ~1.0 from player → at the bottom of screen, the floor 1 cell ahead. Vertical half-angle = atan(1.0/1.0)=45°. So vertical FOV=90°. Horizontal FOV with plane=0.65 = 2*atan(0.65)=~61°. So vertical (90°) > horizontal (61°) → vertical stretch, floor looks a bit tall. To match, set plane = 1.0 (FOV 90°). That's very wide/distorted but matches vertical. Or accept mismatch. 

For a balanced look, let me set the vertical FOV to match by making the floor formula consistent with a chosen FOV. Alternatively, render non-square: the render resolution is 400x300 (4:3). If I set FOV 60° both, vertical=60°, plane=tan30=0.577, and I want floor to align and bottom row at the right distance. With eyeHeight chosen so that wall (full height) spans floor to ceiling: that requires eyeHeight such that wall centered = floor to ceiling → eyeHeight = 0.5 (middle). But then floor align formula needs eyeHeight=1.0. Contradiction again means: if the wall is full-height (floor to ceiling) and viewer eye is in the middle (0.5), the wall does NOT span the viewer's vertical FOV symmetrically—there's more ceiling above (1-0.5=0.5 above eye) and floor below (0.5 below eye). Actually the wall top (ceiling) is 0.5 above eye, wall bottom (floor) 0.5 below eye → symmetric → centered on H/2. So centered! And the floor casting with eyeHeight=0.5: at wall bottom row (H/2+H/(2*dW)), floor formula d=0.5*(H/2)/(H/(2*dW))=0.5*dW. That's half the wall distance, seam mismatch. So to align, eyeHeight in floor formula must=1.0, but the wall spans floor(0) to ceiling(1) with eye at 0.5. The floor is at eyeHeight=0.5 *below* eye... 

The confusion is "eyeHeight" means different things. Let me define clearly:
- Viewer eye at world height h above floor (floor at y=0, ceiling y=1).
- Wall from y=0 to y=1.
- A wall of perpendicular distance dW: the bottom of the wall (y=0) projects to screen row yBot = H/2 + (H/2) * (h/dW) / tan? ... where the vertical scale: an object of vertical size s at distance dW subtends screen size H * (s/dW) * (FOV_factor). The standard Lodevint: lineHeight = H/dW for s=1 and it appears centered → that uses H = screen height and assumes s/dW maps with the plane such that FOV... Lodevint's formula lineHeight = H / perpWallDist comes from: the plane half-size is 1 (screen coords), and tan(FOV/2) = planeLength. An object of height 1 at distance dW subtends: 2 * atan(0.5/dW) ≈ 1/dW for small angles; screen rows = H * (1/dW) * (FOV/(2*tan(FOV/2)))? Lodevint absorbs the FOV into the plane length and uses lineHeight = H/dW / |cos|... no, Lodevint uses lineHeight = (H / perpWallDist) and the FOV is encoded in plane length (tan(FOV/2)). The relationship: the screen half-height in "world at distance 1" units = 1/tan(FOV/2)?? 

I'm overcomplicating massively. The Lodevint formula `lineHeight = H / perpWallDist` is valid when the plane length (tan(FOV/2)) = 1.0? No. Let me recall: Lodevint uses `lineHeight = (int)(h / perpWallDist)` and the FOV is set via `dir` and `plane`. The formula `lineHeight = h/perpWallDist` implies that at distance 1, the wall height (1 world unit) covers the full screen height h. That means the vertical FOV = 90° and the vertical plane half-size = 1.0 (i.e., at distance 1, an object of height 1 fills from -1 to +1 on the screen plane, half-size 1). And horizontal plane half-size = plane length = tan(horizFOV/2). If plane length != 1, then vertical FOV (90°) != horizontal FOV. Lodevint typically uses plane length = tan(FOV/2) with FOV 60° → plane=0.577. Then horizontal FOV=60°, vertical FOV=90° (because lineHeight=h/dW assumes half-height plane=1). So Lodevint actually has mismatched FOVs unless FOV=90° (plane=1)! 

Right, that's a known Lodevint quirk: the formula assumes vertical half-plane=1 (so vertical FOV 90°) and horizontal half-plane=plane length. So they're independent. To keep walls undistorted (square pixels), the render resolution aspect ratio and FOVs... it's fine; walls are vertical slices so they're not horizontally distorted by FOV; the aspect is handled by plane length affecting horizontal. Walls remain vertical (correct aspect) regardless of FOV. Only the horizontal spread changes. So vertical FOV 90° fixed (lineHeight formula), horizontal FOV = 2*atan(plane). For a 4:3 image with 90° vertical, horizontal = 90° too → plane = tan(45°)=1.0. So if I set plane=1.0, FOV=90° both, pixels square, no distortion, and floor formula aligns with eyeHeight=1.0 (matching the wall's assumption). 

So: set plane length = 1.0? That gives FOV 90°, quite wide (fisheye-ish at edges) but no distortion and aligns everything. Hmm 90° FOV in a raycaster is a bit much (Wolf3D ~ 90°? actually it's 90°? Wolfenstein 3D horizontal FOV is 90°? I think it's around 90° maybe less). Let me use FOV 90°... actually many sources say Wolf3D FOV is about 90°? No, I recall ~75°? Let me not worry; 90° is fine and simplifies. But 90° causes pincushion/barrel distortion at edges. Acceptable for this.

Wait, but if plane=1.0, the walls at screen edges: rayDirX = dirX + 1.0*cameraX; at edges cameraX=±1, so rayDir can be long, more distortion. Eh, fine.

Alternatively, accept the mismatch and use plane=0.6 (FOV 61°), with floor formula eyeHeight=1.0 (aligns with walls, since walls assume the 1.0 half-height → vertical FOV 90°, and floor formula with eyeHeight=1.0 aligns). The horizontal FOV=61°, vertical=90° → the floor will appear "tall" (vertical stretched) but walls are fine. On a 4:3 screen (400x300), vertical 90° and horizontal 61° means horizontal is narrower than the 4:3 would imply for 90°—so there'd be side pillars (black bars)? No—horizontal FOV just means less horizontal view; the screen is still fully used, just less wide field of view. That's fine, just a narrower horizontal view. The floor casting: the floor formula uses H/2 and eyeHeight=1.0, independent of horizontal. The floor appears with the vertical FOV 90° (tall). Combined with plane=0.6, the floor tiles' horizontal extent per row uses the column rayDir (which is correct for the narrower FOV). So floor looks consistent with the walls. I think it's fine. Let me just go with plane=0.6 and eyeHeight=1.0 for floor (aligns with walls). Let me verify alignment: wall bottom row = H/2 + H/(2*dW) (since lineHeight=H/dW, drawEnd=H/2+lineHeight/2=H/2+H/(2*dW)). Floor at row=that: d = eyeHeight*(H/2)/(row-H/2) = 1.0*(H/2)/(H/(2*dW)) = dW. Aligned! ✓. Great. So eyeHeight=1.0, plane=0.6 (FOV 61° horizontal, 90° vertical but floors consistent with walls). 

Wait, is the vertical FOV actually 90°? The wall formula lineHeight=H/dW means at dW=1, wall height = H (full screen). The wall is 1 world unit tall (floor to ceiling). At distance 1, a 1-unit object fills the screen height → vertical FOV 90°. And eyeHeight (viewer height above floor) is not in the wall formula (walls centered). For the floor to align, eyeHeight must equal... we found eyeHeight=1.0. But the viewer eye at height 1.0 with a wall of height 1 (floor=0, ceiling=1): the eye is at the ceiling level! That means we're looking at the ceiling top? That's wrong—viewer should be around 0.5 inside the wall (eye at 0.5, floor below, ceiling above). 

The misalignment indicates the wall formula `lineHeight=H/dW` centers the wall on H/2, which corresponds to the viewer's eye being at the wall's vertical center (0.5). But the floor formula with eyeHeight=1.0 corresponds to eye at 1.0 (ceiling). These can't both be right, hence my earlier contradiction. The floor formula `d = eyeHeight*(H/2)/(y-H/2)` and the wall formula `lineHeight=H/dW` are from different conventions (different tutorials) and don't align unless... 

Lodevint actually uses `lineHeight = h / perpWallDist` for walls AND floor casting with a consistent `rowDistance`. Let me finally recall Lodevint's floor casting rowDistance: I think it's `rowDistance = (double)(0.5 * h) / (y - h/2)` multiplied by... Actually I recall the floor casting uses:

```
for (int y = h/2 + 1; y < h; y++) {
    // ... 
    int p = y - h/2;
    // ... 
    // the distance used:
    //   rowDistance = (double)(playerHeight) / (...);
}
```

I don't precisely recall. Given time, let me make a pragmatic choice that I can verify visually: use eyeHeight for floor = 1.0, walls full-height centered. Even if the floor "starts" at the wall base geometrically it's at eyeHeight=1.0... the visual result: floor tiles extend from the wall bottoms downward; they'll look fine. The viewer being "at ceiling height" is a non-physical but the visuals are a textured floor receding to the horizon at center. Honestly for a raycaster, the floor vanishing at the horizon is the key visual; slight eye-height inconsistency is invisible. And walls centered. Let me just do it and check it looks okay. If the floor looks wrong (e.g., too much floor, or ceiling wrong), I'll adjust.

Actually, to avoid ceiling issues (I might skip ceiling or do a solid one), let me do: textured floor below center, solid ceiling color above (with maybe ceiling texture). I'll cast a ceiling texture above center using symmetry. Let me do both via the same formula mirrored, with eyeHeight=1.0, which aligns ceiling with wall tops (wall top row = H/2 - H/(2*dW); ceiling formula d=1.0*(H/2)/(H/2-y); at y=wallTop: d=1.0*(H/2)/(H/(2*dW))=dW ✓). So ceiling aligns with wall tops. 

So the world: viewer eye at height 1.0, but wall is 1.0 tall (0..1). The viewer eye at height 1.0 = exactly at the ceiling. Looking straight, the ceiling is at eye level... that would make the ceiling flat at center. But our floor is below center and ceiling above center with vanishing at center. If eye is at ceiling height (1.0), looking straight we'd see the ceiling as a flat plane at eye level extending back—i.e., the ceiling would be visible as a receding plane above center. And floor below. The wall goes from floor(0) to ceiling(1); eye at ceiling(1) means we're at the top of the wall. That's like standing with your eye at the ceiling—weird but the textures make it look like a normal floor+ceiling corridor because we just see floor below and ceiling above, both receding. The wall texture spans full height. It'll look fine; nobody will notice the eye-height inconsistency because floors and ceilings both recede to horizon. This is exactly how Lodevint looks (floor and ceiling both to horizon). Good, proceed.

Wait, but then the wall texture covers from floor to ceiling with the player "at ceiling height"—the lower half of the wall (below eye) is floor-above-us, upper half ceiling-above-us. In a corridor, the wall is between floor and ceiling, and we see the full wall texture from floor to ceiling with horizon at the middle of the wall texture (since eye at middle of wall). That IS the case if eye is at 0.5 (middle of wall 0..1), not 1.0. With eye at 1.0 (ceiling), the horizon would be at the top of the wall texture, meaning we'd see mostly the lower part of the wall and the ceiling near the top. Hmm.

I think the actual resolution: Lodevint's wall formula `lineHeight = H/perpWallDist` DOES put the horizon at the vertical center of the wall (H/2) because walls are centered at H/2. That means eye at wall's vertical middle = 0.5 (for a wall 0..1). So eye = 0.5. For the floor to align with the wall bottom (H/2+H/(2*dW)), the floor formula needs eyeHeight such that d_eye = eye = 0.5. Using d = EYE*(H/2)/(y-H/2), at the wall bottom row: d = EYE*(H/2)/(H/(2*dW)) = EYE*dW. For d=dW (align), EYE=1.0, not 0.5. So Lodevint's floor formula must use EYE=1.0 independent of the wall's eye-level convention, i.e., the floor formula in Lodevint uses the "distance to the floor plane" = dW and the relationship is geometric with eyeHeight... 

I'll stop. Let me just use Lodevint's actual floor casting code which I'll reconstruct as best I can and trust it aligns:

Lodevint textured floor casting (final remembered code):
```c
// FLOOR CASTING
for (int y = h / 2 + 1; y < h; y++) {
    // left and right point, and distance
    // Determine the left and right end point of the floor line
    // with vanishing point at (w/2, h/2). We use a single distance
    // computed per row:
    int p = y - h / 2; // ...

    // The left and right endpoints' distances equal the distance of 
    // the point where the ray at the left/right edge hits the floor at row y.
    // ...
}
```

I really don't recall the per-row endpoints. But I DO recall the per-pixel simpler version: for each y, compute a single "row distance" then for each x compute the floor point. The per-row distance formula is:
`rowDistance = (h/2.0) / (y - h/2)` ... and then the floor point = player + rowDistance * rayDir. Let me check alignment: at y = wallBottom = h/2 + h/(2*dW): rowDistance = (h/2)/(h/(2*dW)) = dW. So the floor point at the wall bottom row is at distance dW (along the column rayDir) → exactly the wall's base! Aligned! So `rowDistance = (h/2)/(y - h/2)` corresponds to eyeHeight=1.0 (EYE=1.0). And this aligns with the wall centering (which assumed eye=0.5). The inconsistency (floor uses EYE=1.0, wall uses eye-center 0.5) doesn't cause a visible seam because at the wall bottom the floor distance equals the wall distance. The only effect: the floor's perspective rate corresponds to a 90° vertical FOV while the wall is centered at eye-height 0.5... but since both agree at the wall boundary, it's consistent visually. So I'll use `rowDistance = (h/2)/(y - h/2)` (i.e., EYE=1.0) for both floor and ceiling. And the wall formula uses H/dW (centered). They align at wall edges. 

So floor formula: `d = (H/2) / (y - H/2)`. And per column, floor point world = player + d * rayDir(x), since rayDir = dir + plane*cameraX and d is perpendicular/forward distance (the column ray's forward component is 1, so moving d along rayDir advances forward by d — wait rayDir forward component = dir·(dir+plane*cameraX) = 1 (since dir unit, plane⊥dir). So d*rayDir has forward component d. ✓). So world = player + d*rayDir. Good. Sample floor texture at (world.x, world.y) mod tile. 

This is the formula. Let me code floor + ceiling with it. eyeHeight effectively 1.0. 

Now horizontal plane length = plane (tan FOV/2). With H/2 as half-height and floor formula, the vertical FOV: at bottom row y=H-1, d=(H/2)/(H/2-1)≈1.0, floor point 1.0 away. The downward angle to bottom row: the ray from eye (height? in this formula eye height isn't used; the floor starts at row H/2+1 directly below center). Actually the formula gives a 90° vertical FOV (d=1.0 at bottom row = the "near" distance). With plane length = 0.6 (horiz FOV ~61°), vertical FOV 90° — floor appears with its own perspective; should look okay. Actually since the floor formula is independent of plane, and the floor point world uses rayDir(x) (which depends on plane for x-offset), the floor's horizontal scaling matches the walls. Good. I'll use plane=0.6. The vertical FOV 90° means the floor spans from center to bottom over 90° half-angle? No, 90° total vertical. Eh. Let me just try it.

Hmm wait, if vertical FOV is 90° (d=1 at bottom row) but the player's eye "height" in the wall centering is 0.5 (wall centered at H/2), there's a mismatch in how far the floor extends. The floor at d=1 at the bottom row: is that "1 cell ahead" the floor tile right in front? If eye is 0.5 above floor, the bottom row should correspond to a distance like 0.5/tan(bottomAngle). With bottomAngle=45° (half of 90°), d=0.5/tan45=0.5 at bottom row, not 1.0. But formula gives 1.0. So the formula's eyeHeight=1.0 vs wall's 0.5. The floor would be "lower res" / start farther than the wall implies. Visually: the floor tile at the bottom of the screen would be at distance ~1.0 (one cell ahead) instead of 0.5 (half a cell). Slightly less floor near feet. Not a big deal; many raycasters look like this. 

I'll stop analyzing and just implement Lodevint's exact code. Let me write the floor casting using the per-column approach (iterate y, then x) which I'm confident is correct:

```js
// FLOOR
for (let y = midY + 1; y < H; y++) {
  let rowDist = (H/2) / (y - H/2);  // perpendicular distance
  // left and right world coords using left/right ray (cameraX=-1, +1)
  let fdx = rowDist * flx; ... 
  // Actually compute per column:
  for (let x = 0; x < W; x++) {
    let cameraX = 2*x/W - 1;
    let rayDirX = dirX + planeX*cameraX;
    let rayDirY = dirY + planeY*cameraX;
    let dist = rowDist; // forward distance (perp) for this column? but rowDist same for all x—correct since perpendicular distance constant per row
    let floorX = playerX + dist * rayDirX;
    let floorY = playerY + dist * rayDirY;
    // sample floor texture
  }
}
```
Wait, is `dist` (perpendicular forward distance to the row) the same for all columns x? Earlier derivation said yes (forward distance depends only on vertical angle = row). And floor point world = player + dist * rayDirX_col... but rayDir for column x has forward component 1, so dist*rayDir advances forward by dist — but the perpendicular distance should be exactly dist (forward component). ✓. So `floorX = playerX + dist*rayDirX_col`, etc. Good. This matches Lodevint.

But careful: rowDist here is the perpendicular distance (forward). The column rayDir's forward component is 1, so the world position is at forward distance rowDist. Good.

For capping by walls (floor shouldn't appear behind a wall in a column): I have zBuffer[x] = wall perp distance. Floor at row y exists only if rowDist > zBuffer[x]? Since floor distance increases as y→H/2 (rowDist→∞ at horizon) and decreases as y→bottom (rowDist small). The wall is at zBuffer[x]. The wall bottom row corresponds to rowDist = zBuffer[x] (since at wall bottom, d=zBuffer[x]). Below the wall bottom (larger y), rowDist < zBuffer[x] → floor points closer than the wall → but those are in front of the wall (the wall base is at the floor). Actually floor below wall bottom = floor in front of the wall, which is open space (visible). So we draw floor for all y from wall bottom+1 to H-1. There's no occlusion needed for floor by same-column wall (the wall is above the floor, not blocking the floor below it). Floor behind a wall would be a column where the wall is far; the floor extends to infinity—so floor always visible below walls. Fine. So no capping needed; cast floor every row below mid, every column (overdrawn by wall above). Good. 

For ceiling, mirror: rows y from 0 to mid-1, rowDist=(H/2)/(mid - y), ceiling point = player + rowDist * rayDir_col, sample ceiling texture. The ceiling is behind/above walls; walls drawn over. Good.

OK this works. Let me implement.

Texture sampling with light: darker farther. Use rowDist to compute shade factor = clamp(1/(1+rowDist*something), 0.4, 1). I'll do a simple distance fog/dust for atmosphere.

Now let me write everything. This is a big file. Let me write it.

Let me define constants and structures.

```js
const canvas = document.getElementById('c');
const ctx = canvas.getContext('2d');
const RES_W = 400, RES_H = 300;
const SCALE = 2;
canvas.width = RES_W*SCALE; canvas.height = RES_H*SCALE;
canvas.style.imageRendering = 'pixelated'; // via CSS
```
Actually set canvas.width=800, height=600, and drawImage the 400x300 offscreen scaled 2x, with ctx.imageSmoothingEnabled=false.

Let me set:
```js
const canvas = document.getElementById('c');
const ctx = canvas.getContext('2d');
const RES_W=400,RES_H=300;
const canvasW=RES_W,canvasH=RES_H; canvas.width=canvasW; canvas.height=canvasH;
const off = document.createElement('canvas'); off.width=RES_W; off.height=RES_H; const octx=off.getContext('2d');
let imgData = octx.createImageData(RES_W,RES_H);
let fb = new Uint32Array(RES_W*RES_H);
let zBuffer = new Float32Array(RES_W);
```
Then render to fb (as Uint32 RGBA), then `imgData.data` is Uint8Clamped; I can use a Uint32 view on it? ImageData.data is Uint8ClampedArray. I can create a Uint32Array view: `new Uint32Array(imgData.data.buffer)` and write to it, then putImageData. But careful: Uint32Array on Uint8ClampedArray buffer is fine if the buffer is a multiple of 4 bytes (it is). However, color byte order on little-endian: RGBA bytes become 0xAABBGG (RR in lowest byte). So a Uint32 pixel = 0xFF (alpha) << 24 | B<<16 | G<<8 | R = 0xFFBBGGRR. So to set color with RGB (r,g,b), pixel = (255<<24) | (b<<16) | (g<<8) | r. I need to ensure alpha=255. I'll set full. But putImageData reads alpha; if I leave alpha 255 it's opaque. Good. Let me compute pixels as uint32.

But there's a subtlety: ImageData.data is Uint8Clamped and the buffer may be a SharedArrayBuffer? No, regular ArrayBuffer. Creating a Uint32Array view on it works and shares memory. putImageData(imgData) will use the updated bytes. Good. This is fast (Uint32 writes).

Let me write a helper `setPixel(i, r,g,b)` or just compute uint.

Actually simpler: write directly to fb (Uint32Array of size W*H) and at end copy to a Uint32 view of imgData.buffer then putImageData. Or just operate on the Uint32 view of imgData.buffer directly and putImageData once. Let me do that: `const u32 = new Uint32Array(imgData.data.buffer);` then write u32[i]=pixel; putImageData(imgData) each frame. Avoid extra array. But getImageData/createImageData... createImageData allocates. Let me reuse. Actually I'll allocate `u32 = new Uint32Array(RES_W*RES_H*4 /4)` = RES_W*H uints = fb, plus separate ImageData. Hmm. Let me do: `imgData = octx.createImageData(RES_W, RES_H)` (allocates RGBA bytes), `u32 = new Uint32Array(imgData.data.buffer)`. Each frame: clear u32 (fill 0xFF000000 for black), draw walls/floor/sprites into u32, `octx.putImageData(imgData, 0,0)`, `ctx.drawImage(off,0,0,canvasW,canvasH)`. Wait canvasW=RES_W... let me draw at 2x scale to main canvas (800x600). Let me set main canvas 800x600 and drawImage(off,0,0,800,600). And `ctx.imageSmoothingEnabled=false`.

Actually to keep pixelated, set ctx.imageSmoothingEnabled=false. Good.

Let me set main canvas dimensions 800x600.

Now textures: I'll generate texture canvases of size TEX=64. For sampling in the framebuffer (which is in main memory u32), I need the texture pixels accessible. Let me getImageData from each texture canvas to get a Uint32 view for fast sampling. Textures:
- wallTextures = [wall, stone, brick2] (ImageBitmap? ) Let me just store as `{data: Uint32Array, size:64}` via getImageData.

So `makeTexture(fn)` creates a canvas, draws via ctx, returns getImageData → Uint8Clamped; I'll wrap as Uint32 view with size. Then sample pixel = tex.data[(ty*size+tx)] (already uint32 RGBA packed 0xAABBGGGRR... wait byte order). I'll precompute textures as Uint32 arrays so sampling is direct. For shading, I'll apply a factor: multiply RGB channels by factor, clamp. With uint32, extracting and re-multiplying per pixel is okay but a bit of work. For sprites I can also do shading. Let me write a `shade(color32, factor)`.

Actually, to keep shading fast, I might premake lightened textures? No, too many. Let me compute shade on the fly. A helper:
```
function shade(c, f){ 
  let r=(c&255)*f, g=((c>>8)&255)*f, b=((c>>16)&255)*f;
  return (c&0xff000000) | (b<<16) | (g<<8) | r; // keep alpha
}
```
But f as multiplier; r etc. need to clamp and integer. JS: (c&255)*f could be float; when OR'd it truncates. Need Math.min(255). Let me do:
```
function shade(c,f){
  f=f<0?0:f;
  let r=((c&0xff)*f) | 0; if(r>255)r=255;
  let g=(((c>>8)&0xff)*f)|0; if(g>255)g=255;
  let b=(((c>>16)&0xff)*f)|0; if(b>255)b=255;
  return (c&0xff000000)|(b<<16)|(g<<8)|r;
}
```
Good.

Now the brick texture generator (draw on canvas):
```js
function makeBrickTex(size, color){
  const c=document.createElement('canvas'); c.width=c.height=size;
  const t=c.getContext('2d');
  t.fillStyle='#331111'; t.fillRect(0,0,size,size); // mortar base
  const bw=size/4, bh=size/8;
  for(let row=0;row<size;row+=bh){
    let off = Math.floor(row/bh)%2 ? bw/2 : 0;
    for(let x=0;x<size;x+=bw){
      const bx=x+off;
      // brick color variation
      const rnd=Math.random()*0.25+0.75;
      t.fillStyle = hslish;
      t.fillRect(bx+1,row+1,bw-2,bh-2);
    }
  }
  // ... return imageData uint32
}
```
For brick color, let me use a red hue with slight variation: `t.fillStyle = 'hsl(340,'+(50+rnd*10)+'%,'+(30+rnd*10)+'%)` etc.

I'll make a few wall textures: brick (red), stone (gray), dark. Let me create a generic generator.

Enemy texture (face): 64x64. Let me draw a simple face: tan oval, dark eyes, red mouth, maybe a helmet. Procedural:
```js
function makeEnemyTex(size){
  const c=...; const t=c.getContext('2d');
  // base face color tan
  // draw face shape
  // eyes (black), teeth (white), hair/hat (dark)
}
```
I'll make a guard-like face: tan face, black eyes, grin, and a helmet (dark gray) on top. Or a green mutant. Let me make a simple but recognizable face.

Floor texture: a tile pattern (e.g., dark stone tiles with grout). Ceiling: lighter stone.

Weapon: I'll draw the pistol as canvas shapes (polygon) in the render, not a texture. Or a sprite. Let me draw directly: a dark gray shape at bottom center. On shoot, muzzle flash (yellow lines) and a slight kick upward. Good.

Now the main loop and game objects. Let me write it all.

Let me also handle the crosshair and weapon position.

Let me write the code now in index.html.

Let me think about enemies array and AI:
```js
const enemies=[]; // each: x,y, health, state, anim
function resetEnemies(){ enemies=[]; enemies.push({x:..,y:..,health:3}); ... }
```
AI: every frame, for each enemy, try to move toward player (if not in line-of-sight attack, move; if in range and visible, attack). Keep simple: enemies move toward player at speed*dt if the path cell ahead is empty. Also they shouldn't overlap walls. Use float positions with collision against map (and exit).

But if enemies move toward player through narrow corridors, they could get stuck. With 3 enemies and a roomy maze, should be okay. To reduce bugs, maybe keep enemies in place but make them pursue only when reachable... Let me give them pursuit but clamp movement with wall collision (sliding). If they get stuck, that's okay—they'll still be damageable when the player comes near. Actually if they're stuck in a corner they can still attack player when player is near. Fine.

Attack rule: enemy damages player if (1) within attack range (e.g., 1.6 cells), (2) clear line of sight (no wall between enemy and player), and (3) not on cooldown. Apply damage every cooldown (e.g., 1.0s) → 10 damage. Player health 100. 3 enemies * many hits → death possible.

Shooting: Player shoots, ray forward, find nearest visible enemy in a cone, reduce health. Need the enemy visible (clear line sight) and in front.

Let me define line of sight using castRay returning distance to first wall, compare with enemy distance.

castRay(px,py,dx,dy): DDA; returns {dist, x, y, side, ...}. dx,dy should be normalized? DDA works with any direction but step distances: deltaDistX = |1/dx|, etc. If dx,dy not normalized, perpWallDist = (dx*deltaDistX) relation... The formula (`mapX-px+(1-stepX)/2)/dx` works for any dx (it's the perpendicular distance). Actually perp distance = (mapX - px + (1-stepX)/2) / dx where dx is the ray direction's x. If dx is not unit, is it still perpendicular distance? The derivation: perpWallDist = |dot product| ... The standard Lodevint uses dx = dirX+planeX*cameraX (not normalized) and it gives correct perpendicular distance. Because the ray direction is dir+plane*cameraX; its forward component is dir·(that)=1 (since plane⊥dir and |dir|=1). The perpendicular distance = the scalar such that ... it comes out to (mapX - px + ...)/dx. I trust it. So castRay can take the unnormalized rayDir like the walls. Good.

For line of sight from enemy to player: compute dx=player.x-enemy.x, dy=..., then normalize to unit (length = distToPlayer). Pass to castRay. castRay returns dist to first wall (perpendicular? but it's along the enemy→player direction which may not be axis-aligned; the perp distance formula still gives the perpendicular distance to the wall measured along the ray direction's forward... hmm). Actually if I normalize the enemy→player vector and pass as dx,dy, the perpWallDist returned = (mapX-ex+(1-stepX)/2)/dx is the distance along the normalized direction to the wall (since dx,dy unit). And distToPlayer = length of enemy→player. If perpWallDist > distToPlayer → no wall between (wall is beyond player). Good. Let me use normalized direction for visibility rays.

But castRay also used for walls with non-normalized dir; both fine since formula is consistent for the direction's scaling? Let me double check: if dx,dy scaled by factor k, perpWallDist = (mapX-px+...)/(k*dx0). Since mapX-px+... is independent of k (the DDA grid traversal is by ±1, the sideDist increments deltaDistX=|1/dx|=|1/(k dx0)|, the hit cell same), perpWallDist scales by 1/k. For walls, the lineHeight = H/perpWallDist; if we use normalized dir (k=1) for the wall column rays, perpWallDist is the perpendicular distance and correct. But the column ray dir = dir+plane*cameraX is NOT unit (its forward component is 1, so its magnitude = sqrt(1+(plane*cameraX)²)); its perpWallDist from the formula = perpendicular distance (forward component) — wait the formula (mapX-px+...)/dx where dx is the x-component of the column ray. Since the column ray's forward (dir) component is 1, the perpendicular distance (along forward) = ... Let me trust Lodevint: they use dir+plane*cameraX (non-unit) and compute perpWallDist=(mapX-px+(1-stepX)/2)/rayDirX and it's the perpendicular distance (accounting for the forward component being 1). The reason: the DDA advances in grid units; the distance along the forward direction to the wall = (mapX-px)/(forward component) = (mapX-px)/1? No...

Ugh, the Lodevint formula is specifically tuned so that using rayDirX = dirX+planeX*cameraX (non-unit) yields the perpendicular distance because the forward component of rayDir equals the forward component of dir (=1) since plane is perpendicular to dir. The perpendicular distance to the wall = distance along the dir axis = (mapX - px)/rayDirX_component... Let me just trust Lodevint (it's correct and widely used). For visibility rays I'll use the same formula with normalized enemy→player vector; it gives the actual distance to the wall along that vector (since forward component of a unit vector pointing at angle is cos of deviation; the perpendicular distance to a wall = ... it gives the distance along the ray to the wall, which is what we want for comparing with distToPlayer). For an enemy→player unit vector, perpWallDist = distance along the ray to the wall hit. If that > distToPlayer, player is visible. Good. ✓.

Now, the column ray dir is NOT unit but its forward component is 1 (since dir unit and plane⊥dir). So perpWallDist = forward distance. The wall point = player + perpWallDist * rayDir_col gives forward dist + lateral via rayDir lateral. Wait if forward component is 1, then perpWallDist * rayDir_col has forward component perpWallDist*1 = perpWallDist ✓, and lateral component perpWallDist * (plane*cameraX). But the lateral at forward distance d should be d*tan(φ) = d*plane*cameraX (since dir unit). ✓. So world point = player + perpWallDist*rayDir_col. Good. So for floor, I use rowDist (perp/forward distance) * rayDir_col. ✓ consistent.

Great, everything consistent. Now let me code.

Let me write `castRay(px,py,dx,dy)`:
```js
function castRay(px,py,dx,dy){
  let mapX=Math.floor(px)|0, mapY=Math.floor(py)|0;
  let deltaDistX=Math.abs(1/dx), deltaDistY=Math.abs(1/dy);
  let stepX, stepY, sideDistX, sideDistY;
  if(dx<0){stepX=-1; sideDistX=(px-mapX)*deltaDistX;}
  else {stepX=1; sideDistX=(mapX+1-px)*deltaDistX;}
  if(dy<0){stepY=-1; sideDistY=(py-mapY)*deltaDistY;}
  else {stepY=1; sideDistY=(mapY+1-py)*deltaDistY;}
  let hit=0, side;
  while(!hit){
    if(sideDistX<sideDistY){sideDistX+=deltaDistX; mapX+=stepX; side=0;}
    else{sideDistY+=deltaDistY; mapY+=stepY; side=1;}
    // check map; treat exit cell as wall if locked
    let cell = level[mapY] && level[mapY][mapX];
    if(mapX===exit.x && mapY===exit.y && !exit.unlocked) cell = 9; // treat as wall (door)
    if(cell>0) hit=1;
  }
  let perpWallDist;
  if(side===0) perpWallDist=(mapX-px+(1-stepX)/2)/dx;
  else perpWallDist=(mapY-py+(1-stepY)/2)/dy;
  return {dist:perpWallDist, x:mapX, y:mapY, side, cell}; 
}
```
Edge: dx or dy = 0 → deltaDist infinite, but rayDir from player includes plane so unlikely exactly 0; guard with small epsilon.

Note: `level[mapY][mapX]` indexing [row][col] = [y][x]. Good. cell>0 hit. But exit door cell value I set to 9 but level array there is 0; I override in the check via the exit condition. For texture of the door, I'll detect mapX===exit.x && mapY===exit.y in rendering and use door texture. Good.

Also when exit locked and the DDA steps into exit cell, hit=1 (treat as wall) → player can't see/shoot through, and movement blocked (solid check also). When unlocked, cell stays 0, ray passes through; player can walk into exit cell center to win.

Wall rendering: I need per column the cell value to choose texture. I'll run the wall raycasting loop in render directly (not via castRay returning), storing zBuffer and drawing. Let me do the raycasting inline in render for walls, and use castRay separately for visibility/shooting. Or have castRay used for shooting and inline for rendering (for speed). I'll inline rendering.

Let me now also define texture indexing by cell value: cell 1→brick, 2→stone, 3→dark, 9(exit locked)→door texture, and I'll use the cell value as texture index (minus 1) but for door use a special index. Let me store textures in an array `wallTex = [brick, stone, dark]` and door separately. In rendering, `let texId = cell===9? door : wallTex[cell-1]` etc. Simpler: assign `texIndex`:
```
function texForCell(cell, mapX, mapY){
  if(cell===9) return TEX_DOOR; 
  return TEX_BRICK; // default
}
```
Let me just give each wall cell a texture based on value: I'll make the level use values 1..3 for different walls, and the door special. Let me keep level simple: mostly brick (1) with some stone (2) for the exit room, and door (9 handled) — but level stores 0 at exit; I override in render. Let me set stone walls around exit room for visual "locked zone". Eh, I'll just use brick everywhere plus the door texture at exit. Keep it simple: one brick wall texture, one door texture. Variety not required. Actually let me add 2 wall textures for visual interest (brick + stone) alternating or by region. I'll decide after.

Let me now also pick the enemy count: at least 3. I'll place 3 enemies.

Let me design the level now concretely. I'll use a 16x16 grid for more space. Let me carefully construct one with rooms and corridors, player start, 3 enemies, exit. Let me ensure connectivity.

Let me design on a 16x16 (x:0-15, y:0-15). I'll write rows top-to-bottom.

I'll make a central player start near top-left of a main chamber.

Level (1=brick wall, 2=stone wall, 0=empty, E=enemy location (0 but I track separately), X=exit location (0 in grid but tracked)):

```
y0:  1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
y1:  1 1 1 1 1 1 1 0 0 0 0 1 0 0 0 1
y2:  1 0 0 0 0 1 1 0 1 1 0 1 0 1 0 1
y3:  1 0 1 1 0 0 0 0 0 1 0 0 E 1 0 1
y4:  1 0 0 1 1 1 0 1 1 1 1 0 0 0 0 1
y5:  1 1 0 0 0 0 0 1 0 0 0 0 1 1 0 1
y6:  1 0 0 0 0 P 0 0 1 0 1 E 1 0 0 1
y7:  1 0 1 1 1 0 0 0 1 0 0 0 0 0 0 1
y8:  1 0 0 X 0 0 1 1 1 0 1 1 1 1 0 1
y9:  1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1
y10:1 0 0 0 0 0 1 1 1 1 1 0 1 1 1 1
y11:1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1
y12:1 1 1 0 0 0 1 0 1 1 1 1 1 1 0 1
y13:1 0 0 0 0 0 0 E 1 1 0 0 0 0 0 1
y14:1 0 0 0 1 1 1 1 1 1 1 1 1 1 0 1
y15:1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
```
Hmm this is getting messy and I can't easily verify connectivity by hand. Let me make a cleaner, simpler level that I can verify by running.

Let me make a simpler layout with a few connected rooms:

I'll use a 13x13 grid. Rooms connected by corridors. Let me design with clear paths:

Plan:
- Top-left room (player spawn)
- corridor right
- room top-right (enemy 1)
- corridor
- central room (enemy 2)
- corridor down
- bottom-left room (enemy 3)
- exit room (bottom-right, exit behind a door)

Let me draw 13x13:
```
y0  1 1 1 1 1 1 1 1 1 1 1 1 1
y1  1 0 0 0 0 1 0 0 0 0 0 0 1
y2  1 0 0 0 0 1 0 1 1 1 0 0 1
y3  1 0 P 0 0 0 0 0 0 1 0 0 1
y4  1 1 1 0 0 0 1 1 0 1 0 0 1
y5  1 0 0 0 0 1 1 0 0 0 0 0 1
y6  1 0 0 0 0 0 0 0 0 1 1 E 1
y7  1 0 0 0 1 1 0 1 0 0 0 0 1
y8  1 0 0 0 0 0 0 1 1 1 0 1 1
y9  1 1 1 1 0 1 0 0 0 0 0 0 1
y10 1 0 E 0 0 1 1 0 1 0 X 0 1
y11 1 0 0 0 0 0 0 0 1 1 0 0 1
y12 1 1 1 1 1 1 1 1 1 1 1 1 1
```
Hmm P at (2,3). Exit X at (10,10). Enemies E at (11,6),(2,10) and one more (where's enemy 3?). Let me add enemy 3. Let me place: E1 (11,6), E2 (5,5)? Let me reconsider.

Actually let me carefully design and verify connectivity with a mental flood fill. This is error prone; let me instead generate the level in code and just test movement by running the browser and walking. I'll iterate on the level until movement works. Let me start with a simple known-good level and expand.

Simplest valid level (small):
```
1 1 1 1 1 1 1 1 1 1 1 1 1
1 0 0 0 0 0 0 0 0 0 0 0 1
1 0 1 1 1 0 1 0 1 1 1 0 1
1 0 1 0 0 0 0 0 0 0 1 0 1
1 0 1 0 0 0 0 0 0 0 0 0 1
1 0 0 0 0 0 0 1 1 1 1 1 1
1 1 1 0 0 0 0 0 0 0 0 0 1
1 0 0 0 0 1 1 1 0 0 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 1
1 0 0 0 0 0 X 0 0 0 0 0 1
1 0 0 0 0 0 0 0 0 0 0 0 1
1 P 0 0 0 0 0 0 0 0 0 0 1
1 1 1 1 1 1 1 1 1 1 1 1 1
```
13x11 grid (I miscounted columns? let me use 13x11). Let me define 11 rows 0..10, 11 cols 0..10. Let me redo 11x11 for simplicity? Smaller is easier to verify. Let me do 11x11:
```
y0  1 1 1 1 1 1 1 1 1 1 1
y1  1 0 0 0 0 0 0 0 0 0 1
y2  1 0 1 1 1 0 1 0 1 1 1
y3  1 0 1 0 0 0 0 0 0 1 0 1  ... need 11 cols
```
Hmm 11 cols each row. Let me carefully build 11x11.

Columns x: 0..10. Rows y:0..10.
```
y0: 1 1 1 1 1 1 1 1 1 1 1
y1: 1 0 0 0 0 0 0 0 0 0 1
y2: 1 0 1 0 1 0 1 0 1 0 1
y3: 1 0 1 0 0 0 0 0 1 0 1
y4: 1 0 0 0 0 0 0 0 0 0 1
y5: 1 1 1 0 1 1 0 1 1 1 1
y6: 1 0 0 0 0 0 0 0 0 0 1
y7: 1 0 0 0 0 0 0 0 0 0 1
y8: 1 1 1 0 1 1 0 1 0 0 1
y9: 1 0 0 0 0 0 0 0 P 0 1
y10:1 1 1 1 1 1 1 1 1 1 1
```
P at (8,9). This has one big room basically (y1-y4, y6-y7 open, y8 narrow). Let me make it actually have separate rooms so line-of-sight matters. The current level: y5 is a wall row with gaps at x3 (1 0?), x6? Let me see y5: 1 1 1 0 1 1 0 1 1 1 1 → gaps at x3, x6. So vertical corridors at x3 and x6 connecting top and bottom rooms. y8 walls with gaps x3, x6, x8? y8: 1 1 1 0 1 1 0 1 0 0 1 → gaps x3,x6,x8,x9. Hmm.

This is getting complicated to verify. Let me just go with a level and test by running; adjust walls as needed. The key checks from the task: movement near start, wall collision, shooting, stable wall rendering, restart. As long as the player can move and hit walls, enemies work, exit reachable, it's fine.

Let me make a reasonably open level with a few pillars/walls so occlusion happens. Let me use a 16x16 and include some walls. I'll test.

Let me finalize a 16x16 level. I'll write it and test walking; I can always remove a wall if player gets stuck to exit.

Let me decide final level (16x16), with player at center-ish, enemies in alcoves, exit in a corner behind a door.

```
Row0   1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
Row1   1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
Row2   1 0 1 1 1 1 0 0 0 0 1 1 1 1 0 1
Row3   1 0 1 0 0 0 0 0 0 0 0 0 1 0 0 1
Row4   1 0 1 0 0 0 0 E 0 0 0 0 1 0 0 1
Row5   1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1
Row6   1 0 1 1 1 0 0 0 0 0 0 0 0 0 0 1
Row7   1 0 0 0 0 0 0 0 0 1 1 1 0 0 0 1
Row8   1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 1
Row9   1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
Row10  1 0 1 1 0 0 0 0 0 0 1 0 0 0 0 1
Row11  1 0 1 0 0 0 1 1 0 1 0 0 0 0 0 1
Row12  1 0 1 1 1 1 1 0 0 1 0 0 0 0 0 1
Row13  1 0 0 0 0 0 0 0 0 1 0 0 E 0 0 1
Row14  1 1 1 1 1 1 1 1 1 1 0 0 0 X 0 1
Row15  1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
```
Place E enemies at (7,4),(12,11),(12,13); X exit at (12,14) behind door (the cell (12,14) is 0 in map, but door? Let me make exit reachable: the bottom-right area. From row11-13 there are gaps allowing access to x12. Let me ensure a path from player to exit and to each enemy. Player at (7,1)? Let me place P at (7,1) (row1 middle). Let me set P at (7,1).

Hmm I realize I haven't designated player position in the grid; let me place player in code at a specific cell, not in the grid. Let me set player at (7.5, 1.5) facing south? Facing toward center. Let me face player south (dirY=1, down). Actually spawn facing into the map (south). dirX=0, dirY=1. Then arrows turn.

Let me make sure (7,1) is empty (row1: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 → x7=0 ✓). Good.

Exit at (12,14): row14 col12 = 0 ✓. The exit cell is empty; I'll treat as door when locked. To reach, path: from (7,1) go south down the central corridor. Row8 has wall at x0-5 (1 1 1 1 1 1) but gaps at x6-? Row8: 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 1 → x6-14 empty, connecting to bottom. Good, central path open downward to rows 13-14 bottom-right where exit is at x12,y14. But row14: 1 1 1 1 1 1 1 1 1 1 0 0 0 X 0 1 → x10,11,12,13 empty, x14 wall. Exit at x12,y14 reachable from x12,y13 (row13 col12=0? row13: 1 0 0 0 0 0 0 0 0 1 0 0 E 0 0 1 → col12=0? Let me index: positions: 0:1,1:0,2:0,3:0,4:0,5:0,6:0,7:0,8:0,9:1,10:0,11:0,12:E(0),13:0,14:0,15:1. So col12=0 (E is just my marker, actual cell 0). Good exit reachable from below via row13 col12 empty, up to row14 col12 (exit). But exit door locked until enemies dead → blocked. After enemies dead, open and walk to (12,14 center) → win. Good.

Enemies: E1 (7,4): row4 col7=0? row4: 1 0 1 0 0 0 0 E 0 0 0 0 1 0 0 1 → col7=E→0. Good, empty alcove with walls around (col6=0, col8=0...). Actually it's an open area with pillars. Fine.

E2 (12,11): row11 col12=0? row11: 1 0 1 0 0 0 1 1 0 1 0 0 0 0 0 1 → col9=1 (wall). col12=0 ✓. Area has walls.

E3 (12,13): row13 col12=0 ✓ (open). Close to exit—ok.

These enemies are reachable. Some behind walls from the player's start (e.g., E1 at (7,4) is behind the row2 wall? row2: 1 0 1 1 1 1 0 0 0 0 1 1 1 1 0 1 → col2-5 are walls in row2. So from player at (7,1), to reach (7,4) go south: row1 col7 empty, row2 col7=0 (col7 is 0 in row2 since row2 col6,7,8,9 are 0), so path south along x7 is open through row2 col7, row3 col7 (0), to row4 col7. Good reachable.

For line-of-sight/shooting: E1 at (7,4) is directly south of player (same x line), visible through the open corridor—so the player sees it. That's fine (still can shoot; occlusion matters for enemies behind walls elsewhere). To ensure occlusion matters, E2/E3 should be behind walls from the player's line of fire. E2 at (12,11): from player (7,1), there are walls in between (row5-8 walls), so not directly visible until player navigates there. Good.

I think this level works. Let me finalize it. Let me also maybe add more walls to create distinct rooms. Actually this is fine for testing.

Let me reduce to ensure not too many dead-ends that trap the player; I'll test.

Let me now also reconsider: enemies pursue the player. If E2 at (12,11) pursues player to center, that changes encounter. Could get complex but okay.

Let me keep enemies pursuing with wall collision. Let me make pursuit speed slower than player.

Now, the "clear attack rule" for enemy damage: enemy damages player when (within range AND line of sight). Good.

Let me also make enemies take multiple hits? The task says "shots cannot damage an enemy through a wall"—doesn't specify health. Let me give enemies 1 hit to kill (simpler) or 3 hits for more combat. Let me give 3 hits (health=3) for a shooter feel. Actually with 3 enemies and 3 health each, player must land 9 hits; fine. Let me do health=3, and a hit cooldown (can't shoot rapidly to insta-kill). Shoot cooldown ~0.25s.

Alternatively enemies die in 1 hit but there are 3; simpler. Let me do health=2 each? Eh, let me do health=3 for combat feel. Actually to reduce risk of enemies overwhelming near exit, let me give health=1 maybe. Hmm. Let me do health=3 but enemy attack cooldown 1.2s and range 1.8; player health 60; enemy does 15 per hit → 4 hits kills. Reasonable.

Let me just pick: playerHealth=100, enemyHealth=3, enemyAttackRange=1.6, enemyAttackCooldown=1.3s, enemyDamage=12, enemySpeed=0.9*playerSpeed. Shoot cooldown 0.2s.

Now weapon: pistol. Fire straight forward. Hit detection: nearest enemy within small angle and visible.

Let me define forward direction = dirX,dirY (facing). For shoot, aim along forward. Check each alive enemy: compute angle between forward and (enemy-player) direction. If |angleDiff| < weaponHalfAngle (say 5° = 0.087 rad) and within range 8 and visible (castRay from player to enemy; first wall dist > enemyDist). Among those, pick nearest; damage. 

Actually, let me make shooting more forgiving/accurate: since aiming is fixed forward and no mouse, requiring precise angle is harsh. Let me increase weaponHalfAngle to ~8° and give enemies some size. With enemies pursuing (moving straight toward player), they'll often be near the forward direction. Should be fine. Let me set half-angle ~ 10° to be forgiving but still require decent facing. Or, alternatively, make the "aim" snap to the nearest enemy within a cone when shooting—still requires facing roughly. I'll use 8°.

Let me reduce scope risk: maybe make enemies NOT pursue but stay put, and the player navigates to get line of sight. That avoids enemy AI bugs. But then enemies don't damage unless player walks into their range; still works. Pursuit adds liveliness. Given 15 min and testing, pursuit adds movement to test occlusion (good for "enemies must be occluded by walls; shots cannot damage through wall"). With static enemies, occlusion is still tested (shooting around corners misses). Let me do pursuit but keep it simple, and test.

Actually, dynamic enemies flying around sprites could expose sprite sorting bugs. Let me keep enemies pursuing but slowly and colliding. I'll test.

Let me also implement sprite occlusion properly (zBuffer).

Now let me also think: shooting "through a wall" test. When player shoots an enemy behind a wall, castRay from player to enemy should return wallDist < enemyDist → not hit. Good, the visibility check prevents it. ✓.

Let me also verify sprite rendering behind walls: sprites compared against zBuffer per column. ✓.

Alright, let me write the code. I'll write it all into index.html now. Then run and test.

Let me write the HTML skeleton and JS.

I'll write the file.

One more: controls display. I'll show a small overlay at bottom or top: "W/S Move | A/D Strafe | ←/→ Turn | Space Shoot | R Restart". And show Health and Enemies. And weapon.

Let me also add a crosshair (simple + sign at center) and weapon (pistol) drawn at bottom center.

Let me code the weapon shape: a simple rectangle grip + barrel + guard. I'll draw with ctx on the main canvas (or off?). Since main canvas is the upscaled offscreen, drawing UI directly on main canvas with ctx after drawImage(off,...) works. I'll draw weapon each frame in 3D state.

Muzzle flash: when shoot timer active, draw a few yellow/orange lines near muzzle.

Let me write it.

For the restart button: DOM button. Let me add `<button id="restart">Restart</button>` hidden until win/lose; show it; on click resetGame. Also R key restarts. Also click anywhere or Start. Let me also show a title overlay at start (gameState 'start') with instructions and a Start button.

Game states: 'start' → 'playing' → 'won'|'dead'. Restart → 'playing'.

Let me implement states and overlays drawn on main canvas.

Let me write the code now.

Let me carefully write the texture functions returning a Uint32 array + a separate for sampling with width.

I'll structure textures as objects: `{data: Uint32Array, w:64}`.

For wall rendering, I sample tex.data[(ty*w + tx)].

Let me write `sample(tex, tx, ty)` returning uint32 color.

Lighting for walls: side (0/1). Let me darken side==1 by factor 0.6 and side==0 by 0.85? Actually typical: side==1 (horizontal wall) darker. I'll do side==1 → 0.55, side==0 → 0.85 of original. Plus distance fog.

Let me also apply distance-based darkness for atmosphere: factor = 1/(1+0.15*dist) clamp 0.3..1. Combine.

For floor: shade by distance similarly (darker far), and maybe add a checker for the two tile materials.

Let me produce textures:
- `texWall`: brick (size 64).
- `texStone`: gray stone.
- `texDoor`: a wood/grilled door.
- `texEnemy`: guard face (64x64).
- `texFloor`: stone tile floor (64x64) — actually floor texture is large area; a 64 tiled works.
- `texCeil`: lighter.

Let me write generators using canvas 2D.

Enemy face generator: draw a tan circle/oval, black eyes, white teeth, green armor? Let me do a simple face: 
- base: tan oval.
- eyes: two black ovals.
- mouth: grin (red? white teeth).
- hat/helmet: dark on top.
I'll keep it simple but enemy-like.

Let me now write the file. I'll aim for correctness.

For player movement collision `solid(x,y)`: returns true if cell is wall or (exit locked). 

```
function solid(x,y){
  let mx=Math.floor(x)|0, my=Math.floor(y)|0;
  if(mx<0||my<0||mx>=LW||my>=LH) return true;
  let c=level[my][mx];
  if(c>0) return true;
  if(exit.x===mx && exit.y===my && !exit.unlocked) return true;
  return false;
}
```

Player move with radius:
```
function movePlayer(mx,my){
  let nx=player.x+mx, ny=player.y+my;
  const r=0.25;
  if(!solid(nx+r,ny+r)&&!solid(nx-r,ny+r)&&!solid(nx+r,ny-r)&&!solid(nx-r,ny-r))...? 
}
```
The sliding approach (separate axes):
```
function movePlayer(dx,dy){
  let nx=player.x+dx, ny=player.y+dy;
  const r=0.28;
  // X axis
  if(!solid(nx+r, player.y) && !solid(nx-r, player.y)) player.x = nx;
  if(!solid(player.x, ny+r) && !solid(player.x, ny-r)) player.y = ny;
}
```
This allows sliding along walls. Good. But if both blocked, no move. Good. Use r relative: test corners. The above tests two points on the X movement; fine for a small radius. Let me also test corners properly but two-points per axis is okay.

Enemy AI: 
```
function updateEnemy(e,dt){
  if(!e.alive) return;
  let dx=player.x-e.x, dy=player.y-e.y;
  let dist=Math.hypot(dx,dy);
  // line of sight to player?
  let vis = (castRay(e.x,e.y, dx/dist, dy/dist).dist >= dist*0.98);
  if(dist < e.attackRange && vis){
    // attack (cooldown)
    e.cooldown -= dt;
    if(e.cooldown<=0){ e.cooldown=0.9; dealPlayerDamage(12); }
    // don't move while attacking
    return;
  }
  // pursue
  let spd=enemySpeed*dt;
  // move toward player if next cell free
  let nx=e.x+(dx/dist)*spd, ny=e.y+(dy/dist)*spd;
  // collision slide
  const r=0.25;
  if(!solid(nx+r,e.y)&&!solid(nx-r,e.y)) e.x=nx;
  if(!solid(e.x,ny+r)&&!solid(e.x,ny-r)) e.y=ny;
}
```
Note: enemies might pile at player; with attack range 1.6 they stop to attack when close. Good. They won't pass through walls (solid checks). They might not perfectly navigate turns (direct line move blocked by wall → slide → may get stuck pushing along). Could get stuck but acceptable. To improve, use a simple steering: if direct move blocked, try moving along wall. Keep simple.

Hmm, enemies moving along wall with slide: if direct step is blocked, the X move may be blocked too; they could get stuck. Acceptable for this scope; let me test.

Now shooting hit detection uses the player→enemy castRay for visibility. Let me implement:
```
function shoot(){
  let best=null, bestDist=Infinity;
  let fX=player.dirX, fY=player.dirY; // forward unit vector (normalized)
  for(e of enemies){
    if(!e.alive) continue;
    let dx=e.x-player.x, dy=e.y-player.y;
    let dist=Math.hypot(dx,dy);
    if(dist>weaponRange) continue;
    // angle check
    let dot = dx*fX+dy*fY; // = dist*cos(angle) if f unit & (dx,dy) not unit; cos = dot/dist
    let cosAngle = dot/dist;
    if(cosAngle < Math.cos(weaponHalfAngle)) continue; // outside cone
    // visibility
    let vis = castRay(player.x,player.y, dx/dist, dy/dist).dist >= dist*0.95;
    if(!vis) continue;
    if(dist<bestDist){ bestDist=dist; best=e; }
  }
  if(best){ best.health--; if(best.health<=0){best.alive=false;} }
  // muzzle flash
  lastShotTime=performance.now(); shootAnim=0.2;
}
```
I need player.dirX,dirY normalized (unit). I'll keep them unit and rotate together with plane.

Enemy count for win condition: count alive enemies; when 0 and exit reachable → unlock exit.

Let me set exit.unlocked = (enemiesAlive()===0). When unlocked, door opens (render as open / no wall, and cell passable). When all dead, also show a visual cue (door opens, maybe a sound). Player walking into exit cell triggers win.

Win check: in update, `if(exit.unlocked && Math.floor(player.x)===exit.x && Math.floor(player.y)===exit.y){ gameState='won'; }`. But player might approach from outside; floor check. Let me use distance to exit cell center < 0.5? Let me check if player is within the exit cell and exit unlocked. Use Math.floor of player pos equals exit cell. Good. But player must be exactly inside. Good.

Also require enemies all dead for exit to work (so reaching exit before killing → door blocks, player can't enter). Good.

Now let me write weapon range ~10 cells. Half-angle ~7°.

Let me also add a small crosshair.

Let me now write the full code. I'll be verbose but careful.

Let me also consider the FOV/plane: dir=(1,0)? Player faces? Let me set initial facing: I'll spawn facing south? Let me spawn facing east (into the map). Let me spawn player at (7.5, 1.5) facing south (down, dirX=0,dirY=1) so the first view looks into the level. Row1 is near the top; facing south looks down into the maze. Good. dirX=0, dirY=1, planeX = -planeY? The plane must be perpendicular to dir. If dir=(0,1), a perpendicular plane is (1,0) or (-1,0). For a left-handed turn, plane = (0.6, 0)? Standard: plane is dir rotated ±90°. If dir=(0,1), rotate +90° → (-1,0) or +90 → (1,0)? Rotating (0,1) by +90° (counterclockwise) = (-1, 0). So plane=(-0.6, 0) or (0.6,0). Sign determines left/right turn. Let me set plane=(0.6, 0)? Let's just pick plane=(dir rotated -90°)*(tanFOV/2). Hmm sign affects turn direction. I'll set it so left turn = turning left (standard). Let me define dir=(0,1) (south, down), and to rotate left (ArrowLeft) we rotate dir CCW by small angle. plane should be 90° left of dir (CCW) → rotate (0,1) CCW 90 = (-1,0). So plane = (-tanFOV/2, 0). If FOV 60°, tan=0.577, plane=(-0.577, 0). Then ArrowLeft reduces angle? Rotation formulas: rotating dir and plane by angle a: 
newDirX = dirX*cos - dirY*sin; newDirY = dirX*sin + dirY*cos.
For a left turn (CCW), a>0. With dir=(0,1): newDirX = -1*sin(a) = -sin(a); newDirY = cos(a). For small a>0, dirX becomes negative (pointing left-ish) and dirY ~1. So facing turns left. Good. Plane similarly rotated.

Let me set FOV via plane length = 0.5773 (60°) and scale = that. dir unit length 1. Good.

Let me set player: x=7.5, y=1.5, dirX=0, dirY=1, planeX=-0.577, planeY=0.

Wait sign of plane: I'll pick planeX = +0.577 or -0.577? It only affects whether left/right is mirrored; rotation handles it. Let me use planeX = 0.577, planeY=0 with dir=(0,1). Actually let me just pick and ensure arrows turn sensibly; if reversed, I'll flip. I'll test.

Let me now write code.

For rendering walls inline:
```
for(let x=0;x<W;x++){
  let cameraX = 2*x/W - 1;
  let rayDirX = player.dirX + player.planeX*cameraX;
  let rayDirY = player.dirY + player.planeY*cameraX;
  // ... DDA as in castRay but also compute wallX and draw
}
```
I'll inline for efficiency and to fill zBuffer and draw into fb.

Let me write a draw column function that writes to fb and zBuffer.

```
function renderWalls(){
  for(let x=0;x<W;x++){
    let cameraX=2*x/W-1;
    let rdx=player.dirX+player.planeX*cameraX;
    let rdy=player.dirY+player.planeY*cameraX;
    let mapX=Math.floor(player.x)|0, mapY=Math.floor(player.y)|0;
    let ddx=Math.abs(1/rdx), ddy=Math.abs(1/rdy);
    let stepX,stepY,sx,sy,side;
    if(rdx<0){stepX=-1;sx=(player.x-mapX)*ddx;}else{stepX=1;sx=(mapX+1-player.x)*ddx;}
    if(rdy<0){stepY=-1;sy=(player.y-mapY)*ddy;}else{stepY=1;sy=(mapY+1-player.y)*ddy;}
    let hit=0;
    while(!hit){
      if(sx<sy){sx+=ddx;mapX+=stepX;side=0;}else{sy+=ddy;mapY+=stepY;side=1;}
      let cell = (level[mapY]&&level[mapY][mapX])|0;
      if(!cell && mapX===exit.x && mapY===exit.y && !exit.unlocked) cell=9;
      if(cell>0) hit=1;
    }
    let perp;
    if(side===0) perp=(mapX-player.x+(1-stepX)/2)/rdx;
    else perp=(mapY-player.y+(1-stepY)/2)/rdy;
    zBuffer[x]=perp;
    let lineHeight = Math.floor(W_? ) ; // = H/perp but W used; use H
    let lh = Math.floor(H/perp);
    let drawStart = Math.floor(H/2 - lh/2);
    let drawEnd = Math.floor(H/2 + lh/2);
    if(drawStart<0)drawStart=0; if(drawEnd>=H)drawEnd=H-1;
    // texture
    let t;
    if(cell===9) t=texDoor; else { let v=cell-1; t = (v===0?texWall:(v===1?texStone:texWall)); }
    let tw=t.w;
    // wallX
    let wallX;
    if(side===0) wallX=player.y+perp*rdy; else wallX=player.x+perp*rdx;
    wallX -= Math.floor(wallX);
    let tx=Math.floor(wallX*tw)|0;
    if(side===0 && rdx>0) tx=tw-1-tx;
    if(side===1 && rdy<0) tx=tw-1-tx;
    // shade factor
    let colFact = side===1?0.55:0.85;
    let fog = 1/(1+0.2*perp); if(fog<0.25)fog=0.25;
    let f=colFact*fog;
    // draw column
    let col = x + (drawStart)*W; wait fb index: y*W + x. 
    for(let y=drawStart;y<=drawEnd;y++){
      let d = y - (H/2 - lh/2); // distance from top of wall
      let ty = Math.floor((d * tw)/lh)|0; // texture y
      if(ty<0)ty=0; if(ty>=tw)ty=tw-1;
      let col = t.data[ty*tw+tx];
      fb[y*W+x] = shade(col, f);
    }
  }
}
```
Wait `col = t.data[ty*tw+tx]`. And `ty = (y - drawStartBase)*tw/lh` where drawStartBase = H/2 - lh/2. Let me compute `let y2 = y - Math.floor(H/2 - lh/2)`; ty = floor(y2 * tw / lh). Good. Let me use drawStart as the base (the actual clamped drawStart may differ from H/2-lh/2 if clamped; but for texture mapping use the unclamped base). Let me keep base = H/2 - lh/2 and ty from that, clamp ty.

Let me store `const lineBase = H/2 - lh/2;` then for y loop, ty = floor((y-lineBase)*tw/lh). Good.

Now floor casting:
```
function renderFloorCeil(){
  // floor rows H/2+1 .. H-1 ; ceiling rows 0..H/2-1
  for(let y=0;y<H;y++){
    let rowDist = (H/2) / ( (y<H/2? H/2 - y : y - H/2) );
    ...
  }
}
```
Wait for ceiling rows y<H/2, the formula d = (H/2)/(H/2 - y) (using H/2 - y). For floor y>=H/2: d=(H/2)/(y-H/2). But y=H/2 (center) → div by zero; skip y=H/2 (it's the horizon). For y just below center (y<H/2) ceiling distance large; y near bottom (y=H-1) distance small. Good.

For each x, floor point world = player + rowDist*rayDirX. rayDirX depends on x. So:
```
for(let y=0;y<H;y++){
  if(y===H/2) continue;
  let denom = (y<H/2) ? (H/2 - y) : (y - H/2);
  let rowDist = (H/2)/denom; // forward distance
  let isFloor = y>H/2;
  // iterate x
  for(let x=0;x<W;x++){
    let cameraX=2*x/W-1;
    let rdx=player.dirX+player.planeX*cameraX;
    let rdy=player.dirY+player.planeY*cameraX;
    let fx=player.x+rowDist*rdx, fy=player.y+rowDist*rdy;
    // sample texture
    let t = isFloor? texFloor : texCeil;
    let tx = Math.floor((fx*t.w)) & (t.w-1); // wrap (t.w power of 2)
    let ty = Math.floor((fy*t.w)) & (t.w-1);
    // shade by distance
    let fog = 1/(1+0.25*rowDist); if(fog<0.2)fog=0.2;
    let base = t.data[(ty*t.w+tx)];
    fb[y*W+x] = shade(base, fog);
  }
}
```
But this computes rdx/rdy per pixel (redundant). Optimize: compute left and right endpoints and interpolate. But for 400x300 = 120k pixels, per-pixel recompute is okay-ish but the rdx recomputation 120k times... manageable. Let me optimize a bit: precompute rdx per column once into arrays. Let me precompute `rayX[x]` and `rayY[x]` arrays once per frame (used for walls too). Good.

This floor approach ignores walls (draws floor everywhere then walls overdraw). Fine.

But note: computing fx = player.x + rowDist*rdx uses rowDist which is the forward distance for that row (same for all x) and rdx the column ray's x-direction. Since forward component of rdx is dirX*... wait rdx = dirX + planeX*cameraX. Its forward (dir) component = dirX (since planeX is perpendicular to dir, the planeX*cameraX part is lateral; the dirX part is forward). But for forward distance rowDist, position = player + rowDist*(dir + lateral). The forward component of (dir + plane*cameraX) = dir·dir + cameraX*plane·dir = 1 (dir unit, plane⊥dir). So moving rowDist along this ray advances forward by rowDist. ✓. So fx,fy correct. 

Let me ensure dirX,dirY unit (|dir|=1). I'll keep them normalized; rotation preserves length. plane perpendicular & |plane|=tan(FOV/2). Good.

Now sprites (enemies):
```
function renderSprites(){
  // sort by distance (transformY) back to front
  let list=[];
  for(e of enemies){
    if(!e.alive) continue;
    let dx=e.x-player.x, dy=e.y-player.y;
    // transform
    let inv = 1/(player.planeX*player.dirY - player.dirX*player.planeY); // =1 since determinant; plane⊥dir, |dir|=1, det = dirY*1?? let's compute: det = dirX*planeY - dirY*planeX? sign. Standard: invDet = 1/(planeX*dirY - dirX*planeY). Since plane⊥dir, |plane|=p, this determinant = ? dir=(0,1), plane=(-p,0): planeX*dirY - dirX*planeY = (-p)*1 - 0 = -p. inv = -1/p. We'll just compute.
    let tx = inv*(player.dirY*dx - player.dirX*dy);
    let ty = inv*(-player.planeY*dx + player.planeX*dy); // = distance (forward)
    list.push({e,tx,ty});
  }
  list.sort((a,b)=>b.ty-a.ty); // furthest first
  for(let {e,tx,ty} of list){
    if(ty<=0) continue; // behind
    let sX = Math.floor(W/2 * (1 + tx/ty));
    let sY = Math.floor(H/2 + H/(2*ty) ... ) // vertical position: sprite at eye height? Place sprite vertically centered similar to walls: height = H/ty (since |dir|=... H*1/ty? Actually sprite height = (H/perpDist) for a sprite of "height" 1). The sprite occupies height H/ty (like wall lineHeight=H/dist with 1 unit tall). Place base at floor: sY = H/2 + H/(2*ty)? Using same convention as walls (centered) → sY = H/2 - H/(2*ty), height = H/ty. Let me center the sprite vertically like walls (so enemies are "1 unit tall" standing on floor, centered? Actually we want them on the floor, so base at H/2 + H/(2*ty) and height H/ty, i.e., top at H/2 - H/(2*ty)). That's same as walls centered — meaning the sprite floats centered, with feet at H/2+H/(2ty). That's the Lodevint sprite (they're centered, appear standing). Fine.
    let sh = Math.floor(H/ty);
    let drawStartY = Math.floor(H/2 - sh/2);
    let drawEndY = drawStartY + sh;
    let sWpx = sh; // width = height (square) for a billboard? Let me make width = sh (1:1).
    let drawStartX = Math.floor(sX - sh/2);
    let drawEndX = drawStartX + sh;
    // clamp
    // texture
    let t=texEnemy; let tw=t.w;
    let fog=1/(1+0.15*ty); if(fog<0.25)fog=0.25;
    let f=fog;
    for(let sy=drawStartX... ) draw columns:
    for(let sx=0;sx<sh;sx++){
      let px=drawStartX+sx;
      if(px<0||px>=W||ty>=zBuffer[px]) continue; // behind wall
      // Actually need depth test per column: if ty < zBuffer[px] then draw (sprite closer)
      for(let sy=0;sy<sh;sy++){
        let py=drawStartY+sy;
        if(py<0||py>=H) continue;
        if(ty >= zBuffer[px]) break; // sprite behind wall in this column; but zBuffer is per column; if sprite behind wall for this column, skip column
        let tx2 = Math.floor(sx*tw/sh); 
        let ty2 = Math.floor(sy*tw/sh);
        let col = t.data[ty2*tw+tx2];
        if(col===transparentKey) continue; // skip transparent
        fb[py*W+px]=shade(col,f);
      }
    }
  }
}
```
The depth test: sprite distance (ty, perpendicular) vs zBuffer[px] (wall perpendicular distance). If ty < zBuffer[px], sprite is closer → draw. Else skip (behind wall). ✓. To speed, check once per column: if ty >= zBuffer[px], skip whole column. Else draw whole column. But within a column, the sprite may be partially behind wall at some rows only if wall is the sprite's column distance... actually wall distance is constant per column (zBuffer), sprite distance ty constant, so per-column test suffices. Good, skip column if ty>=zBuffer[px]. This occludes sprites by walls. 

For transparency: enemy texture has a color key (e.g., magenta) for background; skip those pixels. I'll generate enemy tex with a transparent background color (say pure magenta #FF00FF) and skip in sprite rendering.

Sprite width = height (1:1) which for a 1-unit tall billboard at the floor looks okay (enemies not too tall). Let me maybe make sprite width = height * 0.6 to look more human-ish? Billboard enemies in Wolf3D are ~1 unit tall, width similar. Let me keep square but it's fine. Actually let me make width = sh (so they're square-ish, occupies 1x1 on floor). Good.

Now the weapon + UI + crosshair. Let me draw on main ctx after drawImage.

```
ctx.drawImage(off,0,0, canvasW, canvasH);
// UI (native res)
ctx.imageSmoothingEnabled=false;
// crosshair
// weapon
// text: health, enemies, controls
```

Let me set canvasW=800, canvasH=600, RES 400x300, scale 2. Wait canvas width/height attributes: I'll set canvas.width=800, height=600. off canvas 400x300. drawImage(off,0,0,800,600). imageSmoothingEnabled=false. Good.

But the render code writes fb (Uint32) of size 400x300, then putImageData, then drawImage scaled 2x. UI drawn at 800x600 native.

Let me write UI text in 800x600 space: health bar top-left, enemy count, controls hint at bottom.

Weapon: draw pistol shape at bottom center (in 800x600 space). On shoot, muzzle flash + slight upward offset.

Let me define weapon drawing using ctx paths.

Let me write the whole file now. It's long. Let me be careful with syntax.

Let me consider performance of floor casting computing cameraX per pixel 120k times and texture index mod. Fine.

Let me precompute rayX[x],rayY[x] arrays each frame (used by walls and floor).

Let me write `render()`:
```
function render(){
  // precompute rays
  let cos=this? ... 
  for(let x=0;x<W;x++){ rayX[x]=player.dirX+player.planeX*(2*x/W-1); rayY[x]=player.dirY+player.planeY*(2*x/W-1); }
  clear fb (fill 0xFF000000 black) - actually floor casting fills everything; but sprites/ceilings fill everything. Let me still fill black then floor fills. Skip fill for speed? Floor+ceil fill all but center row. Let me fill all black then floor casting will overwrite all rows except H/2. Let me just fill ceil+floor over everything. I'll skip explicit clear; floor casting covers all y (including ceiling). Good, no clear needed. But if any pixel not covered (e.g., H/2 row), leave black. Fine.
  renderFloorCeil();
  renderWalls(); // fills zBuffer, draws walls overwriting floor where walls are
  renderSprites();
  // to u32/ImageData
  imgData.data... we use u32 view
  octx.putImageData(imgData,0,0);
  ctx.drawImage(off,0,0,800,600);
  renderUI();
}
```

Wait, I'm using fb = u32 view of imgData.buffer directly. So drawing functions write to fb; then putImageData(imgData). Let me keep `const u32 = new Uint32Array(imgData.data.buffer)` and `const W=400,H=300`. fb refers to u32. Good. No separate fb.

Let me ensure Uint32 view on Uint8ClampedArray.buffer works (yes). And little-endian: 0xAABBGGRR. shade function uses r/g/b at bytes 0,1,2, alpha byte 3 = 0xFF. When I fill with `0xFF000000` that's alpha=255, rgb 0 (black). Good. Texture pixels from getImageData have alpha 255 (opaque) unless I draw transparent areas. For wall/floor textures all opaque. Enemy texture has transparent (magenta) areas—those pixels have rgba (255,0,255,255) which as uint32 = 0xFFFF00FF? Let me handle enemy transparency by checking the source pixel color: if it equals the key color, skip. I'll define key = (magenta) and test in sprite render (col & check). Easier: in sprite render, skip if (col & 0xFF00FF) matches... Let me just check `if((col&0xFF00FF)===0xFF00FF) continue;` i.e., r=255 and b=255 (magenta) and not green? Magenta = R255 G0 B255. col bytes: r255 g0 b255 a255. As uint32 LE: 0xFF00FF (a=255 at byte3 → 0xFF000000; b255 at byte2 →0x00FF0000; g0; r255 at byte0 →0xFF). So 0xFF00FF?? Let me compute: bytes [r=255,g=0,b=255,a=255] → uint32 = a<<24 | b<<16 | g<<8 | r = 0xFF<<24 | 0xFF<<16 | 0 | 0xFF = 0xFF00FF00|... wait 0xFF<<24 = 0xFF000000, b<<16=0x00FF0000, r=0xFF → 0xFFFF00FF? Let me just do: 0xFF000000 (alpha) + 0x00FF0000 (blue) + 0xFF = 0xFFFF00FF? No: 0xFF000000 | 0x00FF0000 = 0xFFFF0000, | 0xFF = 0xFFFF00FF. Hmm that includes green? No, 0xFFFF00FF means bytes r=FF,g=00,b=FF,a=FF? Let me decode 0xFFFF00FF as LE bytes: low byte r=0xFF, next g=0x00, next b=0x00? No: 0xFFFF00FF in binary: FF FF 00 FF. LE bytes: 0xFF(r), 0x00(g), 0xFF(b), 0xFF(a). So r=255,g=0,b=255,a=255 = magenta. Good. So key color as uint32 = 0xFFFF00FF. To test magenta: (col & 0x00FF00FF) === 0x00FF00FF? r and b both 0xFF: (col & 0xFF) === 0xFF && (col & 0xFF0000)===0xFF0000 → i.e., r==255 and b==255, regardless g. Magenta has g=0. Let me test `(col & 0xFF00FF) === 0xFF00FF`. 0xFF00FF mask = r in low byte (0xFF mask) and b in byte 2 (0xFF0000). Wait 0xFF00FF = bits: byte0 0xFF, byte1 0xFF, byte2 0x00, byte3 0xFF? Let me compute 0xFF00FF: 0x00FF00FF = bytes [FF,00,FF,00] in big-endian reading; as a number 0x00FF00FF. Masking col (0xFFFF00FF) & 0x00FF00FF = 0x00FF00FF. Yes equals 0x00FF00FF. Good, key = 0x00FF00FF. So condition `(col & 0x00FF00FF) === 0x00FF00FF` catches r==255 && b==255. That works for magenta background. But it also catches white (r=b=255,g=255) which might be a sprite color (e.g., teeth white). Hmm enemy teeth could be white (255,255,255) → would be skipped as transparent! Bad. Let me pick a distinct key color unlikely in sprite, e.g., bright cyan (r=0,b=255,g=255) or a specific value. Let me use key = R=0,G=255,B=0? green unlikely in guard. Or magenta with specific g=0 and accept teeth aren't white. Let me make enemy teeth not pure white (e.g., off-white 240,240,240) and use magenta key (255,0,255). Then mask `(col & 0xFF00FF) === 0xFF00FF && (col & 0xFF00) === 0` to ensure g=0 → pure magenta only. Let me just check exact key equality: `(col & 0x00FFFFFF) === 0x00FF00FF`? That's r=255,g=0,b=255 → 0x00FF00FF? decode 0x00FF00FF: bytes r=FF,g=00,b=FF,a=00 → as uint32 with a=255 would be 0xFFFF00FF. The full pixel including alpha: 0xFFFF00FF. But alpha might not be exactly 255 if drawn. Let me just check RGB part: `(col & 0xFFFFFF) === 0xFF00FF` (r255,g0,b255). 0xFF00FF as number = bytes r=FF,b=FF,g=00 → 0x00FF00FF. col & 0xFFFFFF extracts low 3 bytes (r,g,b). For magenta pixel col=0xFFFF00FF, &0xFFFFFF = 0xFF00FF. ✓. So condition: `(col & 0xFFFFFF) === 0xFF00FF`. I'll set the transparent areas on enemy canvas to that exact magenta and ensure no sprite pixel is pure magenta. Teeth white (255,255,255) → &0xFFFFFF=0xFFFFFF ≠ 0xFF00FF, not skipped. Good. But white's b=255,r=255; only skipped if g=0 (magenta). White has g=255, so safe. Good. Let me use key RGB 0xFF00FF (magenta) and test `(col & 0xFFFFFF) === 0xFF00FF`. 

But wait: I draw enemy sprite on a canvas; clearing it gives rgba(0,0,0,0) (transparent black), not magenta. So I must explicitly fill the enemy canvas background with magenta, or set composite. Let me in makeEnemyTex fill the canvas with magenta first, then draw the face on top (opaque), leaving magenta where no face. Then getImageData; magenta pixels = transparent. Then in sprite render skip magenta. Good. But getImageData on a canvas with globalAlpha? Use opaque draws. Fine.

Alternatively use offscreen canvas `globalCompositeOperation` but the fill approach is fine.

Hmm but the enemy texture's transparent (magenta) pixels, when drawn via... we don't draw them; we manually sample fb. The magenta is just our skip key. Good.

Actually simpler: store enemy texture as Uint32 data array and in sprite render skip if pixel is the key. Let me proceed.

Let me also give enemies a second frame or variation? Not needed.

Now let me also make sure the enemy sprite is drawn at the right vertical position so it stands on the floor. With centered height (like walls), the sprite from H/2 - sh/2 to H/2 + sh/2, and sh=H/ty (1 unit tall). Since walls are also 1 unit (floor to ceiling) shown centered, the enemy (1 unit tall) fills from floor to ceiling too (same as wall). That means enemies appear as tall as walls—fine (they're 1 unit). Good, they'll look like they stand on the floor with heads at ceiling. Acceptable. Actually they'd look a bit tall like a full-height sprite; that's how Wolf3D enemies look (they're ~1 unit). Good.

Now let me write the code fully. Let me also include a "start" screen and controls.

Let me also handle the weapon Bob (move with walking) — optional; I'll add a slight up/down sway based on movement for polish. Time permitting. Let me add minimal.

Let me write the file. I'll write carefully and then test.

Let me define the level array as a JS 2D array. I'll embed the 16x16 level. Let me finalize coordinates:
- W=16,H=16 grid.
- Player (px=7.5, py=1.5), dir=(0,1) (south). Wait facing south means dirY positive = downward in grid (row increases). Good.
- Exit at (12,14) → x=12,y=14. Locked until enemies dead; door there.
- Enemies: (7,4),(12,11),(12,13). 

Wait, my earlier level has E at row4 col7 (x=7,y=4), row11 col12 (x=12,y=11), row13 col12 (x=12,y=13). Let me re-verify the level array rows. Let me rewrite the level array cleanly with 16 columns and ensure enemies' cells are empty (0) and reachable.

Let me redefine a cleaner 16x16 level now, carefully, with 1-based walls and open cells, and verify connectivity mentally with a flood fill.

I'll create the level:
```
[1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1], // y0
[1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1], // y1
[1,0,1,1,1,1,0,0,0,0,1,1,1,1,0,1], // y2
[1,0,1,0,0,0,0,0,0,0,0,0,1,0,0,1], // y3
[1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,1], // y4  (enemy1 at x7,y4)
[1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,1], // y5
[1,0,1,1,1,1,0,0,0,0,1,1,1,1,1,1], // y6
[1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1], // y7
[1,1,1,0,0,0,1,1,1,0,0,1,1,1,1,1], // y8
[1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1], // y9
[1,0,0,0,0,0,0,1,1,1,0,0,0,0,0,1], // y10 (enemy2 x12? need x12,y10 empty)
[1,0,0,0,0,0,0,1,0,0,1,1,0,0,0,1], // y11 (enemy2 x12,y11? col12 here)
[1,0,0,0,0,0,0,1,0,0,0,1,1,1,0,1], // y12
[1,0,0,0,0,0,0,1,0,0,0,0,X,0,0,1], // y13 (X exit x12,y13?) 
[1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1], // y14 all walls? need path to exit at y13,y14
```
Hmm this is getting tangled and exit unreachable. The bottom rows need an opening to reach exit. Let me simplify drastically: make most of the level one big-ish room with some internal pillars/walls, plus a separate exit room accessed through a door. Let me do:

Main open area + exit room in bottom-right corner, connected via a corridor with a door.

Let me design:
- Top-left large room (player start), open.
- Internal walls/pillars (so occlusion happens).
- Corridor to bottom-right exit room with door at the exit room entrance.
- Enemies scattered in the open room (some behind pillars).

16x16:
```
y0  1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
y1  1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
y2  1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
y3  1 0 0 1 1 1 1 0 0 1 1 1 0 0 0 1
y4  1 0 0 1 0 0 1 0 0 1 0 1 0 0 0 1
y5  1 0 0 1 0 0 1 0 0 1 0 1 1 1 0 1
y6  1 0 0 1 0 0 1 0 0 0 0 0 0 0 0 1
y7  1 0 0 1 1 1 1 0 0 0 0 0 0 0 0 1
y8  1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
y9  1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
y10 1 0 0 0 0 1 1 1 0 0 0 0 0 0 0 1
y11 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1
y12 1 1 1 0 0 0 0 1 0 0 0 0 0 0 0 1
y13 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
y14 1 0 0 0 0 0 0 0 0 0 0 X 0 0 0 1
y15 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
```
Player at (7,1) facing south (down). Enemies: place E1 at (4,4)? (x4,y4 col4 row4 = 0? y4: 1 0 0 1 1 1 1 0 0 1 1 1 0 0 0 1 → col4=1 (wall). Hmm. Let me place enemies in open cells: 
- E1 at (2,2) (open).
- E2 at (9,3) (open, behind pillar).
- E3 at (11,9) (open).
Exit X at (10,14) (open cell, row14 col10=0 ✓). Path from player: down the open central area (y1-y9 all mostly open) to bottom, then to x10,y14. Row14 col10=0, reachable from col10 going down rows 11-14 (col10: y11=0,y12=0,y13=0,y14=0). And from top, col10 rows y1-y9 =0. So path exists. But the corridor into the very bottom and the exit: from (10,9) go down: y10 col10=0,y11 col10=0,y12 col10=0,y13 col10=0,y14 col10=0(=exit). Good open path. But I wanted a door (locked) at exit. The exit cell itself (10,14) — I'll treat as door when locked (solid). When unlocked open. So while enemies alive, (10,14) is solid (can't enter) → can't exit early. After killing all, it opens; walking into (10,14) center → win. 

But the cell (10,14) is open in the map (0); my solid() returns true for exit cell when locked. Good. And raycasting draws a door texture there when locked (cell override to 9). Good.

Enemies at (2,2),(9,3),(11,9). All open cells. Path reachable: (2,2) open neighbors: (2,1),(2,3),(1,2),(3,2) — (2,1) open, (2,3) open etc. player (7,1) can navigate to them. Fine. (9,3): row3 col9=0 (y3: ...1 0 0 1 1 1 1 0 0 1 1 1 0 0 0 1 → col9=1? let me index y3: col0=1,c1=0,c2=0,c3=1,c4=1,c5=1,c6=1,c7=0,c8=0,c9=1,c10=1,c11=1,c12=0,c13=0,c14=0,c15=1. So col9=1 wall. So (9,3) is a wall—not good. Let me pick enemy positions that are open. Let me re-pick: E2 at (9,8) (row8 col9=0 ✓, row8 is all open 0). E3 at (11,9) (row9 col11=0 ✓). E1 at (2,5) (row5 col2=0? y5: 1 0 0 1 0 0 1 0 0 1 0 1 1 1 0 1 → col2=0 ✓). Good E1 (2,5).

So enemies: (2,5),(9,8),(11,9). Exit (10,14). Player (7,1) facing south.

Hmm, enemy (11,9) close to exit; fine.

Let me verify the internal pillars don't fully isolate enemies. (2,5): reachable from (7,5)? (7,5)=0 (row5 col7=0). path west along row5: col6=1 (wall) blocks direct; col5=0, col4=0, col3=1 wall. So from col7 row5 go north: row5 col7=0, row4 col7=0, row3 col7=0, row2 col7=0, row1 col7=0, then west across row1 (all 0) to col2 row1, then down to (2,5)? from (2,1) down: col2 rows2=0,3=0,4=0,5=0 ✓. So reachable via top. Good, big open top area allows navigation.

(9,8): from player go south down col7 (open y1-y9 col7=0), then east along row8 (col9=0) → (9,8). Reachable. Good.

(11,9): from (9,8) east to col11 row8? row8 cols all 0, so (11,8)→(11,9) col11 row9=0 ✓ reachable.

Exit (10,14): from (11,9) down: col10 or col11 rows 10-14. col11 rows10? y10 col11=0,y11 col11 =? y11: 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 → col11=0 ✓; y12 col11=1 (wall y12: 1 1 1 0 0 0 0 1 0 0 0 0 0 0 0 1 → col11=0? index: c0=1,c1=1,c2=1,c3=0,c4=0,c5=0,c6=0,c7=1,c8=0,c9=0,c10=0,c11=0,c12=0,c13=0,c14=0,c15=1 → col11=0). y13 col11=0, y14 col11=1? y14: 1 0 0 0 0 0 0 0 0 0 0 X 0 0 0 1 → col10=X(0), col11=0, col12=0, col13=0, col14=1, col15=1. So exit col10 y14 =0 (X). Reach from (11,9): go to (11,10) col11 row10=0, (11,11)=0,(11,12)=0,(11,13) row13 col11=0,(11,14) row14 col11=0, then west to (10,14)=exit. Reachable. But wait col11 row12=0 (computed), row13 col11=0, row14 col11=0 → path down col11 open y8-y14. And exit (10,14) reachable. But there's an internal wall structure rows 8-12 around col7-9: row8 cols0-15 all 0 (open), row9 all 0 open, row10: 1 0 0 0 0 1 1 1 0 0 0 0 0 0 0 1 → col5,6,7 walls. So there's a wall pillar at col5-7 rows10-11. Does that block reaching exit? Exit via col11, not through that pillar. Fine.

Also note row10 col5,6,7 =1 walls, row11 col7=1 (y11 col7=1). So a pillar/wall around col7 between rows 10-11 — might box in? (7,11): row11 col7=1 wall. The exit path via col11 is clear. The player path to exit via col11 from top: col11 rows1-8: y1 col11=0,y2 col11=0...y8 col11=0, y9 col11=0, y10 col11=0, y11 col11=0, y12 col11=0, y13 col11=0, y14 col11=0. But to get to col11 from player (7,1): go south to row8 col7 (open), east along row8 to col11 (row8 all 0), then south col11 to exit. But row9 col11=0, row10 col11=0... yes. Wait y10 col11=0 (y10: col11=0 ✓). Good. So a straight path: (7,1)↓ ... (7,8)→east→(11,8)? row8 col8,9,10,11 =0. Then ↓col11→(11,14)→west→(10,14) exit. Reachable. Good.

But hold on, the bottom rows 10-14: row10 has walls at col0 (1), col5,6,7 (1), col15. row11 walls col0, col7, col15. row12 walls col0,1,2,col7,col15. row13 walls col0,col15. row14 walls col0..4, col14, col15. So bottom-right area cols 3-13 rows 10-14 is mostly open except the pillars. Exit at (10,14) reachable. Good.

Enemies reachable and visible: 
- E1(2,5): from player (7,1), the central pillar rows2-8 cols3,4? row2 cols? y2: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 → all open (no pillar in row2). Wait I defined y2 as all open? Let me recheck my level: y2: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 (all open). y3 has pillar cols3-6 and cols9-11. y4 pillar cols3, col5? y4: 1 0 0 1 1 1 1 0 0 1 1 1 0 0 0 1 → cols3,4,5,6 walls, col9,10,11 walls. So pillars at cols3-6 (rows3-7) and cols9-11 (rows3-5). 

E1 (2,5): col2 rows3-7? row3 col2=0, row4 col2=0, row5 col2=0, row6 col2=0,row7 col2=0. So (2,5) accessible via the top open area and col2 going down. Is (2,5) visible from (7,1)? There's a pillar cols3-6 rows3-7 between col2 and col7. So line from (7,1) to (2,5) would cross the pillar → not visible until player moves to the left side. Good, occlusion matters for E1. 
E2(9,8): visible from (7,1) straight down col7 to row8 then east—no walls blocking (col7 open rows1-9, row8 open). So E2 visible from start. That's okay.
E3(11,9): from (7,1), line goes southeast; the pillar cols9-11 rows3-5 might block or not depending. Likely partially occluded until player descends. Fine.

This level seems workable. Let me finalize it.

Let me write the level array precisely (16 cols x 16 rows):
Row0: [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1]
Row1: [1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1]
Row2: [1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1]
Row3: [1,0,0,1,1,1,1,0,0,1,1,1,0,0,0,1]
Row4: [1,0,0,1,0,0,1,0,0,1,0,1,0,0,0,1]
Row5: [1,0,0,1,0,0,1,0,0,0,0,0,0,0,0,1]
Row6: [1,0,0,1,1,1,1,0,0,0,0,0,0,0,0,1]
Row7: [1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1]
Row8: [1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1]
Row9: [1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1]
Row10:[1,0,0,0,0,1,1,1,0,0,0,0,0,0,0,1]
Row11:[1,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1]
Row12:[1,1,1,0,0,0,0,1,0,0,0,0,0,0,0,1]
Row13:[1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1]
Row14:[1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1] (exit at col10? but I need a frame). Let me keep the outer walls but allow exit cell. Row14: place exit at col10, and keep border walls except exit. Row14: [1,0,0,0,0,0,0,0,0,0,0(E),0,0,0,0,1] → col14=1 wall, col0=1. Exit col10? Let me set exit at col10,y14. Row14: 1 0 0 0 0 0 0 0 0 0 X 0 0 0 0 1. 
Row15:[1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1]

Wait but I earlier described an internal wall at row12 cols0-2 and col7. Let me re-examine my Row12: [1,1,1,0,0,0,0,1,0,0,0,0,0,0,0,1] → cols0,1,2 walls, col7 wall, col15 wall. That blocks col0-2 rows12 (so bottom-left area cols0-2 from row12 up is walled off—fine). And col7 wall at row12.

And there's a wall pillar around col7? Row10 col5,6,7 walls; Row11 col7 wall; Row12 col7 wall. So a wall column at col7 rows10-12 plus row10 col5,6. This forms an L. Does it block the central path? The main vertical corridor is col7 rows1-9 open. At row10, col7=1 (blocked going further south on col7). So from row9 col7, can't go straight south to exit. But can go south via col8-13 (open rows10-14). E.g., (7,9)→east→(11,9)→south→(11,14)→west→(10,14) exit. col11 open rows10-14? Row10 col11=0, row11 col11=0, row12 col11=0, row13 col11=0, row14 col11=0 ✓. Good. So exit reachable via col11. The L-pillar at col7 rows10-12 just forces the player to go around east. Fine, good for navigation/maziness.

But does the L-pillar box in the exit? Exit (10,14): neighbors col9,10,11 row14 and col10 row13. col9 row14=0, col11 row14=0, col10 row13=0. Open. Reachable. Good.

Now, is there a back route? It's fine.

Let me double check row10: [1,0,0,0,0,1,1,1,0,0,0,0,0,0,0,1] → col0=1,col5=1,col6=1,col7=1,col15=1. So at row10, cols5,6,7 are walls. col8 onwards open. Good, creates the L with col7 walls rows10-12 and cols5-6 row10.

Alright, level finalized. Let me also verify no enemy cell is a wall:
E1 (2,5): row5 col2=0 ✓
E2 (9,8): row8 col9=0 ✓
E3 (11,9): row9 col11=0 ✓
Exit (10,14): row14 col10=0 ✓ (map says 0, we treat as door when locked)
Player (7.5,1.5): cell (7,1)=0 ✓. Good.

Now let me also make sure the player can actually reach all enemies and the exit via walkable cells. The open area columns 0-15 rows1-9 mostly open except pillars cols3-6 rows3-6 and cols9-11 rows3-5. Let me verify the pillars don't trap E1 etc. Fine.

Let me now also double check row3: [1,0,0,1,1,1,1,0,0,1,1,1,0,0,0,1] → cols3,4,5,6 walls, cols9,10,11 walls. row4: cols3, col5? [1,0,0,1,0,0,1,0,0,1,0,1,0,0,0,1] → col3=1, col4=0,col5=0,col6=1, col9=1,col10=0,col11=1. So pillar cols3-6 not full; row4 col4,5 are open inside. row5: [1,0,0,1,0,0,1,0,0,0,0,0,0,0,0,1] col3=1,col6=1; col4,5 open. row6: [1,0,0,1,1,1,1,0,0,0,0,0,0,0,0,1] col3,4,5,6 walls. So the left pillar (cols3-6) spans rows3-6 fully (row3 cols3-6 wall, row4 col3+col6 wall but col4-5 open, row5 col3+col6 wall col4-5 open, row6 cols3-6 wall). So it's an open-ish room with walls around. Anyway navigable.

I won't over-verify; I'll test in browser.

Now let me write the code. This is a big file. Let me write it carefully.

Let me also consider: the player facing south initially; ArrowLeft should turn left. Let me make left turn CCW. With dir=(0,1) (south) and plane=(-p,0) (left?), let me define planeX = -p*tan? Hmm let me just set dirX=0,dirY=1, planeX=-0.6, planeY=0 (plane points left in world x). Then a left turn (CCW by angle a): newDirX = dirX*cos a - dirY*sin a = -sin a; newDirY = dirX*sin a + dirY*cos a = cos a. For small a>0: dirX<0 (west), dirY>0 (south) → facing southwest = turned left from south. ✓. plane rotates similarly. Good, ArrowLeft → a>0 → CCW → left. 

Let me define FOV: tan(FOV/2)=0.6 → FOV≈62°. Fine. planeX=-0.6, planeY=0 initially? Wait plane perpendicular to dir=(0,1). Perpendicular to (0,1) is (±1,0). plane should be (-tan,0) or (tan,0). I set planeX=-0.6, planeY=0 → perpendicular to (0,1) (dot=0). ✓. Length 0.6. Good.

But hold on, the determinant invDet = 1/(planeX*dirY - dirX*planeY) = 1/((-0.6)*1 - 0*0) = 1/(-0.6) = -1.667. That's used in sprite transform; fine (the transform handles it). 

Now let me write everything. Let me also clamp FOV-related and ensure dir stays unit (rotation preserves).

Let me write the code now. I'll produce the file.

Let me handle the shoot cooldown and weapon state: `player.shootTimer` (countdown). When Space pressed and shootTimer<=0, shoot, set shootTimer=0.2, weapon anim=0.3, muzzle flash.

Also maybe a fire sound via oscillator (optional, no network). Let me add a simple 'click' sound via Web Audio on shoot for feedback. Optional. Let me include a tiny beep. Actually to reduce risk, skip. Muzzle flash visual is enough "weapon feedback".

Let me also add a weapon bob when moving.

Let me write.

Let me define colors for UI: health bar red, etc.

Let me write the HTML now with inline everything.

I'll set canvas to fill; maybe width 960? Let me keep 800x600 display, render 400x300. Actually upscaled 2x of 400x300 = 800x600. Good.

Let me write.

I need to be careful with the Uint32Image data view timing: after creating imgData via createImageData (uninitialized), fill via u32, then putImageData. Each frame. The u32 view persists (same buffer) since I don't recreate imgData. Good. But putImageData with the same imgData each frame reusing buffer is fine.

Wait: createImageData returns a new ImageData with its own buffer each call. I'll call once and reuse. Good.

Let me also handle high-DPI? Skip (pixelated retro).

Let me write the file now.

For `texEnemy`, draw a face. Let me make it 64x64 magenta background, draw face:
- Fill magenta.
- Draw head: tan/oval (use a darker tan).
- Helmet: dark gray cap.
- Eyes black.
- Mouth/teeth.
I'll just draw circles/rects.

Let me make the enemy look like a wolfenstein guard: tan face, blue uniform, red? Hard. Let me do a simple green monster with red eyes. Whatever—just a visible sprite.

Let me make enemy tex:
- magenta bg
- face oval tan (center)
- two black eyes
- grin with teeth
- helmet/hair dark

I'll draw with ctx.

Let me code texture generators returning {data:Uint32Array, w}.

For converting canvas getImageData to Uint32: 
```
function canvasToU32(c){
  const ctx=c.getContext('2d');
  const id=ctx.getImageData(0,0,c.width,c.height);
  return {data:new Uint32Array(id.data.buffer), w:c.width};
}
```

Now `shade` operates on uint32 colors from textures (which include alpha in byte 3). When I shade, keep alpha. My shade function keeps `c&0xff000000` (alpha). Good.

But textures' alpha is 255 (opaque). Good.

Let me write the wall draw with shade factor and also a tiny detail: make vertical walls (side==0) slightly brighter, horizontal darker. Already.

Let me write floor texture: a dark stone tile with borders. Let me generate a 64x64 tile floor texture.

Let me also do ceiling texture (lighter). I'll make ceiling a solid-ish with a pattern.

Let me now also ensure performance of floor casting computing per pixel: 400*300=120k iterations with a few ops; okay.

Let me write the code. Time to commit.

Let me write helper `rand` and color utils.

Let me also handle input for restart button and R.

Let me write the final file. I'll include comments.

I must be careful that the code is syntactically correct. Let me write it methodically.

Let me define module-level constants:
```
const canvas=document.getElementById('c');
const ctx=canvas.getContext('2d');
ctx.imageSmoothingEnabled=false;
const W=400,H=300, SCALE=2;
canvas.width=W*SCALE; canvas.height=H*SCALE;
canvas.style.width=canvas.width+'px';
const off=document.createElement('canvas'); off.width=W; off.height=H;
const octx=off.getContext('2d');
const imgData=octx.createImageData(W,H);
const u32=new Uint32Array(imgData.data.buffer);
const zBuffer=new Float32Array(W);
const rayX=new Float32Array(W), rayY=new Float32Array(W);
```

Textures: texWall, texStone, texDoor, texFloor, texCeil, texEnemy.

Level array `level` (16x16), exit={x:10,y:14, unlocked:false}, enemies[].

Player object.

Functions: init, resetGame, castRay, update, render, sub-functions, input.

Let me write event listeners for keys and the restart button.

Let me write the loop with a fixed update step to keep movement smooth and game logic consistent: accumulate dt, step at 60Hz. Or just dt-based with requestAnimationFrame. Let me do dt-based but clamp large dt. Keep simple: use requestAnimationFrame timestamp.

Let me write.

Actually, for the enemies to "attack" with a clear rule and for movement to feel good, fixed timestep is nice but dt-based is fine. Let me do dt-based.

Let me write now.

Let me define speeds:
```
const PLAYER_SPEED=4.0; // cells per second
const ROT_SPEED=2.2; // radians per second
const ENEMY_SPEED=1.4;
const ENEMY_RANGE=2.0;
const ENEMY_CD=1.5; const ENEMY_DMG=15;
const SHOOT_CD=0.25; const WEAPON_RANGE=12;
const WEAPON_ANGLE=8*DEG; const DEG=Math.PI/180;
```

Health 100.

Let me write.

For the line-of-sight check in a helper using castRay with normalized dir:
```
function los(ax,ay,bx,by){
  let dx=bx-ax,dy=by-ay;
  let d=Math.hypot(dx,dy);
  if(d===0)return true;
  let r=castRay(ax,ay,dx/d,dy/d);
  return r.dist>=d*0.97; // wall beyond target
}
```
Use for enemy→player and player→enemy shooting.

But castRay uses the same DDA; if the ray origin is at an enemy position and direction toward player, perpWallDist returned is the perpendicular distance along that normalized direction. Comparing to d (actual distance). Since normalized direction, perpWallDist ≈ distance to wall along that direction. If >= d, no wall before target. Good. Use factor 0.97 tolerance.

Now shooting:
```
function playerShoot(){
  if(state!=='playing') return;
  if(lastShot && (now-lastShot<SHOOT_CD*1000)) return;
  lastShot=now;
  let fX=player.dx, fY=player.dy (unit forward);
  let best=null,bestD=Infinity;
  for(e of enemies){ if(!e.alive)continue;
    let dx=e.x-player.x,dy=e.y-player.y;
    let d=Math.hypot(dx,dy);
    if(d>WEAPON_RANGE)continue;
    let dot=dx*fX+dy*fY;
    if(dot<=0) continue; // not in front (angle >90)
    let cosA=dot/d; // since forward unit and (dx,dy) not unit: cos angle = dot/d
    if(cosA<Math.cos(WEAPON_ANGLE)) continue;
    if(!los(player.x,player.y,e.x,e.y)) continue;
    if(d<bestD){bestD=d;best=e;}
  }
  if(best){ best.health--; if(best.health<=0){best.alive=false; checkWin();} e=... }
  muzzleFlash=true; weaponAnim=...;
}
```
Wait dot = dx*fX+dy*fY where f unit, (dx,dy) vector to enemy (not unit). dot = d*cosA. So cosA = dot/d. Good. Condition cosA > cos(ANGLE). Good.

Muzzle flash and weapon anim for visual feedback.

checkWin: recompute enemiesAlive; if 0 → exit.unlocked=true; show "Door opened!" maybe briefly.

Win detection in update: if exit.unlocked and player within exit cell → state='won'.

Game over: if player.health<=0 → state='dead'.

Let me draw:
- crosshair: a small + at screen center (in display coords, at W*SCALE/2).
- weapon: pistol shape at bottom center.
- HUD: health bar (red), enemies count (skulls), ammo? (infinite), controls hint, round state messages.

Let me draw HUD in display coords (800x600) above the canvas using ctx after drawImage.

Restart button: DOM button, positioned. On show, click → resetGame.

Let me also make clicking the canvas request pointer lock? Skip.

Let me write the code. I'll write it all in the file now.

Let me also ensure the player can't move outside map (solid() returns true for out of bounds).

Let me also handle that the player's facing after turning; update dx,dy = dirX,dirY for shoot.

Now writing.

For the weapon (pistol) drawing, I'll define a function drawWeapon(ctx, sx, sy) that draws a simple pistol: a grip, a body, a barrel, a trigger guard. On shoot add flash. Let me draw with filled polygons via ctx.moveTo/lineTo or rectangles+rotation. Let me keep axis-aligned simple pistol shape translated to bottom center.

Weapon draw (in display coords, centered at X=400 (scale 800/2), Y=540):
- Barrel: a rectangle angled slightly.
Let me draw:
```
function drawWeapon(flash){
  const bx=400, by=520;
  ctx.save();
  ctx.translate(bx,by);
  // slight kick based on anim
  // body
  ctx.fillStyle='#444';
  // pistol body (handle + grip)
  ctx.beginPath();
  // shape...
  ctx.fillRect(...);
  // barrel
  ctx.fillStyle='#aaa';
  // muzzle flash
  if(flash){ ctx.fillStyle='#ff8800'; ... }
  ctx.restore();
}
```
I'll make a simple shape: a vertical grip and angled barrel. Let me draw a polygon.

Let me define weapon as a polygon (pistol silhouette) in local coords, fill dark gray, then a barrel highlight. On flash, draw orange lines at muzzle.

OK let me just write concrete drawing.

Let me define the pistol path (local coords, origin at grip bottom center?):
Points for a simple pistol:
- grip: from (0,0) down to (8,40) ... 
Honestly let me draw rectangles:
- Grip: rect at (-6,0)-(6,30) dark gray (the handle going down from body)... 

Let me set origin at where the weapon rests (bottom of grip at top of screen area). I'll draw:
- Body: a horizontal rectangle (the gun frame) centered, e.g., rect(x=-20,y=-10, w=40,h=20) dark gray.
- Barrel: rect(x=10,y=-6, w=30,h=12) slightly lighter gray, pointing right.
- Grip: rect(x=-8,y=10, w=16,h=18) dark gray, angled.
- Trigger guard: a U shape near body.

Since origin at center bottom and gun points... let me orient gun pointing right (along x) at bottom center. So body at bottom-center, barrel extends right-down? A pistol held at bottom center pointing toward center? Actually the gun should appear at the bottom of the screen, pointing "forward" (into the scene, i.e., down the screen). For a first-person view, the weapon is held below the view and points away (down screen). So I'll draw the pistol so its barrel points downward (toward bottom of screen) / slightly right. Let me just draw a pistol silhouette that points generally downward with the grip up. I'll position the weapon at X~center, Y~bottom-150.

Let me draw a recognizable pistol:
- Grip (top, near chin): a curved/rect shape.
- Barrel (bottom, pointing down): a long rectangle.
- Body connecting.

I'll just draw:
```
// weapon positioned with barrel pointing down
let wx = 400; let wy = 540;
// barrel: long dark rect pointing down
ctx.fillStyle='#3b3b3b';
ctx.fillRect(wx-4, wy-40, 8, 40); // barrel extends up from wy? pointing down means barrel tip at bottom (wy). Let me point down: barrel rect from wy to wy+40 (downwards), width 8.
```
Let me think: screen Y increases downward. Pointing forward = pointing down (toward bottom of screen). So barrel goes from wy (upper) down to wy+length. Let me set wy=470, barrel rect (wx-4, wy, 8, 50) dark. Grip above barrel: rect (wx-6, wy, 12, 30) dark. Body: rect (wx-10, wy+20, 20,14). Trigger guard: arc/rect near wy+10. Muzzle at wy+50 (bottom of barrel). Flash lines emanating from (wx, wy+50) downward.

This is rough but fine. Let me also add a weapon "sway" with movement: offset based on walk cycle.

OK enough planning; let me write the file and iterate.

Let me write it now. I'll keep the weapon drawing simple to avoid bugs.

Let me also include a small ammo/health pickup? No.

Let me write the file.

I'll write the entire HTML.

One more: the requirement "Display the controls." I'll show control hint in HUD.

Also "Show health and remaining enemy count". Yes HUD.

Let me write.

Let me also make sure to call resetGame at start and on restart, and set initial state 'playing' (or 'start' screen). Let me do a start screen for polish: gameState 'start' shows title + controls; clicking or pressing a key starts. But to ensure quick test, maybe start directly in 'playing'. Let me have a brief start screen with a big "PLAY" — but the task says test movement etc., so starting in playing is fine. Let me include a start screen for polish but also accept Enter/Space to start. Actually let me start in 'playing' directly to simplify testing, and show controls in HUD. I'll add a start overlay too but optional. Let me just start playing and show controls HUD always. The restart button also available. Keep simple: no separate start screen; game begins immediately. I'll add a small title at top.

Hmm, but "Provide Restart" — restart button. Fine.

Let me write the file.

Actually, let me include a title overlay at the very start ("Raycaster Maze Shooter — press ENTER to start") then gameplay. It's nice and shows instructions. I'll add it; quick to implement. On Enter/Space start. Then gameplay. On win/dead, show result overlay + Restart button. Also R key restarts. Let me include.

Let me now also make sure that during 'won' or 'dead' the game stops moving (update still runs but no movement? or stop loop?). I'll keep loop running; update checks state and skips movement when not 'playing'. Render shows overlay.

Let me write.

Let me code the crosshair and weapon only in playing state (and won/dead maybe hide). Fine.

Now, writing the file.

Let me write a fairly complete implementation.

For the floor texture generator: a dark tile with a lighter border and some noise. 
```
function makeFloorTex(size){
  const c=canvas(size); const t=c.getContext('2d');
  const base='#2b2b2b'; // dark gray
  t.fillStyle=base; t.fillRect(0,0,size,size);
  // tile borders: lighter lines
  t.fillStyle='#3a3a3a';
  const ts=size/4; // 4 tiles
  for(let i=0;i<=4;i++){ t.fillRect(i*ts-1,0,2,size); t.fillRect(0,i*ts-1,size,2); }
  // random speckles
  ...
}
```
Hmm let me make 2x2 tiles. Fine.

Ceiling: lighter gray with a darker border grid.

Enemy face: magenta bg, tan face oval, eyes, mouth.

Wall brick: red bricks.
Stone: gray with lighter veins.

Door: dark wood: a brown with horizontal planks and a handle.

Let me write generators.

Let me write the code now, final.

Let me also reconsider render resolution and scaling for crispness: render W=400,H=300 at canvas 800x600 (2x). imageSmoothingEnabled=false on ctx. Good.

Let me also set `off` canvas context imageSmoothing false (not needed since we putImageData).

Now, the u32 view: `new Uint32Array(imgData.data.buffer)`. imgData.data is Uint8ClampedArray of length 400*300*4. Its buffer is an ArrayBuffer of that size. Uint32Array view length = 400*300. Good.

Edge: On some browsers ArrayBuffer for ImageData isn't directly usable? It is; Uint8ClampedArray has .buffer. Good.

Let me write `setPixel` not needed; I'll write loops.

For clearing each frame: I won't explicitly clear; floor+ceiling fill all rows. But the center row (y=H/2=150) not covered by floor (denom=0 skipped) or ceiling (denom=0). Let me handle y=H/2 specially: fill with black or wall. Walls at x will fill their columns up to drawStart which may be at H/2 for distant walls. The center row between walls (if wall doesn't reach center) would be floor/ceiling meeting at horizon—let me fill center row with floor or ceiling. Let me just in floor casting, handle y=H/2 by setting rowDist large and drawing floor color (it'll be far floor/ceiling). Let me treat y=H/2 as floor (denom tiny → rowDist huge → very dark far floor). Actually division by zero. Let me set for y===H/2: rowDist = some large number (e.g., 999) and draw the floor/ceiling far color. Let me handle: denom = (y===H/2) ? 0.5 : (y<H/2? H/2-y : y-H/2); then rowDist = (H/2)/denom. This avoids div0. At y=H/2 denom=0.5 → rowDist=H (large) → far/dark. Good enough (it's the horizon). Actually H/2 with denom 0.5 gives rowDist=150 — large enough, dark. Fine.

Let me just set denom small. Good.

Alternatively skip center row; walls cover it usually. But if a column has no wall reaching center (distant wall, drawStart>H/2... hmm). Let me just fill center row with far floor. Use denom guard. Fine.

Let me now write.

Actually, simpler: skip floor casting entirely for the horizon row and instead fill it in clear with a gradient. Let me add a clear step: fill entire u32 with a ceiling color, then floor casts floor (over bottom), then ceil casts ceil (over top). That covers everything. But floor casting for ceiling? I'll do ceiling casting (top) and floor casting (bottom). The center row: ceiling cast covers y<H/2 (y=0..149), floor covers y>H/2 (151..299), y=150 unhandled → fill with black via initial clear. Let me initial-clear u32 to a dark color (e.g., 0xFF111111) to handle any gaps. Then floor/ceil overwrite. Good. So include `u32.fill(0xFF111111)` each frame. That's 120k fills—fine. Actually fill is fast.

Wait, but I want the clear to be black-ish; the sky. Let me clear to a dark blue ceiling-like (0xFF0a0a1a). Then draw ceiling/floor over (or leave sky at horizon). Let me just clear to dark and draw floor+ceil; sky not needed. Actually drawing a sky color above ceiling would be nicer. But ceiling texture covers top half anyway. The clear only matters for the horizon line and any tiny gaps. Let me clear to a mid gray; fine.

Hmm, but if I draw ceiling texture for top half, the clear color is irrelevant there. For y=H/2 center row only. Let me clear to ceiling far color. OK.

Let me finalize and write code. Enough planning.

Let me write the file now.

Let me write `update(deltaTime)`:

```
function update(dt){
  if(state==='start'){ return; }
  if(state==='dead'||state==='won'){ return; } // paused
  // movement
  let moved=false;
  if(keys['KeyW']){ let mx=player.dx*dt*PLAYER_SPEED, my=player.dy*dt*PLAYER_SPEED; movePlayer(mx,my); moved=true;}
  if(keys['KeyS']){ let mx=-player.dx*dt*PLAYER_SPEED, my=-player.dy*dt*PLAYER_SPEED; movePlayer(mx,my); moved=true;}
  if(keys['KeyA']){ // strafe left: move perpendicular left
    let sx=-player.dy, sy=player.dx; // left perpendicular (for dir=(0,1): left=(-1,0)? -dy=-1,dx=0 → (-1,0) west = left of south? South's left is east? Hmm.
    ...
  }
}
```
Wait: for dir=(0,1) (south), left perpendicular should be east (positive x)? When facing south, "left" is east. The left perpendicular vector = rotate dir 90° counterclockwise = (-1,0)? Rotating (0,1) CCW 90 = (-1,0) (west). That's right, not left. Hmm. Rotating (x,y) CCW 90° → (-y, x). For (0,1): (-1, 0) = west. CCW rotation of the direction vector gives the leftward direction in a standard math (x-right, y-up) coordinate. But our screen Y is down; the "left" of the player when facing south (down on screen) is east (rightward on screen). 

This is confusing. Let me define: the player's "right" vector = (dy, -dx)? For dir=(0,1) (south/down), right = (1,0)? (dy, -dx)=(1,0) → east (right on screen). Yes! When facing south (down), the screen-right is east = (1,0). And right vector in screen coords (x-right,y-down) for a facing dir (dx,dy) is (dy, -dx)? Let's verify: facing east (1,0): right should be south (0,1). (dy,-dx)=(0,-1)=north. That's wrong (should be south). Hmm.

Let me reconsider. In screen coords (x-right, y-down), a direction (dx,dy). The "right" perpendicular (pointing to the right side of the screen relative to facing) — if you face east (right), your right hand points down (south, +y). So right vector = (0,1) when facing (1,0). Formula (dy, -dx): (0,-1) = north. Wrong. Formula (-dy, dx): (0,1)=south. ✓. So right = (-dy, dx). And left = (dy, -dx). Let me verify facing south (0,1): right = (-1, 0)? (-dy,dx)=(-1,0)=west. But facing south (down screen), right hand points west? No! Facing down, right hand points left (west). Hmm, when facing down (south) in screen coords, right is west (left side of screen)? Let me think: face down (toward bottom). Extend right hand → points to the left (west, negative x). Yes! Facing south, right = west. ✓. So right=(-dy,dx)=(-1,0)=west ✓. left=(dy,-dx)=(1,0)=east ✓ (left hand points right/east). 

So strafe: KeyA (strafe left) → move left vector (dy,-dx). KeyD (strafe right) → move right vector (-dy, dx). 

But wait, does strafing "left" mean move to the player's left? A/D strafe — A left, D right. Yes player's left. So:
- KeyA: move along left = (dy, -dx) * speed.
- KeyD: move along right = (-dy, dx) * speed.

Let me double check with facing east (1,0): left=(dy,-dx)=(0,-1)=north (up). When facing east (right), strafing left means moving up (north). ✓. Good.

So:
```
if(keys.KeyA){ let lx=player.dy, ly=-player.dx; movePlayer(lx*speed, ly*speed); }
if(keys.KeyD){ let rx=-player.dy, ry=player.dx; movePlayer(rx*speed, ry*speed); }
```

Now rotation: ArrowLeft turn left (CCW). In screen coords (y-down), CCW turning is... when facing south (down), turning left means facing east (right). Facing east (right), turning left means facing north (up). So left turn in screen coords = clockwise rotation of the direction vector (because y-down flips handedness). The rotation formula for "turn left" (toward right on screen) when y+ is down: 
newDirX = dirX*cos + dirY*sin
newDirY = -dirX*sin + dirY*cos
Let me verify facing south (0,1), small sin>0,cos~1: newDirX = sin (>0, east), newDirY = cos (~1, south) → east-ish. ✓ left turn. 
ArrowRight (turn right): opposite:
newDirX = dirX*cos - dirY*sin
newDirY = dirX*sin + dirY*cos
Verify (0,1): newDirX=-sin (<0 west), newDirY=cos south → west-ish = right turn. ✓.

Let me use these. And rotate plane too:
ArrowLeft:
npx = planeX*cos + planeY*sin;
npy = -planeX*sin + planeY*cos;
ArrowRight:
npx = planeX*cos - planeY*sin;
npy = planeX*sin + planeY*cos;
With cos=cos(rotSpeed), sin=sin(rotSpeed). Good.

Let me define ROT_SPEED in rad/s ~ 2.0 (about 115°/s). Fine.

Now let me write the full code. I'll write to file.

Let me also add mouse aiming optional: if pointer is locked and moving, adjust aim. But optional. I'll add a simple mouse-look that's off by default (click to lock). Actually to reduce complexity and bug risk, I'll skip mouse aiming; shooting is forward. The task says mouse turning optional. I'll note it's not implemented (arrow keys turn). Good.

Let me write the file now. I'll write it all.

Let me write textures with randomness seeded to be deterministic? Not necessary; random is fine. But re-random each... I generate once at load. Good.

Let me write the enemy face more carefully so it's not terrible. I'll do:
- 64x64, magenta fill.
- face: ellipse tan (#c09870) centered (32,36) radii (18,22).
- helmet: dark gray (#333) top cap ellipse (32,22) radii (16,10).
- eyes: black ellipses at (26,34),(38,34) radii (3,5).
- eyebrows? skip.
- mouth: red/grin. A path for teeth: draw white teeth in mouth area with a line. Let me draw a grin: magenta→ draw a red open mouth (arc) with white teeth.
Let me draw teeth as white rects in a mouth region (y~44-50) and red below.

I'll keep it simple: eyes black, mouth a red curve, teeth white rects above it.

Let me write.

Now the weapon: pistol. Let me draw:
```
function drawWeapon(flash){
  const w=800,h=600;
  const cx=w/2; const cy=h-90; // grip top area? Let me place weapon center.
  ctx.save();
  ctx.translate(cx, cy);
  // bob based on walk: let bx = player.walkBob*... 
  // draw gun
  ctx.fillStyle='#222';
  // grip
  ctx.fillRect(-8,0,16,50);
  // body (angled, pointing down)
  ctx.fillRect(-10,30,20,16);
  // barrel (points down, longer)
  ctx.fillRect(-4,46,8,60);
  // trigger guard
  ctx.fillRect(-6,46,12,4);
  // muzzle at bottom
  if(flash){
    ctx.fillStyle='#ffaa00';
    ctx.beginPath(); ctx.moveTo(-4,106); ctx.lineTo(4,106); ctx.lineTo(0,112); ctx.closePath(); ctx.fill();
    // spark lines
    ctx.strokeStyle='#ff6600';
    ctx.beginPath();
    for(let i=0;i<5;i++){ let a=random; ctx.moveTo(0,106); ctx.lineTo(...); }
    ctx.stroke();
  }
  // side handle highlight
  ctx.fillStyle='#fff4';
  ctx.fillRect(...);
  ctx.restore();
}
```
Rough but okay. Let me position: weapon origin at (cx, cy=h-120). Barrel extends downward from cy. Let me make the gun occupy bottom of screen. I'll tune by testing.

Let me place weapon at X = 400 (center), with its "hold" point around Y=490, barrel reaching ~Y=580. On flash, flash at ~Y=580.

Let me just code and visually check, adjusting.

I think I've planned enough. Let me write the file. It'll be long. Let me write it.

Let me also remember to display controls text and health/enemy count in the HUD overlaid on the 3D (drawn on ctx at 800x600).

Let me write the code.

I'll write to /tmp/job-sb0fp7/index.html. cwd is that. Let me create it.

After writing, I'll open in the browser tool, inspect, move around, test walls, shoot, restart. Then fix issues.

Let me write now.

Let me carefully write the floor casting using precomputed rayX/rayY and the rowDist. Actually in floor casting I need rayDir per column = rayX[x],rayY[x]. Precomputed. Good. rowDist per row. For each row, for each x: fx=px+rowDist*rayX[x], fy=py+rowDist*rayY[x]. Then sample floor tex. 120k iterations. OK.

Actually I realize the floor casting per pixel with Math.floor and texture index may be a bit slow but fine for 400x300. Let me maybe reduce to 320x240 to be safe on slower machines, scale 2x → 640x480. But display 800x600 with 320x240 scaled by 2.5 would be non-integer scaling (blurry unless pixelated; 320*2.5 not pixel aligned). Pixelated scaling needs integer scale factor for crisp. 400*2=800 (integer ✓). 320*2.5 no. Let me keep 400x300 → 800x600 (2x integer). Good.

Let me also maybe skip ceiling texture (use solid color) to save perf? Ceiling is only top 150 rows. Let me do ceiling texture too for style but cheap. Fine.

Now write.

Let me write the file content.

I'll be thorough.

Let me define the level as `LEVEL` constant and copy into `level` at reset (to restore). Since I mutate exit.unlocked and enemies, not level grid (door handled dynamically). Good. Walls never break. So level static. Enemies reset via resetEnemies. Good.

Let me write.

Actually, I want to double-check the DDA castRay and rendering handle the case rdx or rdy ~0 (looking straight along axis). With dir=(0,1) initially, rdy at center x = 1 (cameraX=0 → rayDirY=1

Let me build a raycasting maze shooter in a single index.html file. I need to be quick about this. Let me write the complete file.

Key requirements:
- Raycasting with textured walls
- Procedural textures
- W/S forward/back, A/D strafe, arrows turn, Space shoot
- Show controls
- Wall collision
- Small level with exit + 3 enemies
- Enemies occluded by walls, shots can't go through walls
- Player health
- Enemies damage player under clear attack rule
- Show health and enemy count
- Zero health = Game Over
- Defeat all enemies unlocks exit
- Reach exit = win
- Restart button

Let me write this all in one file.