Auto-mount archive next to the executable
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
Research direction
Start by tracing the existing PhysFS initialization entry points and the platform-specific path handling controlled by RAYLIB_PHYSFS_PLATFORM_RAYLIB. Verify how raylib's GetApplicationDirectory() and current-directory checks can support the requested search order, then confirm completion with archive, loose-folder, NULL-argument, mount-point, and not-found cases; the issue names no files or tests.
Written by the indexing model from the issue text.
Description
Summary
Add an InitPhysFSAuto() (or similar) helper that automatically searches for and mounts a default archive without the caller having to figure out the path. This mirrors the convention used by LÖVE, SDL-based games, and several other engines, and removes a chunk of boilerplate from typical raylib game startup code.
Proposed behavior
Given a filename like "data.zip", search in this order and mount the first hit:
- Next to the running executable (use raylib's
GetApplicationDirectory()). - The current working directory.
- A loose folder of the same base name (e.g.
data/) for development builds where assets aren't packed yet.
If none are found, return false and let the caller decide what to do.
Proposed API
bool InitPhysFSAuto(const char* archiveName, const char* mountPoint);
archiveName— e.g."data.zip". May beNULLto fall back to a default.mountPoint— passed through to PhysFS, may beNULLfor root.
Why
- Removes the most common ~10 lines of "figure out where my assets live" code from every project that uses this library.
- Makes "ship a single executable + zip" workflows trivial.
- Keeps dev-mode (loose folder) and release-mode (zip) using the same code path.
Notes
- Should respect
RAYLIB_PHYSFS_PLATFORM_RAYLIBso it works on platforms where raylib provides its own file I/O. - Consider also exposing the resolved path via an out-parameter for logging.
- Dominant language
- C
- Stars
- 50
- Forks
- 11
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from RobLoach/raylib-physfs
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
RobLoach/raylib-physfs#34 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 30/100
RobLoach/raylib-physfs#21 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
RobLoach/raylib-physfs#19 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
RobLoach/raylib-physfs#18 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 25/100
RobLoach/raylib-physfs#17 ·
All issues in RobLoach/raylib-physfs
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
BasedHardware/omi#19711 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
microsoft/ebpf-for-windows#5604 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
trezor/trezor-firmware#7985 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 2 days