[Orkie]

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/o...amfsldr-0.2.zip
Download (Boomshine2x example): http://x11.gp2x.de/t...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]

This post has been edited by Orkie: 26 January 2008 - 09:14 PM

[bman]

Well, it works really good. I took exult (91MB) and got it down to 61.5MB. Start times changed from 5 seconds to 7 seconds. I didn't convert all save files, but I could continue a game just fine. Sound would not work with the music.raw mount, though. Probably a config issue on my part. Good idea for saving space.

[Orkie]

Glad to hear it's working. If you upload your image somewhere, I'll take a look and see if I can figure out why the sound isn't working.
It's a shame about the load time, but when Open2x is released, most of the original 5 seconds will likely be eliminated anyway if it gets recompiled .

[ruckage]

This sounds interesting. Not meaning to sound stupid but with a Fenix game does this also include the runtime in the finished image? Providing it does I'm sure I'll use it.

[Orkie]

It includes whatever you decide to bundle . I experimented on Boomshine2x (which is a Fenix game) and if you download the cramfsldr-0.1.zip file, you'll see that I included the runtime in the image. You can literally copy the file onto SD, select it from the menu and it'll run without any external dependencies (other than a few shell commands, which are in the standard firmware anyway).

[bman]

Glad to hear it's working. If you upload your image somewhere, I'll take a look and see if I can figure out why the sound isn't working.
It's a shame about the load time, but when Open2x is released, most of the original 5 seconds will likely be eliminated anyway if it gets recompiled .

A little too big to post. Don't have a file account anywhere.
I built a running exult with music support as described in ReadMe.
created run.sh
created cramfs and gpe

It may want some r/w access I did not define (like gamedata I left out)

here is the run.sh

#!/bin/sh
if [ -d "$RUNDIR/exult" ]
then
echo "Using existing exult save directory"
else
echo "Creating exult save directory"
mkdir -p $RUNDIR/exult
fi
echo "Creating music buffer"
touch $RUNDIR/exult/music.raw
mount -o bind $RUNDIR/exult/music.raw $MNTDIR/music.raw
echo "Creating settings files"
if [ -a "$RUNDIR/exult/.exult.cfg" ]
then
echo ".exult.cfg "
else
cp -f $MNTDIR/.exult.cfg $RUNDIR/exult/.exult.cfg
fi

mount -o bind $RUNDIR/exult/.exult.cfg $MNTDIR/.exult.cfg
./exult.gpe
sync
umount $MNTDIR/music.raw
umount $MNTDIR/.exult.cfg

[Senor Quack]

That's a neat trick.

[trooper]

Hi Orkie,

I`ve edited/ rearranged you topic so that it looks better on the front page, Hope you don`t mind.

Trooper

[Orkie]

That's fine, thanks.

[rlyeh]

thumbs up :D !

[icurafu]

Wow, very impressive.

This could make a kick@rse combination with the Gp2x Emudownloader. (But not just emulators).

Hopefully something like this will be included in the initial release of the Pandora to save a lot of installation pain.

This post has been edited by icurafu: 28 January 2008 - 08:24 AM

[Burbruee]

Very nice.

[Kojote]

i have some questions stuff to add up... specially about packaging fenix games with the runtime in one binary. anyone has more details on this yet? if it's working flawless, we could allow fenix that way in pdrc 3.99.

[Orkie]

Well I've not had any problems. Download the boomshine2x binary linked to in the first post if you want to try it for yourself (it is a Fenix game). I'll probably be on IRC tomorrow evening if you have any specific questions.