Write-side parity: ExportImageToPhysFS / ExportWaveToPhysFS / ExportImageAsCodeToPhysFS
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 68/100
Research direction
Start with the proposed ExportImageToPhysFS, ExportImageAsCodeToPhysFS, ExportWaveToPhysFS, ExportWaveAsCodeToPhysFS, and possibly ExportFontAsCodeToPhysFS entry points. Review ExportImageToMemory and ExportWaveAsCode alongside SaveFileDataToPhysFS and SetPhysFSWriteDirectory; done means the supported typed exporters write their generated buffers through the PhysFS write directory.
Written by the indexing model from the issue text.
Description
Summary
The current API has good coverage for loading raylib assets through PhysFS (LoadImageFromPhysFS, LoadWaveFromPhysFS, etc.) but only generic byte/text writers (SaveFileDataToPhysFS, SaveFileTextToPhysFS) on the write side. Add typed export wrappers so that screenshots, recorded audio, generated images, and user-generated content can all go through the PhysFS write directory without callers having to round-trip through raylib's stdio-based exporters.
Proposed API
bool ExportImageToPhysFS(Image image, const char* fileName);
bool ExportImageAsCodeToPhysFS(Image image, const char* fileName);
bool ExportWaveToPhysFS(Wave wave, const char* fileName);
bool ExportWaveAsCodeToPhysFS(Wave wave, const char* fileName);
bool ExportFontAsCodeToPhysFS(Font font, const char* fileName); // if feasible
Each one would mirror its raylib counterpart but write through SaveFileDataToPhysFS instead of the OS filesystem, so the file lands in whatever directory was set via SetPhysFSWriteDirectory() (typically GetPrefDirectory()).
Why
- User screenshots, level editors, and save-game data should land in the pref directory by default — right now callers have to call
ExportImageToMemory()and feed the buffer intoSaveFileDataToPhysFS()manually. - Keeps the read/write API symmetric, which is currently a small papercut.
- All of these are thin wrappers — raylib already provides the in-memory exporters.
Notes
ExportImageToMemory()/ExportWaveAsCode()from raylib already produce the buffers; these helpers just plumb the bytes through PhysFS.
- Dominant language
- C
- Stars
- 50
- Forks
- 11
- PR merge metrics
- No merged PRs in 30d
Getting set up
We have not checked this project's setup files yet. 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 4/5 3-5 days Newbie friendliness 45/100
RobLoach/raylib-physfs#33 ·
-
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 88/100
ARM-software/sysarch-acs#556 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
bug needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
netdata/netdata#24062 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100