Known Limitations

1) Linux and X11 runtime dependency

The project relies on MiniLibX with X11 on Linux.

• in headless or misconfigured display environments, mlx_init may fail
• parser and validation can still be tested, but full runtime rendering cannot

2) Bonus progression is sequential only

Current level progression is linear:

• next level is current + 1
• trigger is manual (F4)
• no branching or selection system is implemented

If no next level exists, the progression call fails harmlessly.

3) Asset completeness policy in bonus mode

Bonus asset handling is mixed by subsystem:

• retro framebuffer initialization can warn and disable the retro path safely
• wall, door, symbol, and animation texture loading reports warnings for each missing asset, then fails bonus startup
• fallback texture constants exist for some symbol choices, but the resolved fallback files still must load successfully

So missing core bonus art is not treated as optional at runtime.

4) Performance scaling

Render cost scales with:

• window width, because it increases ray count
• sprite count
• bonus overlays such as minimap, HUD, and retro passes

Very high resolutions or heavy bonus scenes can reduce frame smoothness on weaker machines.

5) Sprite sorting complexity

Current sprite sorting is simple and deterministic, but it is not designed for very large sprite counts.

For the current pickup-based usage this is acceptable. For large dynamic sprite sets, a more efficient sort strategy would be preferable.

6) Coupling between mandatory and bonus paths

The mandatory executable includes bonus API calls through no-op compatibility files and shared flow.

This keeps one coherent runtime path, but it increases architectural coupling compared with a fully separate mandatory binary pipeline.

7) Door and gameplay depth

Door mechanics support interaction and passability transitions, but more advanced gameplay rules are not implemented in the current state:

• locks
• keys
• scripted triggers

The subsystem is functional, but its gameplay depth remains limited.

8) Test environment sensitivity

Automated scripts are useful smoke checks, but final behavior validation still depends on:

• local graphics session
• machine timing and performance
• asset path consistency across environments

So a passing test suite should be combined with manual runtime verification before the defense. The inverse is also true: in headless environments, valid runtime cases can fail the smoke scripts because the expected success condition is a timeout on a still-running graphical binary.