FAQ / Expected Questions

1) Why is your map validator safe?

Short answer:
Validation rejects invalid geometry before runtime and uses BFS closure checks with explicit void handling.

What to explain:

• validation runs before init_mlx
• it enforces allowed symbols, exactly one spawn, and enclosed playable area
• BFS treats out-of-bounds or space as a leak
• irregular row lengths are safe because missing columns are interpreted as void
• unreachable open cells are rejected

2) How does DDA choose the first hit?

Short answer:
At each step, DDA advances along the smaller next-side distance, side_x or side_y, until it reaches a blocking cell.

What to explain:

• each ray starts in the player cell with direction, delta distances, step signs, and initial side distances
• the loop compares side_x and side_y
• it advances one grid boundary on the smallest side
• it moves to the next map cell on X or Y
• it checks whether the new cell is solid
• the first blocking cell is the first valid hit
• perpendicular distance is then derived from side distance minus delta

3) How are texture coordinates computed?

Short answer:
wall_x gives the horizontal hit fraction on the wall, then tex_x is selected from texture width and optionally flipped, while tex_y advances by a vertical step across the projected wall height.

What to explain:

• wall hit fraction is computed from perp_dist
• only the fractional part of the wall hit is kept, in [0,1)
• horizontal sampling uses tex_x = (int)(wall_x * tex_width)
• tex_x may be flipped depending on hit side and ray direction
• vertical sampling uses step = tex_height / line_height
• tex_pos starts at the projected wall start and advances one step per screen pixel
• tex_y is clamped to avoid out-of-bounds reads

4) How does cleanup work on partial initialization?

Short answer:
All resources are owned by t_app, and cleanup checks pointer validity before destroy or free, so partial initialization states are safe.

What to explain:

• startup initializes progressively: parse, player vectors, MLX, textures, then bonus subsystems
• on any failure in main, free_app(&app) is called
• free_app destroys only initialized resources
• this includes images, textures, bonus subsystems, window and display, config strings, and map buffers
• destroy helpers null pointers after release when appropriate
• the same cleanup path is reused for normal close with ESC or the window cross

5) Why can make test fail on a valid map in headless mode?

Short answer:
The repository smoke script treats a valid runtime as “the process is still alive after timeout”, so a headless mlx_init failure produces a false negative.

What to explain:

• tests/run.sh expects valid maps to exit with 124 after timeout 1s
• if mlx_init fails early, the binary exits with an error instead
• parser and validation behavior can still be correct even when the graphical smoke test fails
• final runtime verification therefore requires a real X11 session

6) Which Makefile checks should I run before evaluation?

Short answer:
Run both build targets and both repository test targets.

What to explain:

• make builds the mandatory binary
• make bonus builds the bonus binary
• make test runs mandatory parser/validation/init/render smoke cases
• make test_bonus runs bonus smoke maps and symbol checks
• the current Makefile does not provide a separate ci target

Quick Oral Version

• validation is strict and happens before MLX, so bad maps never reach runtime
• DDA steps grid by grid using the nearest side distance, so the first hit is deterministic
• texture mapping uses wall_x for tex_x and stepped projection for tex_y
• cleanup is centralized in free_app and pointer-guarded, so partial init failures stay safe