Dingoonity.org

What's usually done is putting the data on the internal memory, like:
~/.quake2/
If you really want to store something on the external SD card, I've put something together that will find the first mountpoint for the first partition of the external SD card:
mount | grep -m1 /dev/mmcblk1p1 | cut -d " " -f 3
I'd suggest providing the choice to use either path (checking the internal SD first, then external, something like that).

Thank you for your answers.

So the process would go like this:

• get the working directory, this is also the mount point for the OPK
• read /proc/mounts to find the loop device (/dev/loop<N>) associated with the mount point
• find the image path associated with the loop device, this is the OPK file
• look for the data relative to the OPK path

The third step can be done using an ioctl specific to loop mounts, see the query_loop function of busybox for an example.

If you really want to store something on the external SD card, I've put something together that will find the first mountpoint for the first partition of the external SD card:

Code: [Select]

mount | grep -m1 /dev/mmcblk1p1 | cut -d " " -f 3

I was expecting something simpler like "the external SD card can be accessed through this fixed path".

If a maintainer of the GCW Zero operating system goes through this post: for the next version, could you automagically mount it for everyone so that it can be accessed through /media/extsdcard or /mnt/extsdcard ?

Coding it to always look for the data on the external SD card would prevent people from installing Quake on the internal storage. It would be better to look for the data relative to the OPK's location.
...
I'd suggest providing the choice to use either path (checking the internal SD first, then external, something like that).

What's usually done is putting the data on the internal memory, like:

Code: [Select]

~/.quake2/

It already checks the internal SD for .pak files, in /media/data/Quake2 as specified in http://wiki.surkow.com/Understanding_the_directory_structure. The Quake 2 engine can check multiple paths to find its files, it's just a few lines to add.

I thought it was cleaner to allow it to run independently on SD cards you can swap. Quake 2 data take something like 630 MB with all mission packs and HQ textures, a user could prefer to not fill the internal SD card with this.

So I decided to not change the current behavior. When using an OPK, the data files must be installed in /media/data/Quake2 in the internal SD card.

If a user wants to put data on the external SD card, he will have to copy the binaries (not the OPK) in the same directory.

I will provide both the OPK and the binaries (with the source code obviously).

All written files (configuration, logs, downloaded maps and skins) are put in "/media/home/.local/share/Thenesis/Quake2".
This is the path given by SDL2.

I was expecting something simpler like "the external SD card can be accessed through this fixed path".

If a maintainer of the GCW Zero operating system goes through this post: for the next version, could you automagically mount it for everyone so that it can be accessed through /media/extsdcard or /mnt/extsdcard ?

Well we didn't really want to do that, to force people to write code that will compile and work on other Linux systems. The more assumptions you make on the OS, the less portable  your code end up being.

Well we didn't really want to do that, to force people to write code that will compile and work on other Linux systems. The more assumptions you make on the OS, the less portable  your code end up being.

OK I understand. The clean way is to ask the user for a place where to find the files.
But since it is not my engine, it needs some modifications to do so because pak files are needed early at start up, before rendering is initialized. If I found the time and the courage, I will try to do something for this.

Beside this, being able to use a path relative to an executable is portable across Linux and Windows systems. I will check if I can find the path of the OPK from the main() arguments (wonder why I didn't think about this before ...).

@Thenesis: Maybe you could look for the data in each subdir of /media? That is a pretty common place to mount removable storage.

I will think about it. For the moment putting binaries in the same directory than the data is simple and intuitive. There will be .sh scripts to launch the different mission packs, this what I have used up until now and it works well. The user will have to use the Explorer to launch the game, this less friendly than a icon in the games category but there is always the possibility to put everything on the internal SD card for this.

If someone has the skills to make nicer icons than the ones I have found, it would be cool to add them in the github once it will be setup.

For Quake 3, someone has done the port some years ago. You can check this topic: http://boards.dingoonity.org/gcw-games-and-homebrew/quake-3-will-transplant-it/

There is also an existing Quake 1 port: http://boards.dingoonity.org/gcw-games-and-homebrew/quake1-gles/

And also a previously existing Quake 2 port, which uses software rendering: http://boards.dingoonity.org/gcw-games-and-homebrew/(help)-quake-ii/

I just released the GLES 1 version of Quake 2: http://boards.dingoonity.org/gcw-releases/quake-2-gles-12725/