Orkie
Super Duper Mega GP Mania
This is a first version of my suite of tools for making single file executables for the GP2X. This
version uses cramfs images to store the actual game data.
It hasn't been particularly extensively tested, but it should work on any GP2X since it is mostly script based (though these binaries won't run on custom firmwares unless they use the GPH kernel or provide their own cramfs modules). I will be working on this again in the near future and will be providing more tools and more information on writing your run.sh scripts (I may even be able to eliminate that entirely though the use of a tool I intend to write).
UPDATE: 0.2 has been released to fix a mistake which prevented packages running on Open2x. All packages should be recreated with this release.
Download: http://x11.gp2x.de/open2x/cramfsldr/cramfsldr-0.2.zip
Download (Boomshine2x example): http://x11.gp2x.de/tempfiles/boomshine2x.gpe
[cut]
I'll just paste the README here since it covers pretty much everything:
CODE
cramfsldr 0.1 by Orkie (orkie@gp2x.de)
This is a first version of my suite of tools for making single file executables for the GP2X. This
version uses cramfs images to store the actual game data.
Advantages of cramfs images:
* Can be used compressed
* Filesystem has no 'blocks' so many tiny files don't take up lots of space
* Easy to organise (just need a file and a save directory on SD) and can be run from anywhere
* No need to extract or set up, just copy it over and run as normal (could be downloaded straight to SD)
* Feasible to use for a one-click downloader in the future
Disadvantages of cramfs images:
* Extra 0.5 seconds load time in worst case (generally much less)
* Read-only filesystem, so config files and saves have to be stored in a separate directory for
each application
Myths:
* It is not possible to extract them
> cramfsck can extract cramfs loopback images
* You can only make them on Linux
> mkcramfs and cramfsck can both run on Windows and in pretty much any other OS
* They are slow
> A small extra load time is added, which is often not noticeable
* The size difference is negligible
> egoboo2x went from 130MB to 12MB with this process, and Boomshine2x from 6MB to 4MB
* It is harder for a user to set up
> A user simply has to copy a single file onto SD. How could that be more difficult than having to
extract it and occasionally copy into certain places?
How to use:
1. Write a run.sh script and include this in the root directory of your application. This is
what will be executed by the loader, so it needs to mount any files that have to be writable,
and are stored in a writable directory outside the image, using "mount -o bind src dest".
See the included Boomshine2x image contents for an example of how to write a run.sh.
> $MNTDIR is the directory the game is being run rom (i.e. the root of the game)
> $RUNDIR is the directory the image is stored in. The save/config directory should be
created here
2. Mark your application's executable "+x" using chmod (should not be needed in Windows).
3. Make an image using mkcramfs (no label is needed for the filesystem). A Windows binary is
included, but for all other operating systems, it will be neccessary to compile from source.
See the links section for this.
4. Merge the files in the order cramfsldr.gpe, cramfs.o, zlib_inflate.o, cramfs image.
> e.g. cat cramfsldr.gpe cramfs.o zlib_inflate.o cramfs.img > runme.gpe (*NIX)
> e.g. COPY /B cramfsldr.gpe+cramfs.o+zlib_inflate.o+cramfs.img runme.gpe (Windows)
5. Done! runme.gpe will now be treated as a normal application by the GP2X.
NOTE: Your application should not launch the menu itself if at all possible - leave it to the
script please! That way, it can clean up properly without being interrupted.
How it works:
It work in the same way as most self extracting archives on *NIX, but doesn't extract anything.
At the start of the file, there is a script. This first checks if cramfs modules are installed and
copies them into place if they are not. Next it creates a mount point in /tmp (so it is erased at
every power-down) and mounts the image. It sets some environment variables and executes run.sh, which
is a shell script inside the image. After application execution has finished, it cleans up and re-launches
the menu.
Future plans:
* Work on mkcramfs/cramfsck a bit to make them more user-friendly
* Examine ways of adding writable sections to the image
* Automated download service?
Thanks:
ParkyDR
Comments and constructive criticism are appreciated, mindless ranting and flaming is not.
[/cut]
version uses cramfs images to store the actual game data.
It hasn't been particularly extensively tested, but it should work on any GP2X since it is mostly script based (though these binaries won't run on custom firmwares unless they use the GPH kernel or provide their own cramfs modules). I will be working on this again in the near future and will be providing more tools and more information on writing your run.sh scripts (I may even be able to eliminate that entirely though the use of a tool I intend to write).
UPDATE: 0.2 has been released to fix a mistake which prevented packages running on Open2x. All packages should be recreated with this release.
Download: http://x11.gp2x.de/open2x/cramfsldr/cramfsldr-0.2.zip
Download (Boomshine2x example): http://x11.gp2x.de/tempfiles/boomshine2x.gpe
[cut]
I'll just paste the README here since it covers pretty much everything:
CODE
cramfsldr 0.1 by Orkie (orkie@gp2x.de)
This is a first version of my suite of tools for making single file executables for the GP2X. This
version uses cramfs images to store the actual game data.
Advantages of cramfs images:
* Can be used compressed
* Filesystem has no 'blocks' so many tiny files don't take up lots of space
* Easy to organise (just need a file and a save directory on SD) and can be run from anywhere
* No need to extract or set up, just copy it over and run as normal (could be downloaded straight to SD)
* Feasible to use for a one-click downloader in the future
Disadvantages of cramfs images:
* Extra 0.5 seconds load time in worst case (generally much less)
* Read-only filesystem, so config files and saves have to be stored in a separate directory for
each application
Myths:
* It is not possible to extract them
> cramfsck can extract cramfs loopback images
* You can only make them on Linux
> mkcramfs and cramfsck can both run on Windows and in pretty much any other OS
* They are slow
> A small extra load time is added, which is often not noticeable
* The size difference is negligible
> egoboo2x went from 130MB to 12MB with this process, and Boomshine2x from 6MB to 4MB
* It is harder for a user to set up
> A user simply has to copy a single file onto SD. How could that be more difficult than having to
extract it and occasionally copy into certain places?
How to use:
1. Write a run.sh script and include this in the root directory of your application. This is
what will be executed by the loader, so it needs to mount any files that have to be writable,
and are stored in a writable directory outside the image, using "mount -o bind src dest".
See the included Boomshine2x image contents for an example of how to write a run.sh.
> $MNTDIR is the directory the game is being run rom (i.e. the root of the game)
> $RUNDIR is the directory the image is stored in. The save/config directory should be
created here
2. Mark your application's executable "+x" using chmod (should not be needed in Windows).
3. Make an image using mkcramfs (no label is needed for the filesystem). A Windows binary is
included, but for all other operating systems, it will be neccessary to compile from source.
See the links section for this.
4. Merge the files in the order cramfsldr.gpe, cramfs.o, zlib_inflate.o, cramfs image.
> e.g. cat cramfsldr.gpe cramfs.o zlib_inflate.o cramfs.img > runme.gpe (*NIX)
> e.g. COPY /B cramfsldr.gpe+cramfs.o+zlib_inflate.o+cramfs.img runme.gpe (Windows)
5. Done! runme.gpe will now be treated as a normal application by the GP2X.
NOTE: Your application should not launch the menu itself if at all possible - leave it to the
script please! That way, it can clean up properly without being interrupted.
How it works:
It work in the same way as most self extracting archives on *NIX, but doesn't extract anything.
At the start of the file, there is a script. This first checks if cramfs modules are installed and
copies them into place if they are not. Next it creates a mount point in /tmp (so it is erased at
every power-down) and mounts the image. It sets some environment variables and executes run.sh, which
is a shell script inside the image. After application execution has finished, it cleans up and re-launches
the menu.
Future plans:
* Work on mkcramfs/cramfsck a bit to make them more user-friendly
* Examine ways of adding writable sections to the image
* Automated download service?
Thanks:
ParkyDR
Comments and constructive criticism are appreciated, mindless ranting and flaming is not.
[/cut]
.
