Let me build a raycasting maze shooter. I'll create a single index.html with everything inline.

Key features:
- Raycasting rendering on canvas
- Grid maze with textured walls (procedural textures)
- WASD movement, arrow keys + mouse turning
- Enemies you can shoot
- Wolfenstein 3D style

Let me write this carefully. I'll generate procedural textures on offscreen canvases.

Let me plan the code:

1. Maze grid (2D array) - walls vs floor
2. Player state: x, y, dir angle
3. Raycasting: DDA algorithm to find wall hits, compute distance, draw textured vertical strips
4. Textures: generate a few procedural textures (brick, stone, etc.) as ImageData arrays
5. Floor/ceiling casting (optional, can do simple colors or textured)
6. Sprites/enemies: billboard rendering with depth sorting
7. Shooting: raycast forward, check enemy hit
8. HUD: weapon sprite at bottom, health, ammo

Let me write a solid implementation.

I'll keep it performant. Use ImageData for textures (64x64). For walls, sample texture column based on hit. For performance, render wall strips via per-pixel or via fillRect with computed color. Actually for textured walls the classic approach is per-pixel column draw. Let me do per-column using a 1-pixel wide image scaled — but scaling a canvas column is fine. Actually better to manipulate ImageData directly for the whole screen for performance.

Let me do: render to an ImageData buffer pixel by pixel for walls (per column, per row pixel). That's screen_w * column height pixels. For 640x400 that's fine.

Actually simpler and fast: for each column, compute wall height, then for each screen row in that wall slice, sample texture and set pixel. Let me build a Uint8ClampedArray buffer.

Let me do floor/ceiling as solid colors or gradient for simplicity, or do floor casting too. I'll do a simple gradient ceiling and floor casting for nicer look. Actually let me do full floor casting with textures — it's a bit more work but looks great. Hmm, performance. Let me do textured ceiling/floor too but it might be slow. I'll do a simpler approach: solid ceiling color, solid floor color with the wall textures being the main feature. Actually, let me do floor/ceiling casting with textures — it gives the authentic Wolfenstein look. I'll optimize.

Let me think about resolution. I'll render at a lower internal resolution (like 320x200) and scale up with canvas image smoothing off for that retro pixelated look. That's both performant and stylish. 

Plan:
- Internal canvas: 480x300 or so. Actually let me use a buffer canvas at low res and scale to display canvas.
- Use offscreen buffer ImageData.

Let me just do one canvas at a moderate resolution and write ImageData.

I'll set internal resolution W=480, H=300. Display canvas can be larger via CSS scaling with image-rendering: pixelated.

Let me write the code.

Maze: 16x16 grid, 1 = wall. Use different texture ids.

Textures: generate 4 textures (brick, stone, moss, door). 64x64 each stored as Uint32Array or Uint8 arrays.

Let me generate:
- tex0: brick (red bricks with mortar)
- tex1: stone (gray blocks)
- tex2: tech/blue panel
- tex3: mossy green

Enemies: array of {x, y, type, health, alive, sprite}. Sprite as procedural texture (enemy image) stored as canvas for drawing scaled. Billboard: compute distance, screen position, size, draw with drawImage. But drawing enemies on top of the ImageData wall buffer — I need to either draw enemies after putting wall ImageData, or composite. I'll put wall ImageData first, then draw enemies and HUD with regular canvas 2D drawImage/fill. That's fine and fast.

But sprite occlusion by walls: classic technique uses a zbuffer per column. I'll store per-column wall distance, then when drawing sprite, clip per column where sprite depth < zbuffer. Simpler: for each sprite column, check zbuffer. I'll implement that with clip rectangles.

Actually a simple approach: draw sprite with drawImage but check zbuffer per column using clipping. I'll do per-column drawing via drawImage of 1px wide slices. That works.

Weapon: a gun sprite at bottom-center, with bob animation and firing flash. Draw procedurally.

Let me write everything now.

Enemies AI: move toward player slowly, attack when close (reduce player health). Player can shoot them.

Let me also add muzzle flash, hit detection, particles maybe.

Let me write the file.

I'll structure JS:
- Constants
- Texture generation
- Map
- Input handling
- Player
- Raycast render (walls + floor + ceiling)
- Sprite rendering
- HUD
- Game loop

Let me write it.

For textures I'll create offscreen canvases and also keep ImageData for wall sampling. For sprites I'll keep canvases for drawImage.

Let me generate texture as Uint8ClampedArray of size 64*64*4, and also build a canvas from it for sprite use.

Wall sampling: texture coordinate u = wallX fractional, v = y within slice.

Let me code the renderer carefully.

Raycasting DDA:
```
for x in 0..W:
  cameraX = 2*x/W - 1
  rayDirX = dirX + planeX*cameraX
  rayDirY = dirY + planeY*cameraX
  mapX, mapY = floor(playerX), floor(playerY)
  deltaDistX = abs(1/rayDirX)
  deltaDistY = abs(1/rayDirY)
  ... step and sideDist
  DDA loop until hit
  perpWallDist
  lineHeight = H / perpWallDist
  drawStart, drawEnd
  wallX computation
  texX = wallX * texWidth
  for y in drawStart..drawEnd: texY = ...; sample; set pixel
  zbuffer[x] = perpWallDist
```

Floor/ceiling: for y below drawEnd to H, and above drawStart to 0, do floor casting. Let me do the standard floor casting:
```
for y in (drawEnd+1 .. H):
  rowDistance = posZ / (y - H/2)  where posZ = 0.5*H
  ... floorX, floorY step
  sample floor texture, ceiling texture
```
This is per pixel per column — combined with walls. Doing floor casting for every column is expensive but at 480x300 ~ 144k pixels, fine.

Actually the standard Lodev floor casting iterates per screen row (y) computing leftmost ray, then stepping across x. That's more efficient. Let me do that approach for floor/ceiling after walls. But walls already wrote pixels in the middle band. I'll just overwrite floor/ceiling regions. Simpler: I'll compute walls into buffer, then do floor/ceiling in a separate pass writing to the top/bottom regions. Let me do per-row floor casting.

Let me just do it per-row for floor and ceiling:

```
for y in 0..H/2:  // ceiling
  rowDistance = (0.5*H) / (H/2 - y)  // for ceiling top
  ...
```
Hmm, let me follow Lodev's exactly:

```
// floor and ceiling
for(int y = H/2 + 1; y < H; y++) {
  rayDir for leftmost (x=0) and rightmost (x=W) ray
  p = y - H/2
  posZ = 0.5 * H
  rowDistance = posZ / p
  floorStepX = rowDistance * (rayDirX1 - rayDirX0) / W
  floorStepY = ...
  floorX = posX + rowDistance * rayDirX0
  floorY = posY + rowDistance * rayDirY0
  for x in 0..W:
    cellX = floor(floorX), cellY = floor(floorY)
    tx = floorTexWidth * (floorX - cellX) ...
    sample floor texture -> buffer[y*W+x]
    sample ceiling -> buffer[(H-y-1)*W + x]  (mirror) or compute separately
    floorX += floorStepX; floorY += floorStepY
}
```

This gives nice textured floor and ceiling. I'll do this. It overwrites the floor/ceiling pixels (the wall pass only wrote the wall band, leaving top/bottom as whatever — I'll init buffer to 0 then walls write band, then floor/ceiling pass writes the rest). Order: do walls first (writes band + zbuffer), then floor/ceiling writes top and bottom. Good.

But wait, the floor casting uses rayDir which depends on plane. Fine.

Let me make floor and ceiling use textures too. I'll make a floor texture and ceiling texture.

Let me now actually write the code. I'll keep it reasonably complete.

For the gun: draw with canvas paths.

For enemies sprites: generate canvas images. A simple imp-like figure: brown body, red eyes. Let me draw procedurally onto a canvas.

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

I need to be careful with performance of per-pixel JS. 480x300 = 144000 pixels, written once per frame for floor/ceiling/walls. At 60fps that's 8.6M pixel writes/sec — should be OK in modern JS.

Let me reduce internal resolution to 320x200 for safety and pixelated retro look. Actually 480x300 looks better. Let me use 400x250. I'll go 480x270 (16:9). Let me use W=480, H=270.

Hmm floor/ceiling pass writes full W*H/2 each = lots. Fine.

Let me write.

For sprite rendering with zbuffer: 
```
spriteX = sprite.x - posX
spriteY = sprite.y - posY
invDet = 1/(planeX*dirY - dirX*planeY)
transformX = invDet*(dirY*spriteX - dirX*spriteY)
transformY = invDet*(-planeY*spriteX + planeX*spriteY)
spriteScreenX = (W/2)*(1 + transformX/transformY)
spriteHeight = abs(H/transformY)
drawStartY, drawEndY
spriteWidth = abs(H/transformY)
drawStartX, drawEndX
for stripe in drawStartX..drawEndX:
  if transformY>0 and stripe in 0..W and transformY < zbuffer[stripe]:
    draw 1px-wide slice of sprite image at (stripe, drawStartY)
```

Use drawImage(spriteCanvas, srcX, 0, 1, spriteH, stripe, drawStartY, 1, spriteHeight). That's fast.

Let me implement.

Enemies: list with x,y,health,alive, and a state (idle/approaching). Move toward player if line of sight. Simple.

Shooting: on click/space, raycast along dir, find closest enemy within angle. I'll do: for each enemy, compute angle to enemy relative to player dir; if within small threshold and not behind wall and within range, hit closest. Better: do a hitscan — cast a ray, step through map, at each step check enemy proximity. Simpler: compute perp distance of enemy from the aim ray. Let me do: for each alive enemy, compute vector to enemy, project onto dir, get forward distance and perpendicular. If perpendicular < enemy radius and forward > 0 and no wall between closer, it's a hit. Pick closest.

Let me implement a simple version: pick the enemy minimizing perpendicular distance among those with forward>0 and within range, check wall occlusion via DDA to enemy distance.

Good enough.

Let me write the full file now. This will be long.

I'll include:
- Start overlay with instructions
- Health, ammo, score
- Enemies respawn / level? Keep simple: a maze with several enemies; kill all to win; restart.
- Minimap in corner maybe.

Let me write.

I'll generate enemy sprite on canvas: a demon-like creature.

Let me code textures generation functions returning {data: Uint8ClampedArray, canvas}.

Actually for walls I sample from Uint8ClampedArray directly (fast). For sprites I use canvas drawImage. I'll generate wall textures as Uint8ClampedArray and also could be sampled. For floor/ceiling same.

Let me write a helper makeTexture(size, drawFn) that creates a canvas, draws with 2D context, then extracts ImageData into Uint8ClampedArray and returns both.

For sampling I need width. I'll fix texSize=64.

Sampling function: idx = (ty*64 + tx)*4.

Let me write it all.

For performance, store textures in a single typed array per texture. I'll precompute.

Alright, writing now. Let me be thorough but get it done.

I'll add a simple lighting/distance shading: multiply color by a factor based on distance and side (darken y-sides). Nice Wolfenstein feel.

Shading: 
```
shade = 1/(1 + dist*0.04) or fixed steps
if side==1: shade *= 0.7
color = tex * shade
```

Let me implement a fast shade by quantizing.

For floor casting shading by row distance similarly.

OK writing.

Let me make the maze interesting with multiple texture types. Map:
```
1,1,1,1,...
1 = brick, 2=stone, 3=moss, 4=door(could be solid)
```
I'll handcraft a 24x24 maze or generate. Let me handcraft a decent maze. I'll write a string map.

Let me design a 24x24 maze. Use characters:
'#' wall (brick), '=' stone, '%' moss, '.' floor.

I'll make it a maze with rooms. Let me just make a reasonably structured maze.

Let me write a 24x24 grid. I'll generate via a simple pattern. Actually handcrafting 24x24 is tedious; let me do a procedural maze generator in JS (recursive backtracker) so it's a fresh maze each load. That's nice and ensures connectivity. Then assign texture types by region/random.

Let me implement a maze generator:
- grid of cells, walls between.
- Standard: grid (2n+1)x(2n+1), odd = wall, carve.
- Recursive backtracker.

That gives a perfect maze (single path, no rooms). For a shooter, open rooms are better. I'll do maze + knock down some walls randomly to create loops/open areas. Good.

Let me do grid 21x21 cells carving on odd indices, then randomly remove ~15% of interior walls.

Map size 21x21, player starts at (1,1). Enemies placed at random floor cells far from player.

Texture assignment: based on a hash of cell or random — pick from [brick, stone, moss]. I'll just random per wall cell for variety, or by region. Random is fine.

Let me code generator.

Alright, time to write the whole file. Let me go.

I'll write the file now.

Let me verify it works by checking for syntax errors. Let me do a quick node syntax check by extracting the script. Actually let me just review the code for bugs.

I noticed a bug in the movement code - I have a messy KeyA handler that adds to mvX twice with commented weird logic. Let me fix the strafe logic to be clean.

Let me re-read the update function strafe part:

```
if(keys['KeyA']){mvX+=(-d.y)*speed*0.8; mvX+=0;}
if(keys['KeyA']){ const p=planeVec(); mvX-=p.x*speed*0.9/ (planeLen/0.66); mvY-=p.y*speed*0.9/(planeLen/0.66);}
```

This is buggy/duplicated. Let me clean it up. The plane vector already includes planeLen scaling. For strafing, moving along the plane direction. p = planeVec() = (-sin*planeLen, cos*planeLen). To strafe right, move along +plane (normalized). Let me just use unit perpendicular: (-d.y, d.x) for right, (d.y, -d.x) for left.

Right (D): perpendicular = (-d.y, d.x)? Let's see: dir=(cos,sin). Right-hand perpendicular (rotated -90) = (sin, -cos)? The camera plane in Lodev for dir along x... Let me just compute: forward d. Right vector = rotate d by -90°: (d.y, -d.x). Left = (-d.y, d.x).

Actually for strafing left/right it doesn't matter much which is which as long as consistent. Let me set:
- A (strafe left): leftVec = (d.y, -d.x) ... hmm let me just pick: right = (d.y, -d.x)? 

dir = (cos θ, sin θ). Rotating forward by +90° (CCW) gives (-sin θ, cos θ) = (-d.y, d.x). That's the "left" if y is down... whatever. Let me just make A and D opposite and test direction by logic doesn't matter much. I'll use:

perp = (-d.y, d.x)  // rotate +90
D (strafe right) -> +perp, A (strafe left) -> -perp.

Let me rewrite cleanly.

Also planeVec uses planeLen=0.66. In render plane is used for FOV. Fine.

Let me fix the movement.

Now let me check the wall pixel writing code - I have a bug there too:

```
const r=px[((y*RW+x)*4)]=tex[ti]*ff;
const gr=px[((y*RW+x)*4)+1]=tex[ti+1]*ff;
const b=px[((y*RW+x)*4)+2]=tex[ti+2]*ff;
```

This is wrong - `const r = px[...] = ...` is a chained assignment that works but is weird. Actually `const r = px[X]=val` — the assignment px[X]=val returns val, then r=val. That's fine actually. But it's ugly. It works. Let me leave it but simplify to avoid confusion. Actually it works fine. Let me keep.

Wait, there's a subtle issue: floor/ceiling pass writes to ALL rows including wall band rows (y between start/end). The floor pass iterates y from 0..RH and writes floor for y>RH/2 and ceiling for the mirrored y. For wall band rows, it will overwrite the wall pixels with floor/ceiling! That's a bug.

Let me check: floor pass:
```
for y in 0..RH:
  isFloor = y>RH/2
  p = isFloor ? y-RH/2 : RH/2-y
  ...
  for x: write floor pixel at (y,x) if isFloor, else write ceiling at (RH-1-y, x)
```

So for floor rows (y>RH/2), it writes floor at row y. For ceiling rows it writes at mirrored row RH-1-y. This covers ALL floor rows (y>RH/2) and ALL ceiling rows (RH-1-y < RH/2). So it overwrites the wall band in floor and ceiling areas... but the wall band pixels are at specific y between drawStart and drawEnd per column. The floor pass writes floor color to ALL y>RH/2 regardless of whether a wall is there. So a wall that extends below RH/2 (tall near wall) would get its lower portion overwritten by floor texture. That's a real bug.

The classic approach: floor casting only writes where there's no wall — i.e., for y > drawEnd for that column. The standard Lodev floor casting writes floor for y from drawEnd+1 to H, and ceiling for y from 0 to drawStart-1. So it's per-column based on drawEnd/drawStart. But Lodev's floor casting is per-row for efficiency and assumes you only fill the non-wall region... Actually no. Lodev's floor casting fills the entire lower half and upper half with floor/ceiling, and the walls are drawn ON TOP after? No, walls drawn before, then floor/ceiling fills non-wall area. But if floor fills entire lower half it overwrites wall bottoms.

Wait in Lodev's tutorial the wall pass writes the wall column from drawStart to drawEnd. Then floor casting: for y from drawEnd+1 (per column) ... but the row-based version uses a fixed per-row. Let me re-check Lodev's actual code.

Lodev's floor casting (the row version):
```
for(int y = H / 2 + 1; y < H; y++)  // only lower half floor
{
  ...
  for(int x = 0; x < W; x++) { ... floorBuffer[y][x] = ...; }
}
```
And it only fills y from H/2+1 to H. But walls extend below H/2 for close walls (drawEnd > H/2). So those wall pixels below H/2 would be overwritten!

Hmm, actually in Lodev's the order is: floor/ceiling first (fills entire top/bottom halves), then walls drawn on top. So walls overwrite floor. Let me reorder: do floor/ceiling FIRST, then walls on top. That way walls always win in the band, floor shows where wall doesn't reach.

But my floor pass writes to row y for floor and row RH-1-y for ceiling. If I do floor first then walls, walls overwrite the band. The floor rows y>RH/2 get floor; wall band within those rows gets overwritten by wall pass. 

So I just need to reorder: do floor/ceiling pass BEFORE walls. But zbuffer needs wall computed for sprites regardless of order — sprites are drawn after via drawImage on the main canvas (not buffer), so zbuffer just needs values; fine.

But wait, if I do floor first then walls, the wall pass writes to px buffer at wall band. Good. Then putImageData. Then sprites drawn on canvas. 

Currently order is walls THEN floor. Let me swap to floor THEN walls.

Actually let me reconsider: my floor pass writes ceiling at row (RH-1-y) where y<RH/2, i.e., for y<RH/2 the ceiling target row = RH-1-y which is >RH/2... that's wrong! Ceiling should be in the TOP half.

Let me re-examine. The loop `for y in 0..RH`. For y<RH/2 (upper half), isFloor=false, p=RH/2-y (distance to horizon). Then it writes ceiling at row (RH-1-y). RH-1-y for y<RH/2 gives rows > RH/2... that's the bottom half. That's BACKWARDS. Ceiling should be in top half.

I think I confused myself. Let me rewrite the floor/ceiling pass correctly:

- Ceiling occupies rows 0..RH/2 (top half). For a given top row y (0..RH/2-1), p = RH/2 - y (distance from horizon), rowDist = 0.5*RH/p. Sample ceiling.
- Floor occupies rows RH/2..RH-1. For row y, p = y - RH/2, rowDist = 0.5*RH/p. Sample floor.

So I should iterate y over top half for ceiling and bottom half for floor, writing to row y directly. Let me rewrite cleanly. I'll do it as two loops or one loop with correct targeting.

Let me rewrite the floor/ceiling section. And do it BEFORE walls so walls overwrite the band.

Actually, if I write floor to row y (bottom half) directly and ceiling to row y (top half) directly, and walls overwrite the band, then ordering: floor/ceiling first, walls second. Good.

Let me fix both issues: the targeting and the ordering.

Let me find the floor/ceiling section to edit.

Now let me restructure the render to: floor/ceiling FIRST, then walls, so walls overwrite the band. I'll replace the floor/ceiling block and move it. Actually simpler: keep wall pass first but make floor pass skip rows that are within the wall band per column. But that requires per-column drawStart/drawEnd which I have stored... I'd need arrays. Simpler approach: do floor/ceiling pass first (fill entire top with ceiling, entire bottom with floor), then wall pass overwrites the wall band. 

But I also need zbuffer computed in wall pass for sprites — that's independent. Let me just reorder: move floor/ceiling pass to before the wall pass.

Let me replace the whole floor/ceiling block with a corrected version, and relocate. Actually the cleanest fix without moving large blocks: change the ceiling targeting to write to top rows and floor to bottom rows directly, and reorder by running floor pass before walls.

The wall pass loop starts at `for(let x=0;x<RW;x++){` after the render function begins. The floor pass is after the wall pass loop closes `}`. 

I'll restructure: I'll wrap both in proper order. Let me do a targeted edit: replace the floor/ceiling block (lines ~430-456) with a corrected version that writes ceiling to top half and floor to bottom half. Then to handle ordering, change the wall pass to NOT clear (it overwrites band, that's fine if floor first). 

But the wall pass is currently BEFORE floor. If floor writes whole halves after walls, it overwrites wall band. So I must move floor before walls. 

Let me just move the floor pass to the start of render. I'll cut the floor block from its current location and paste it at the top of render (after computing dir/plane). Let me do this with edits:

1. Remove the floor block from its current location.
2. Insert corrected floor block right after `const dir=dirVec()...` line.

Let me do it. First, read the render start.

Wait, there's an issue with the ceiling targeting. For ceiling (isFloor=false), rowY = half - p. When y goes from 0 to half-1, p = half - y, so rowY = half - (half-y) = y. Good, so ceiling writes to row y directly (top half). That's correct! rowY = y for ceiling. 

For floor (isFloor=true), rowY = y. Wait I set `const rowY = isFloor ? y : (half - p);`. For floor rowY=y (bottom half). For ceiling rowY = half - p = half - (half - y) = y. So both just write to row y! So rowY is just y always. The mirroring was unnecessary. Good — both write to row y, ceiling in top half, floor in bottom half. 

Now let me verify there are no remaining issues. Let me also double check the wall pixel writing line that uses chained assignment - it works but let me simplify for clarity/safety. Actually `const r=px[...]=tex[ti]*ff;` — this assigns to px and to r. Works. Fine.

Now let me do a syntax check by running node to parse the HTML's script. Let me extract and check. Easier: use node to check the whole file isn't possible since it's HTML. Let me just grep for obvious issues and test in a headless way. 

Actually, I can validate JS syntax by extracting the script block and running `node --check`. Let me do that.

Syntax is OK. Now let me actually run it in a headless browser to check for runtime errors. I could use a quick test with puppeteer if available, but that may not be installed. Let me just do a logic review instead, and maybe check a few things.

Actually let me try to open it with a simple check. I don't have a browser. Let me just carefully review the remaining code for runtime bugs.

Let me re-read the full file to check the remaining sections (sprites, HUD, update, etc.).

One issue: the hurt tint rectangle. When an enemy is hurt, I draw a red overlay using source-atop, but that composite op only affects already-drawn pixels in the current drawing — but since I draw per-stripe with drawImage, and the buffer is already blitted... actually the hurt tint is drawn on the main canvas (ctx) AFTER the buffer blit. Wait no — the sprite drawing (drawImage with stripes) happens on `ctx` after `bctx.putImageData` and before the final `ctx.drawImage(buf,...)`. 

Wait, the order in render():
1. fill px buffer (floor/ceiling/walls)
2. bctx.putImageData(img) -> buf canvas
3. draw sprites on... `ctx`? Let me check. The sprite loop uses `ctx.drawImage(spr,...)`. But `ctx` is the main canvas context, and buf hasn't been blitted to ctx yet! So sprites draw to ctx first, then `ctx.drawImage(buf,...)` blits the wall/floor buffer ON TOP, covering the sprites! That's a bug — sprites would be hidden behind the wall buffer.

I need to draw sprites AFTER blitting the buffer to ctx. Let me move the sprite drawing after `ctx.drawImage(buf,...)`. 

Let me reorganize: 
1. compute px (floor/ceiling/walls) 
2. putImageData to buf
3. ctx.drawImage(buf) to main canvas
4. draw sprites on ctx (with zbuffer)
5. drawHUD

Currently sprite drawing is before the blit. Let me move the blit before sprites.

The blit line: `ctx.imageSmoothingEnabled=false; ctx.drawImage(buf,0,0,RW,RH,0,0,canvas.width,canvas.height);` is currently at the end of render() after sprites. I need it before sprites. Let me move the sprite section to after the blit.

Let me edit: move the blit up to right after `bctx.putImageData(img,0,0);`, and remove the blit at the end.

Actually simplest: change the line `bctx.putImageData(img,0,0);` to also immediately blit, then sprites draw on top. Let me restructure.

Current:
```
  bctx.putImageData(img,0,0);
  // ---- sprites ... ----
  ... sprites loop drawing to ctx ...
  ctx.imageSmoothingEnabled=false;
  ctx.drawImage(buf,0,0,RW,RH,0,0,canvas.width,canvas.height);
}
```

Need:
```
  bctx.putImageData(img,0,0);
  ctx.imageSmoothingEnabled=false;
  ctx.drawImage(buf,0,0,RW,RH,0,0,canvas.width,canvas.height);
  // ---- sprites ... ----
  ... sprites loop ...
}
```

But sprites use screen coords based on RW/RH internal resolution but drawn on main canvas which is scaled (canvas.width x canvas.height). The sprite coords (dStartX, dStartY, h, w) are in RW/RH pixel space, not scaled to main canvas. So if I draw sprites on the main canvas (which is larger, e.g. window size), the sprite would be tiny at internal-res coordinates positioned in top-left corner area. 

So sprites need scaling too. The cleanest fix: draw sprites onto `buf` (the internal-res canvas) using bctx, THEN blit buf to ctx. That way everything is in RW/RH coordinate space and scales uniformly. But bctx is a 2D context on buf — drawImage works there. And zbuffer is in RW space. 

So: draw sprites on bctx (internal res), then blit buf to ctx. But the hurt tint uses ctx — change to bctx.

Wait but putImageData replaces all of buf. If I putImageData then draw sprites on bctx, the sprites draw on top of the pixel data. Good. Then blit. 

But putImageData ignores alpha blending — it just sets pixels. drawImage after that composites normally. Good.

So the fix: after `bctx.putImageData(img,0,0)`, draw sprites on `bctx` (not ctx), then do the final blit. Let me change all `ctx.drawImage(spr,...)` in the sprite section to `bctx.drawImage`, and the hurt tint fillRect to bctx, and keep the blit at the end.

Actually there's also the muzzle flash and HUD which use ctx (main canvas, scaled coords) — those are fine drawn after blit.

Let me make the sprite section use bctx. Let me edit.

Also note: sprite stripes use ctx.globalCompositeOperation for hurt tint — need bctx.

Let me rewrite the sprite section to use bctx.

Now let me verify the remaining part of the file (update loop, end screen). Let me read from offset 586.

Variable name collision: in `update()`, I declared `const px = -d.y, py = d.x;` but `px` is also the global `px` (the ImageData array) and `planeLen`... wait there's a global `px` (img.data). Declaring `const px` in update shadows the global within update scope — that's fine for update, but it could be confusing. Actually it's fine since it's block scoped. But let me rename to avoid shadowing the important global to prevent confusion. Let me rename to `strafeX/strafeY`. Actually it works but let me rename for safety/cleanliness.

Also `tryMove` function: I declared `const cx = isWall(...)` and `const cy = isWall(...)` but then never use cx, cy. The actual checks are inline. The cx/cy are dead. Harmless. But the collision logic: it checks the new x position with a margin in x, keeping y, and separately new y with margin in y keeping x. That's standard "slide" collision. Good. The cx/cy dead vars are fine.

Let me rename the `px`/`py` locals to avoid shadowing global px. This is important because if any code in update references the global px it'd get the local — but nothing in update uses global px. Still, clean it.

Let me edit.

Now let me re-validate syntax and also try to actually run it in a headless browser to catch runtime errors. Let me check if puppeteer/playwright is available.

No browser available. Let me try to set up a quick jsdom-based test to at least catch obvious runtime errors in non-canvas code. But canvas requires a real canvas implementation. jsdom doesn't have canvas. puppeteer not available.

Let me do a thorough manual review of potential runtime errors:

1. `buf` is created as canvas with getContext('2d'). createImageData works.
2. FLOortex, CEILtex — typo "FLOortex" (capitalization) but consistent usage? I used `FLOortex.data` in floor pass. Defined as `const FLOortex = stoneFloor('#3a3028');`. Consistent. Fine.
3. `WALLTEX` indexing: wallTexAt returns `MAP.tex[idx] % WALLTEX.length`. MAP.tex values 0..4, %4 gives 0..3. But doors set tex=4, 4%4=0 → brick. So doors render as brick, not the door texture. Minor. Actually I'd like doors to show. WALLTEX has 5 textures (indices 0..4 including door). But wallTexAt does %WALLTEX.length (=5) so 4 stays 4. Wait WALLTEX.length is 5 (pushed 5). So tex%5. tex values 0..4. So door (4) → texture 4 = door. Good. Wait I wrote `% WALLTEX.length` which is 5. Good, door shows. 

But in maze gen, tex[i] = (Math.random()*4)|0 → 0..3 for normal walls, and door set to 4. So all good.

4. In render wall pass, `texId=wallTexAt(mapX,mapY)` then `WALLTEX[texId]`. texId 0..4, valid.

5. The `drawStart`/`drawEnd` use `let` but never reassigned — fine.

6. The wall pixel write: `const r=px[((y*RW+x)*4)]=tex[ti]*ff;` — chained assignment, returns value to r. Works. But `tex[ti]*ff` where tex is Uint8ClampedArray (from getImageData.data which is Uint8ClampedArray). Multiplication gives number. Assigned to px (Uint8ClampedArray) clamps. Fine.

7. floor pass: `rowY = isFloor ? y : (half - p)`. For ceiling, p=half-y, rowY = half-(half-y)=y. So rowY=y always effectively. Good. But when y==half (p=0), `if(p<1) continue` skips. Good. So rows y=0..half-1 ceiling, y=half+1..RH-1 floor. Row y=half (horizon) skipped → remains whatever. Initially px alpha=255, rgb=0 (black). The horizon row would be black. That's a 1px black line at horizon. Wall pass likely overwrites most of it. Minor. Could fill but fine.

Actually wait — does the floor pass cover the full screen including the wall band? Yes, it fills top half ceiling and bottom half floor across all columns. Then wall pass overwrites the wall band columns/rows. Good. So only wall band pixels get wall texture; rest floor/ceiling. Correct.

8. `bctx.putImageData(img,0,0)` then sprite stripes drawn with bctx.drawImage. putImageData sets pixels ignoring transform. Then drawImage composites sprites. Good.

9. Sprite source: `bctx.drawImage(spr, stripe*(64/w)|0, 0, srcStep, 64, sxp, dStartY+bob, 1, h)`. spr is 64x64 canvas. srcX = stripe*(64/w). For w=h sprite height in internal pixels. dStartY+bob could be negative; drawImage handles negative dest by clipping. Good.

10. zbuffer comparison `tY >= zbuf[sxp]-0.02` skip (wall closer). Good.

11. HUD muzzle flash uses ctx (main canvas) with createRadialGradient — fine.

12. drawWeapon draws on ctx main canvas scaled coords. Fine.

13. The overlay start button: on click hides overlay and requests pointer lock. But pointer lock requires user gesture & the canvas. Should work.

14. `document.getElementById('start')` referenced at top — exists in initial HTML. After showEnd replaces innerHTML with a new button id="start", re-listener added. Good.

15. One concern: the initial `requestAnimationFrame(loop)` starts the game loop immediately even before clicking start. So render runs behind overlay. That's fine (shows the maze behind overlay). Actually overlay has rgba(0,0,0,.82) so semi-transparent — you'd see the maze dimly. Nice. But pointer not locked so mouse turn doesn't work, but keyboard works. Fine. Actually movement keys would work behind overlay too. Whatever, it's fine; overlay covers. Actually the game updates while overlay visible — player could move. Minor, acceptable. But enemies could kill player before start. Hmm. Let me add a `started` gate so update only runs after start. Let me add a `gameStarted` flag.

Let me add: only run update/enemy logic if started. Render always. Let me implement a `paused`/`started` flag.

Actually simpler: gate the update() body. Let me add `let started=false;` set true on start click, and in loop only call update if started (and not dead/won handled inside). Let me add.

16. Another: `keys['Enter']` to restart on death — but pointer lock might be exited. Fine.

17. `enemyTick` movement: when blocked, `e.seen = e.seen` no-op (harmless). Could get stuck but ok.

18. Potential perf: floor pass writes RH*RW pixels ~ 270*480=129600 per frame, walls similar. Fine.

Let me add the started gate. Let me edit the loop and start handler.

Also the "msg" flash for hit/miss — fine.

Let me add started flag.

Now in showEnd, when player dies/wins, I should also exit pointer lock so the overlay button is clickable. Let me add `document.exitPointerLock()` in showEnd. And set started stays true but update returns early when dead/won. That's fine.

Let me add exitPointerLock to showEnd.

Now in update, when dead/won, pressing Enter restarts. But pointer lock exited, Enter key works. Good. Also the "PLAY AGAIN" button calls restart (reload). Good.

Let me do a final syntax check and also verify there are no references to undefined things. Let me grep for a few identifiers.

Let me check: `planeLen` used in planeVec and render. Defined. `mouseDX` defined unused — fine. `moveCool` on enemy unused — fine.

Let me verify `drawMinimap`, `drawWeapon` defined before use — they're function declarations, hoisted. Good. `weaponBob` declared with `let weaponBob=0;` AFTER drawHUD which uses it — but it's a let at module scope; drawHUD references weaponBob which is hoisted in TDZ? No — `let` is not hoisted for use before declaration in temporal dead zone, BUT drawHUD is a function that's called at runtime (in loop) after the `let weaponBob=0` line executes. So by the time drawHUD runs, weaponBob is initialized. Fine.

Wait, `muzzleFlash` declared `let muzzleFlash=0;` after drawHUD references it too — same, fine at runtime.

`showMap` declared after drawHUD — fine at runtime.

Now, the order of top-level execution: function declarations hoisted; the IIFE spawn runs; event listeners attached; `requestAnimationFrame(loop)` at end. All good.

Let me run final syntax check.

Let me try to actually run it with a headless browser via a quick install of puppeteer? That might take too long / no network. The instructions say no network for the artifact but I can try to install puppeteer — but no network in this environment likely. Let me skip and trust the review.

Actually, let me do one more careful scan: the floor/ceiling `rowY` for ceiling. I set `const rowY = isFloor ? y : (half - p);`. For ceiling y<half, p=half-y, rowY=half-(half-y)=y. Good. But I should just use y directly. It's fine.

One concern: the floor pass computes `tx`/`ty` from `fx, fy` which is `posX + rowDist*rX0`. rowDist can be huge for p small (near horizon) but p<1 skipped. For p=1 (y=half±1), rowDist=0.5*270/1=135. Large but finite. fx could go far. floor() handles. Fine.

Another: when rowDist is large, ff = max(0.12, 1.25 - 135*0.05)=max(0.12,1.25-6.75)=0.12. Good clamped.

Now, the wall pass `f = 1.35 - perp*0.06`. For perp up to ~20 (far), f=1.35-1.2=0.15, ff=max(0.18,...)=0.18. Good.

Sprites: `h = Math.abs((RH/tY))|0`. For tY small (close), h large, could exceed RH — drawImage clips. Good. dStartY negative. Fine.

I think it's solid. Let me also verify the canvas CSS: #game width:100% height:100% and canvas.width=RW=480. CSS stretches to fill window. image-rendering pixelated. Good. But I set canvas.width=RW in resize(). The display CSS overrides display size. Good.

Wait, resize() sets canvas.width=RW and canvas.height=RH, and CSS sets style width/height to window. So internal res 480x270, displayed stretched. Good pixelated.

But the HUD draws using canvas.width (480) and canvas.height (270) as cw,ch! Because canvas.width=RW=480. So HUD text at 16px on 480-wide canvas, scaled up to window. That's fine — it scales with the buffer. Good, consistent. Minimap uses cw=480. Fine.

Actually wait — ctx is the main canvas context at 480x270 internal res, and drawHUD draws weapon etc. directly on ctx at 480x270 coords, which then... no. The main canvas IS 480x270 internally (canvas.width=480). We blit buf (480x270) onto ctx scaled to canvas.width x canvas.height = 480x270 — i.e. 1:1! Because canvas.width=RW. So the blit is 1:1, and CSS stretches the whole canvas (480x270) to window size. HUD drawn at 480x270 coords also stretches. 

So effectively everything is at 480x270 and CSS upscales. The blit `ctx.drawImage(buf,0,0,RW,RH,0,0,canvas.width,canvas.height)` = drawImage(buf,0,0,480,270,0,0,480,270) = 1:1 copy. Fine. Could just drawImage(buf,0,0). Works.

OK. I'm confident. Let me also double check the `srcStep` ceil(64/w) — for w large (close enemy, h=RH/tY, tY small → h large, e.g. 270). 64/270 <1, ceil=1. stripe loop w=270 times per sprite. Fine. For far enemy w small e.g. 10, 64/10=6.4 ceil=7, srcX=stripe*6.4. srcStep 7. Slight over-read beyond 64? stripe goes 0..9, srcX max = 9*6.4=57.6, +srcStep 7 = 64.6 >64 → drawImage clamps/reads beyond? Source rect (57.6,0,7,64) — right edge 64.6 beyond 64 width. Canvas drawImage may clamp or error? Actually reading beyond source bounds is allowed (treats as transparent). Should be fine. But to be safe, srcStep could be Math.max(1, 64/w) without ceil. The src width being slightly more than needed just samples more. The visual is per-1px-wide stripes so sampling source width doesn't matter much. It's fine.

Actually there's a subtle issue: drawImage with non-integer source x (stripe*(64/w)|0 is integer) and integer source width srcStep, dest width 1. Fine.

I'm satisfied. Let me make sure file present and final.

Let me do a final read of the top portion to ensure the floor block placement is correct.

All looks correct. The floor pass writes ceiling to row y (top half) and floor to row y (bottom half), then walls overwrite the band, then putImageData, then sprites drawn on bctx, then blit.

Let me also double-check: ceiling for y<half writes to rowY = half-p = half-(half-y)=y. Yes rowY=y. So ceiling occupies rows 0..half-1, floor rows half+1..RH-1. The horizon row `half` is skipped. Walls cover most of it. The tiny black horizon line at y=half where no wall — at the vanishing point there's always a wall far away typically, so line covered. Acceptable.

Everything is solid. The file is complete and present. Let me confirm the file exists.