Author Topic: Quake 2 GLES  (Read 1277 times)

Thenesis (OP)

Quake 2 GLES
« on: January 15, 2017, 11:56:34 pm »
Hello,

I'm working on a version of Quake 2 for embedded platforms, using their GPU with OpenGL ES 1.1 (maybe a version with OpenGL ES 2.0 later).

Currently it works quite well on Raspberry Pi and Creator CI20 (and PC obviously), even in 720p with MSAA. The GCW Zero is stuck in 320x240 and has 20 to 60 fps, mainly because of the GLES 1.1 implementation which is horribly slow and buggy, and also because I don't use vertex buffers (and all vertices go through the CPU for each frame). The GPU itself doesn't seem to suffer.

But I have some trouble when data is on the external SD card, since the data must be separated from the binaries for legal reasons.

I know that I can put these data in the internal SD card, and it is supported, but I think it's cleaner if the OPK is in the /apps directory and the data in the /Quake2 directory of the external SD card.

So when the OPK is run, the current directory is "/mnt/Quake 2/".
The path to the SD card is /media/<card name>. But I don't know <card name> because it can be different for each user.

Does anyone know a way to find the the path to the SD card ?

Thank you in advance !

By the way I'm also working on a GLES 1.1 version of Quake 1, which runs but is not ready for a release.

com64

  • *
  • Posts: 58
Re: Quake 2 GLES
« Reply #1 on: January 16, 2017, 12:16:43 am »
What's usually done is putting the data on the internal memory, like:
Code: [Select]
~/.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:
Code: [Select]
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).
« Last Edit: January 16, 2017, 12:19:05 am by com64 »

mth

  • *
  • Posts: 297
Re: Quake 2 GLES
« Reply #2 on: January 16, 2017, 06:07:04 am »
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.

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.

Thenesis (OP)

Re: Quake 2 GLES
« Reply #3 on: January 16, 2017, 09:38:13 pm »
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.

gameblabla

  • *
  • Posts: 444
Re: Quake 2 GLES
« Reply #4 on: January 17, 2017, 03:28:12 am »
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 ?
Isn't it already the case ?
The sd card is mounted at /media/sdcard

Also, please provide the sauce, i'm curious to give it a try.
Thanks

pcercuei

  • ***
  • Posts: 1392
    • GitHub
Re: Quake 2 GLES
« Reply #5 on: January 17, 2017, 10:52:21 am »
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.

Thenesis (OP)

Re: Quake 2 GLES
« Reply #6 on: January 17, 2017, 12:09:26 pm »
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 ?
Isn't it already the case ?
The sd card is mounted at /media/sdcard

Also, please provide the sauce, i'm curious to give it a try.
Thanks

/media/sdcard is empty for me, it doesn't point on the external SD card in my system.

I want to make a release, that's why I'm here :)
But I first need to put the source code on Github for legal reasons.
I try also to make a first release that is not too dirty.

Thenesis (OP)

Re: Quake 2 GLES
« Reply #7 on: January 17, 2017, 12:16:18 pm »
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 ...).

mth

  • *
  • Posts: 297
Re: Quake 2 GLES
« Reply #8 on: January 17, 2017, 03:09:41 pm »
The sd card is mounted at /media/sdcard

The auto-mount handler tries to use the label of the SD card; if it doesn't have a label, "sdcard" is used.

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.

Having to make assumptions on the OS being OpenDingux might be unavoidable, since that is currently the only OS using OPKs. But it would be good to avoid making assumptions about the device (like it having an external SD slot).

Maybe we could have opkrun set an environment variable that contains the path of the OPK file? That would make locating data using relative paths a lot easier.

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

Thenesis (OP)

Re: Quake 2 GLES
« Reply #9 on: January 17, 2017, 10:18:54 pm »
@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.

jutley

  • **
  • Posts: 703
Re: Quake 2 GLES
« Reply #10 on: February 27, 2017, 05:57:23 pm »
Do we have a working quake 3?
Devices
GCW White Retail
GameGadget
Arduboy
PocketChip

Thenesis (OP)

Re: Quake 2 GLES
« Reply #11 on: March 01, 2017, 10:51:27 pm »
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/

zear

  • * Moderator
  • Posts: 2378
Re: Quake 2 GLES
« Reply #12 on: March 02, 2017, 12:15:01 am »
For a Quake III port, you can use my repository: https://github.com/zear/ioq3
I never released it, because the default button mapping and menu layout is embedded in the commercial data files, so a proper port could not be procured.

 

Post a new topic