Quake 3 Arena at 60 FPS

[jamesh]

I think 60fps is the max the HDMI outputs. Just out of interest, what benefits are there running the renderer at a higher FPS than the display?

HDMI doesn't have a 60fps limit. Also, many displays are capable of more than 60hz. As for the other benefits? You jump higher. Basically higher fps = smoother gameplay.

Indeed HDMI goes higher than 60Hz, but I have a feeling (I will check) that the HDMI on the Videocore is capped at 60Hz, but I may be wrong, I just know that it is capped on other devices that use the Videocore 4 at 60Hz.

[marqs]

It's seems tu run under forced vsync and fixed resolution, which is a pity. You can of course select e.g. 640x480@120Hz as the screen mode in config.txt if your monitor can handle it, but the game is just too heavy for the CPU. Perhaps Q1 would be a more suitable for this hardware.

[AndrewS]

Perhaps Q1 would be a more suitable for this hardware.

It'll probably need a lot of conversion, but I guess https://code.google.com/p/glesquake/ would probably be the best starting point for a Raspi version of Quake1? (reminder: Raspi has OpenGLES, which isn't the same thing as OpenGL, as used by GLQuake)

[dextrus]

I've made a minor discovery regarding sound:

It's been hacked out. If you look at snd_dma.c (in code/client) around line 393 you can see the offending hack (the author even says "XXX hacked to disable sound").

Removing the hack and enabling sound (note you also need to modify line 400) again cause floating point exception errors. So if we in turn hack the signal handler and ignore those, we finally get the output below.

I'm at a loss at this stage, but will delve deeper. I'm assuming there is no way to debug this remotely in a nice graphical environment like Visual Studio, so I shall continue to hack it to pieces. Perhaps it's just running out of memory and losing the plot?

/Andy


------ Initializing Sound ------
----- Sound Info -----
-1 stereo
0 samples
0 samplebits
0 submission_chunk
0 speed
(nil) dma buffer
No background file.
----------------------
Sound initialization successful.
--------------------------------
Sound memory manager started
Loading dll file ui.
Sys_LoadDll(/home/raspbian/quake3/baseq3/uiarm.so)...
Sys_LoadDll(/home/raspbian/quake3/baseq3/uiarm.so) failed:
"Failed loading /home/raspbian/quake3/baseq3/uiarm.so: /home/raspbian/quake3/baseq3/uiarm.so: cannot open shared object file: No such file or directory"
Sys_LoadDll(/root/.q3a/baseq3/uiarm.so)...
Sys_LoadDll(/root/.q3a/baseq3/uiarm.so) failed:
"Failed loading /root/.q3a/baseq3/uiarm.so: /root/.q3a/baseq3/uiarm.so: cannot open shared object file: No such file or directory"
Sys_LoadDll(build/release-linux-arm/baseq3/uiarm.so)...
Sys_LoadDll(build/release-linux-arm/baseq3/uiarm.so): succeeded ...
Sys_LoadDll(ui) found vmMain function at 0x42e1288c
9 arenas parsed
6 bots parsed
--- Common Initialization Complete ---
IP: 127.0.0.1
IP: 192.168.0.5
IP6: ::1
IP6: fe80::ba27:ebff:fe59:4f0a%eth0
Opening IP6 socket: [::]:27960
Opening IP socket: 0.0.0.0:27960

[dextrus]

At last, I have fixed the sound. It's only 3 lines of code to fix in the end!

In code/client modify the following lines in snd_dma.c. I might have nudged the line-numbers out though..

393: Undo the hack by un-commenting the s_soundMuted = qfalse; line. Comment out the line after, which reads "s_SoundMuted = 1".

1501: Comment out the "s_soundMuted = 1" line. Someone slipped this in without commenting! This too disables sound.

Finally, modify the Makefile at line 1381 and replace the "es_snd.o" with "sdl_snd.o". For some reason the arm build was not linking in the SDL sound.

Enjoy!

[jamesh]

Nice work!

[asb]

Want to make a pull request for https://github.com/raspberrypi/quake3 ?

[dextrus]

I've no idea if this works across other Pi configurations at the moment (need more Pi's!). Is it working for everyone? I'm a n00b with git too, so perhaps if we see it doesn't break anything else, someone else could do it?

[lewmur]

This is why vsync exists, though it just so happens to be the worst thing to have on when playing competitively. I explained above why you might want to have a higher fps, you might think this only applies to older games, but many new ones have this limitation as well.

This is pure nonsense. To even include the phrase "playing competittively" when discussing the Pi, is laughable. A $35 entry level board against a gaming rig where the video card alone cost more than $500? Heck, I'm amazed that abody could get 60fps out of the Pi in the best of conditions. Much less sustain that kind of rate while also running the game.

Let's try to remain at least a little bit realistic when discussing the Pi. Attempting to stretch bounds on what the Pi can do is great. But complaining about it not being a "real gaming platform" borders on the insane. Neither is any other computer that cost less than several hundred dollars.

[simonlc]

This is why vsync exists, though it just so happens to be the worst thing to have on when playing competitively. I explained above why you might want to have a higher fps, you might think this only applies to older games, but many new ones have this limitation as well.

This is pure nonsense. To even include the phrase "playing competittively" when discussing the Pi, is laughable. A $35 entry level board against a gaming rig where the video card alone cost more than $500? Heck, I'm amazed that abody could get 60fps out of the Pi in the best of conditions. Much less sustain that kind of rate while also running the game.

Let's try to remain at least a little bit realistic when discussing the Pi. Attempting to stretch bounds on what the Pi can do is great. But complaining about it not being a "real gaming platform" borders on the insane. Neither is any other computer that cost less than several hundred dollars.

I'm not complaining, I'm just saying it's not plausible, stop being a jerk. And heck if anyone buys a 500$ video card for Quake 3 these days. You could easily build a PC for less than $500 that which could run Quake 3 great.

Regardless, if you wanted higher fps, it would be achieved by removing the forced vsync and AA, then yeah, it might actually be plausible for competitive play. Please be more informed about such things before you try to attack me.

[dextrus]

It seems perfectly playable to me, especially with spacial sound. Have you both tried it on the latest Raspian Pisces build? If you're talking "competitive" meaning professional gamer level, then that's just crazy talk.

[Liamm]

At last, I have fixed the sound. It's only 3 lines of code to fix in the end!

In code/client modify the following lines in snd_dma.c. I might have nudged the line-numbers out though..

393: Undo the hack by un-commenting the s_soundMuted = qfalse; line. Comment out the line after, which reads "s_SoundMuted = 1".

1501: Comment out the "s_soundMuted = 1" line. Someone slipped this in without commenting! This too disables sound.

Finally, modify the Makefile at line 1381 and replace the "es_snd.o" with "sdl_snd.o". For some reason the arm build was not linking in the SDL sound.

Enjoy!

Odd. I'm on the latest Raspbian I made these edits and compiled successfully but only get sound during the intro video and menus. As soon as I go in game it's silent

[dextrus]

Here are the two code changes in context:

• /*
  =====================
  S_BeginRegistration
  
  =====================
  */
  void S_Base_BeginRegistration( void ) {
  // XXX hacked to disable sound // andy I am reversing this hack
  s_soundMuted = qfalse; // we can play again
  //s_soundMuted = 1;
  
  if (s_numSfx == 0) {
  SND_setup();

and in the same file later on:

• if( !si ) {
  return qfalse;
  }
  
  s_khz = Cvar_Get ("s_khz", "22", CVAR_ARCHIVE);
  s_mixahead = Cvar_Get ("s_mixahead", "0.2", CVAR_ARCHIVE);
  s_mixPreStep = Cvar_Get ("s_mixPreStep", "0.05", CVAR_ARCHIVE);
  s_show = Cvar_Get ("s_show", "0", CVAR_CHEAT);
  s_testsound = Cvar_Get ("s_testsound", "0", CVAR_CHEAT);
  
  r = SNDDMA_Init();
  
  if ( r ) {
  s_soundStarted = 1;
  // s_soundMuted = 1; //Andy, commented this our.
  // s_numSfx = 0;
  
  Com_Memset(sfxHash, 0, sizeof(sfx_t *)*LOOP_HASH);

I'm *fairly* certain I didn't change any other code meaningfully, but I was so intent on finding the problem I logged *everything*. In both cases you are undoing the forced change to set s_soundMuted to 1. In the second code snippet, you are also stopping the forced change to s_numSfx to 0. I'm on the 192k memory split (although I'm sure I tested it on the 128 one).

/Andy

[SliceOpi]

As a super-n00b when it comes to writing any code, I'm lost as far as how one even opens this file, let alone how to change any lines that need to be changed... I'd love to have sound on quake3! Any help with this would be much appreciated.

[dextrus]

There are a few user-friendly editors from the command line or there's nothing to stop you using the GUI and editing those files. I use pico, and there is nano (just type in the words) from the command line. I see the latest Raspbian build doesn't have Geany (not surprising though!) which is an excellent code-centric editor. However, if you have internet on your Pi, look here:

http://packages.debian.org/stable/editors/

Install one you like the look of with sudo apt-get install [insert package]. If it doesn't work, just do sudo apt-get remove [insert package]

There are also some general "how to build quake" blogs around. I'll add to this growing pile soon.

Here's a video of quake3 on the Pi with sound to prove I've not gone mad.

http://www.youtube.com/watch?v=88IHndVS ... e=youtu.be

I have to say, with sound, the 25-ish frame rate seems faster (I have overclocked my Pi a little). My son did choose to play the laggiest level though! I'm fairly certain, looking at the code, there can be more optimisation to come with ioquake3 over and above the amazing work everyone is doing with the OS's, libraries and Kernel code but I doubt we'll be getting 60fps I'm afraid (unless we stand and look into the corner of the arena all the time).

[shinji257]

I just built it earlier. I checked the Makefile though and I tracked it to setting arm to use es_ objects instead of sdl_ ones and since our distros have sdl support I went in to the build.sh file and just dropped the ARCH=arm bit. Hopefully it will attach to the sdl objects now. I'm not too keen on modifying makefiles if I can help it unless it is absolutely necessary.

On that note the code has openal support as well and that's disabled by option set. We do have openal libraries that may or may not work.

[shinji257]

I see that the change is pushed to the git repo however I found the sound to be full of static after a few minutes. Some buffering tweaks or something may be needed to clean it up or maybe see if openal works better (if at all). Anyways I'm going to suggest a change to the code to have the sound disabled by default while leaving it available for those that do want to enable it.

Line 455 @ code/client/snd_main.c
Change

Code: Select all

cv = Cvar_Get( "s_initsound", "1", 0 );

To

Code: Select all

cv = Cvar_Get( "s_initsound", "0", 0 );

That just makes it so that s_initsound now defaults to 0 which prevents sound from being initialized at all by default. If you want to have it enabled do one of the following
Open ~/.q3a/baseq3/q3config.cfg and add...

Code: Select all

seta s_initsound "1"

Or in game (for that session) bring down a console (typically tilde ~)

Code: Select all

s_initsound 1
snd_restart

Update: Leaving the above for history but you do not have to change it at all. OpenAL actually works.

Install the packages libopenal1, libopenal-dev, and libopenal-data. The first and last is needed to actually use it and the middle one is needed to link against it.

Open build.sh and change USE_OPENAL=0 to USE_OPENAL=1. Rebuild it. If you built once already it will simply relink OpenAL to the main binary. Now run using the main one. It will still indicate it is using SDL audio but you should have no more static. My audio was clear on the initial testing with no static at all even after several minutes and several test passes in the menu. In game audio was clear to me during play.

[strawberrytau]

Fantastic! Can you post the binaries?

[shinji257]

It is done. The package is built on Raspbian (Pisces image) so it is HardFP optimized and does not include the redundant SDL libraries that were in git repo or the openal libraries. It might not work on SoftFP built distros like the current official debian image. It also doesn't include the missionpack so files that were built during compile but they are not needed.

For SDL you may need to install the libSDL1.2-dev package from the raspbian repo.
For OpenAL install libopenal1 and it should get any dependencies that are needed for it.

If you need pk3 files I can't redistribute them but if you can google for them. There are plenty of sources. I'll reach out to Zenimax for possible permission to distribute the demo ones.

Download: http://www.robertpendell.com/rpi/q3a/qu ... or_rpi.zip

EDIT: Correction... Zenimax is the appropriate group to contact now apparently. Legal on iD Software homepage directs me to Zenimax instead. Hrm...

[shinji257]

Gah! It's still doing it occasionally. I have no idea why. Sometimes it's ok and sometimes it doesn't. Definitely looks like an audio buffer-underrun though.

Update: If you are getting static try bringing down the console (tilde by default) and entering "snd_restart" (no quotes) and press enter. It will re-init the sound subsystem and can clear it up in my build.

And yes my RPi does reboot sometimes while playing this game (in case anyone else gets it). Not sure why though.

Update: Finally got the game to output console text to log so that I can see it all. Getting this when the static happens.
ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred

That confirms my theory on why it happens. Just not processing audio fast enough. OpenAL helps but doesn't resolve it unfortunately. It's a start though.

[tnoskilz]

So far here is where I'm at:
Running on official raspian release image
16gb class10 sandisk
overclocked: arm_freq=900 gpu_freq=250 sdram_freq=500 (no overvoltage)
retail pak0
1st round of config tweaks has gotten me to a timedemo of 40.9 fps with sound enabled
..and I think there are easily a few more fps to be found in the config.

that's definitely playable!

[richx]

For some reason quake 3 freezes under raspbian-pisces-r3 on the main menu. This happens most of the time after a couple of seconds after the id animation. It froze in-game as well. The system is still up and I can SSH in and kill the process and get back to the shell. However, a reboot is needed before anything OpenGL works again, startx works afterwards.

But, quake 3 does not freeze at all under squeeze or the recently released official raspbian. I also ran it overclocked at 800MHz with no issues under the official images. Power is not an issue, I'm using a couple of HP Touchpad 2 amp adapters, both stay between 4.8-5V while the raspi is on (one is at 5.2V no-load, another is closer to the speced 5.3V no-load). Tried other USB adapters and hub with same results.

Also, if I access the vfat /boot partition, for example sha1sum /boot/*, I get maybe 20 times more of the following under pisces:

mmc0: missed completion of cmd 17 DMA (512/512 [1]/[1]) - ignoring it
mmc0: DMA IRQ 6 ignored - results were reset

[tnoskilz]

So far here is where I'm at:
Running on official raspian release image
16gb class10 sandisk
overclocked: arm_freq=900 gpu_freq=250 sdram_freq=500 (no overvoltage)
retail pak0
1st round of config tweaks has gotten me to a timedemo of 40.9 fps with sound enabled
..and I think there are easily a few more fps to be found in the config.

that's definitely playable!

I forgot to mention...this is at 128/128 memsplit. I also think it's more stable for me with this setting from what I've seen so far.

192 memsplit seems to max at about 36fps no matter what else I change in the config so far. I've also had some freezes during play at that split.

[Raidersan]

I compiled it on the pi and it runs very well, but the display is slightly too big for the screen, cutting off 5% off the top & bottom of the screen. When it shows "CD key", it's half hidden as well as the buttons at the bottom. In games, figures showing health & ammo are missing a portion. I have tuned my Raspbian console overscan in /boot/config.txt but it doesn't seem to have any effect on quake. Whaever I try through the menus in Quake doesn't make any difference. I see on some youtube videos that I am not the only one having this issue.
Did anybody witness this or better, found a fix?

[dom]

I compiled it on the pi and it runs very well, but the display is slightly too big for the screen, cutting off 5% off the top & bottom of the screen. When it shows "CD key", it's half hidden as well as the buttons at the bottom. In games, figures showing health & ammo are missing a portion. I have tuned my Raspbian console overscan in /boot/config.txt but it doesn't seem to have any effect on quake. Whaever I try through the menus in Quake doesn't make any difference. I see on some youtube videos that I am not the only one having this issue.
Did anybody witness this or better, found a fix?

The overscan fix in config.txt only applies to framebuffer (i.e. console and X).
OpenGL specifies the destination directly (the dest_rect in dispmanx_element_add) so could in theory avoid overscan area, but doesn't currently.

The best solution is disabling overscan on the TV. Almost all allow this but often the options are hard to find, without consistent naming. You may need to go into the service menu by entering a password on remote control.
Search for <yout TV model> and overscan in google.