User avatar
theburntcrumpet
Posts: 5
Joined: Tue Feb 10, 2015 11:27 pm

Doom 3 on Raspberry Pi 2

Wed Feb 11, 2015 12:16 am

Hello there, just wondering if someone could lend a hand.

I have had my new Raspberry Pi 2 for a couple of days now. Really impressed with what it can do. Was not expecting it to be anywhere near as usable in the desktop environment as it is.

I currently have emulationstation and kodi installed. Really impressed with the performance.

One thing that did occur to me was that the Doom 3 source is now publicly available, and there is a build for devices running Android with ARM processors. As Android shares huge similarities with Raspbian, I have attempted to build this from source using the Android shell script (using scons) . This got a good 10 minutes through and failed.

Sooner than wasting time troubleshooting this when there is already a perfectly good arm build with a deb package for installation, I decided to take the easy root (if you pardon the pun) and install this package.

To my surprise this worked. A port of Doom 3 is now installed on my Pi 2.

Unfortunately, when I run "doom.arm" from the the terminal emulator in LXDE, I get an error initializing OpenGL. I tried exiting LXDE with CTRL+ALT+F1 and running doom.arm from the terminal and got the same darn OpenGL initialization error. Tried both as root and still failed to initialize. I have also upped the video memory to 128MB using raspi-config.

Has anybody experienced the same issue with any other applications and found a simple solution to this? Any ideas? I just hope that if I do manage to get it running it actually runs well enough to play - the Raspberry Pi 2 should have plenty enough power for this considering the minimum specifications required for the original game. In theory, power shouldn't be an issue provided the minimum specifications for the source port are no different to the Windows minimum specifications.

Thanks for reading my first post! :D :roll: :P

Hiradur
Posts: 96
Joined: Fri Mar 01, 2013 10:59 am

Re: Doom 3 on Raspberry Pi 2

Wed Feb 11, 2015 10:00 am

Can you post a link to this Doom 3 ARM port? Does it support OpenGL ES 2.0?
Is it this one: https://github.com/AreaScout/dante-doom3-odroid ?

User avatar
theburntcrumpet
Posts: 5
Joined: Tue Feb 10, 2015 11:27 pm

Re: Doom 3 on Raspberry Pi 2

Wed Feb 11, 2015 10:19 am

Hi there,

Thanks for response. I got the arm build from the repository mentioned here: http://forum.odroid.com/viewtopic.php?f=91&t=5354

It looks as though the port supports OpenGL ES 2.0

Hiradur
Posts: 96
Joined: Fri Mar 01, 2013 10:59 am

Re: Doom 3 on Raspberry Pi 2

Wed Feb 11, 2015 10:56 am

What error message does it show? I don't own a RPi2 yet so I can't really try myself (I could build it on the RPi1 but that wouldn't be fun).

Vanfanel
Posts: 433
Joined: Sat Aug 18, 2012 5:58 pm

Re: Doom 3 on Raspberry Pi 2

Wed Feb 11, 2015 11:01 am

If this source has GLES/GLES2 support, all that's missing is Raspberry Pi EGL context initialization, and the game will be able to send GLES commands and will work.
So if it supports GLES/GLES2 (different from desktop OpenGL!!) then it's easy to make it work on the Pi/Pi2.

User avatar
theburntcrumpet
Posts: 5
Joined: Tue Feb 10, 2015 11:27 pm

Re: Doom 3 on Raspberry Pi 2

Wed Feb 11, 2015 11:11 am

I'm not entirely sure at the moment - I could dump the error message when I get home from work. The error is along the lines of "Error! Failed to initialize OpenGL". I have all of the pk4 files mounted from a memory stick at /home/pi/.doom3/base (probably bad practice to mount here I know) and these seem to get picked up on launch okay

barrybarryk
Posts: 20
Joined: Thu Jul 19, 2012 12:11 pm

Re: Doom 3 on Raspberry Pi 2

Wed Feb 11, 2015 1:25 pm

Compiling from source I get a load errors like this before the compile stops

Code: Select all

/opt/vc/include/interface/vcos/vcos_string.h:109:94: error: ‘use_idStr_Cmpn’ was not declared in this scope
I've no idea what's causing it, though I'd rather chalk it up to some dodgy compile flags before attempting to debug Carmack's code :lol:

User avatar
theburntcrumpet
Posts: 5
Joined: Tue Feb 10, 2015 11:27 pm

Re: Doom 3 on Raspberry Pi 2

Wed Feb 11, 2015 1:51 pm

Yeah I found compiling from source to be a bit of a pain so I installed from the arm deb package. Maybe it does need to be compiled from source though - got the same error as yourself during my source compile attempt

barrybarryk
Posts: 20
Joined: Thu Jul 19, 2012 12:11 pm

Re: Doom 3 on Raspberry Pi 2

Wed Feb 11, 2015 2:04 pm

I just assumed the .deb wouldn't work since it was compiled against the odroid and Mali 400 driver sources. Unfortunately, I don't really know enough about it to track down the compiler problem, though I'd assume the underlying codebase is fine (since it compiles on the odroid) and just think it's something weird going on with the compile options.

Hiradur
Posts: 96
Joined: Fri Mar 01, 2013 10:59 am

Re: Doom 3 on Raspberry Pi 2

Wed Feb 11, 2015 2:11 pm

Don't install the .deb package, compile from the provided source instead.

User avatar
theburntcrumpet
Posts: 5
Joined: Tue Feb 10, 2015 11:27 pm

Re: Doom 3 on Raspberry Pi 2

Wed Feb 11, 2015 3:20 pm

Interesting... Looks like I might have to spend some time learning how to bug fix the build from the error messages etc

barrybarryk
Posts: 20
Joined: Thu Jul 19, 2012 12:11 pm

Re: Doom 3 on Raspberry Pi 2

Wed Feb 11, 2015 4:38 pm

This is how far I get trying to build just the "core" with one thread.

Code: Select all

[email protected] ~/dante-doom3-odroid/neo $ ./odroid.sh 
Already up-to-date.
Do you wish to build doom3 to play video with ffmpeg decoder ?n
scons: Reading SConscript files ...
Loading build configuration from site.conf:
  BUILD_GAMEPAK='0'
  JOBS='1'
  TARGET_OPENGL='0'
  TARGET_ANDROID='0'
  DEDICATED='0'
  SILENT='0'
  ID_MCHECK='2'
  BUILD_ROOT='build'
  ALSA='1'
  NDK=''
  CC='arm-linux-gnueabihf-gcc-4.8'
  TARGET_D3XP='0'
  TARGET_CORE='1'
  BUILD='release'
  TARGET_GAME='0'
  TARGET_MONO='0'
  BASEFLAGS='-I/usr/include/arm-linux-gnueabihf -I/usr/include -I/usr/local/include -L/usr/local/lib -I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads'
  CXX='arm-linux-gnueabihf-g++-4.8'
  NOCURL='0'
  DEBUG_MEMORY='0'
  IDNET_HOST=''
  LIBC_MALLOC='1'
  ID_NOLANADDRESS='0'
  TARGET_DEMO='0'
Command line: CC='arm-linux-gnueabihf-gcc-4.8'
Command line: NOCURL='0'
Command line: TARGET_D3XP='0'
Command line: TARGET_CORE='1'
Command line: TARGET_ANDROID='0'
Command line: TARGET_DEMO='0'
Command line: BASEFLAGS='-I/usr/include/arm-linux-gnueabihf -I/usr/include -I/usr/local/include -L/usr/local/lib -I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads'
Command line: CXX='arm-linux-gnueabihf-g++-4.8'
Command line: BUILD='release'
Command line: TARGET_GAME='0'
Command line: ARCH='arm'
Command line: USE_FFMPEG='0'
scons: done reading SConscript files.
scons: Building targets ...
scons: building associated VariantDir targets: build/release/core
arm-linux-gnueabihf-g++-4.8 -o build/release/core/TypeInfo/TypeInfoGen.o -c -I/usr/include/arm-linux-gnueabihf -I/usr/include -I/usr/local/include -L/usr/local/lib -I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads -pipe -Wall -Wno-sign-compare -Wno-unknown-pragmas -Wno-psabi -fmessage-length=0 -fpermissive -D__ODROID__ -falign-functions=32 -falign-loops -falign-labels -falign-jumps -fomit-frame-pointer -ffast-math -fexpensive-optimizations -finline -finline-functions -mstructure-size-boundary=32 -frename-registers -Wunused-but-set-variable -fvisibility=hidden -O3 -marm -march=armv7-a -mfpu=neon -ffast-math -fno-unsafe-math-optimizations -fomit-frame-pointer -fvisibility=hidden -DGL_ES_VERSION_2_0 -DXTHREADS -fno-strict-aliasing -D__DOOM_DLL__ TypeInfo/TypeInfoGen.cpp
In file included from /opt/vc/include/interface/vcos/vcos.h:116:0,
                 from /opt/vc/include/interface/vmcs_host/vc_dispmanx.h:33,
                 from /opt/vc/include/EGL/eglplatform.h:110,
                 from /opt/vc/include/EGL/egl.h:36,
                 from TypeInfo/../idlib/../renderer/qgl.h:44,
                 from TypeInfo/../idlib/precompiled.h:144,
                 from TypeInfo/TypeInfoGen.cpp:28:
/opt/vc/include/interface/vcos/pthreads/vcos_platform.h: In function ‘void vcos_event_signal(VCOS_EVENT_T*)’:
/opt/vc/include/interface/vcos/pthreads/vcos_platform.h:535:8: warning: variable ‘ok’ set but not used [-Wunused-but-set-variable]
    int ok = 0;
        ^
/opt/vc/include/interface/vcos/pthreads/vcos_platform.h: In function ‘int vcos_strcasecmp(const char*, const char*)’:
/opt/vc/include/interface/vcos/pthreads/vcos_platform.h:596:27: error: ‘use_idStr_Icmp’ was not declared in this scope
    return strcasecmp(s1,s2);
                           ^
In file included from /opt/vc/include/interface/vcos/vcos.h:143:0,
                 from /opt/vc/include/interface/vmcs_host/vc_dispmanx.h:33,
                 from /opt/vc/include/EGL/eglplatform.h:110,
                 from /opt/vc/include/EGL/egl.h:36,
                 from TypeInfo/../idlib/../renderer/qgl.h:44,
                 from TypeInfo/../idlib/precompiled.h:144,
                 from TypeInfo/TypeInfoGen.cpp:28:
/opt/vc/include/interface/vcos/vcos_string.h: In function ‘int vcos_strncmp(const char*, const char*, size_t)’:
/opt/vc/include/interface/vcos/vcos_string.h:109:94: error: ‘use_idStr_Cmpn’ was not declared in this scope
 int vcos_strncmp(const char *cs, const char *ct, size_t count) { return strncmp(cs, ct, count); }
                                                                                              ^
scons: *** [build/release/core/TypeInfo/TypeInfoGen.o] Error 1
scons: building terminated because of errors.
Similar fails on the first file if I try build the game (or core & game). It looks like it's not traversing the build tree properly but I've no idea why or how to fix it.

Update: I added some verbose logging for the scons script. It looks like no matter what options you select or pass through for the compile, when it's sending a file list to the compiler it always labels the idlib files (like Str.h which contains the declarations for the errors above) as already compiled and with the .o extension so the compiler can't find them to include them.

I still have no idea how to fix it though, scons is still a mystery to me, but narrowing it down atleast.

User avatar
Forgotten01
Posts: 162
Joined: Sun Dec 01, 2013 6:06 pm

Re: Doom 3 on Raspberry Pi 2

Thu Feb 12, 2015 10:19 pm

Hello there, I just wanted to point out that with some other quake based games on the pi like JK2 and RtcW, OpenGL fails to initialise for me too, so this may be a problem with raspbian itself, or something within raspbian. But maybe this is just me...... So take it as you will :D
Engineers like to solve problems. If there are no problems handily available, they will create their own problems.
Scott Adams

Henrik42
Posts: 19
Joined: Sat Sep 14, 2013 12:04 pm

Re: Doom 3 on Raspberry Pi 2

Mon Feb 16, 2015 8:08 pm

I managed to get it to compile and start.

ImageImageImageImage

As you can see by my frame rates there is still some work to be done. None of the quality settings seems to have any influence on the frame rate. Changing the resolution doesn't help either. I tried it at 320x200 and it was just as bad as at 1920x1080.
The UI is just as slow as the game.

I logged in with ssh and checked the load:

Code: Select all

top - 19:08:50 up  1:21,  4 users,  load average: 1.48, 1.35, 1.33
Tasks: 113 total,   2 running, 111 sleeping,   0 stopped,   0 zombie
%Cpu(s):  3.8 us,  9.0 sy,  0.0 ni, 87.1 id,  0.0 wa,  0.0 hi,  0.2 si,  0.0 st
KiB Mem:    494560 total,   474976 used,    19584 free,     1616 buffers
KiB Swap:   102396 total,      296 used,   102100 free,   220188 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                                                                                                                                          
  4362 pi        20   0  280m 166m  13m R  50.3 34.6   8:02.13 doom.arm                                                                                                                                                                                                         
  43 root       1 -19     0    0    0 S  13.4  0.0   2:59.58 VCHIQ-0                                                                                                                                                                                                          
  44 root       1 -19     0    0    0 S   1.0  0.0   0:11.04 VCHIQr-0                                                                                                                                                                                                         
  4372 pi        20   0  4776 2176 1724 R   1.0  0.4   0:05.66 top             
 
It doesn't use more than about 50% of one core despite only doing 1 fps. I would seem like most of the time is spent waiting for something. Hopefully it won't be too difficult to track down.

Also when I start a new game the game hangs with a black screen at the start with the CPU almost idle. It works if I load a saved game. Also Doom 3: Resurrection of Evil works without hanging.

I have uploaded my sources here:
http://henrike.se/d3/dante-doom3-odroid ... _pi.tar.gz

I copied odroid.sh to raspberry_pi.sh and changed the options for the pi. I also had to change SConstruct to get it to link.

The files with the most important changes are sys/linux/gles2.cpp and renderer/draw_glsl.cpp.
Use KDiff3 or meld or some similar program to see all the changes against the original sources.

This is the config I used:
http://henrike.se/d3/DoomConfig.cfg

Please feel free to experiment and if someone would like to start a project on github and maintain it that would be great as I don't have time to put much work into this.

Hiradur
Posts: 96
Joined: Fri Mar 01, 2013 10:59 am

Re: Doom 3 on Raspberry Pi 2

Mon Feb 16, 2015 9:07 pm

Valgrind with callgrind option in combination with KCachegrind is great to find bottlenecks in programs (compile with debug information).

User avatar
jeanleflambeur
Posts: 157
Joined: Mon Jun 16, 2014 6:07 am
Contact: Website

Re: Doom 3 on Raspberry Pi 2

Mon Feb 16, 2015 11:11 pm

Congrats on getting it to run. The Pi 2 costs less than half of what the game used to cost when it came out :)

My guess is that the low fps is due to too many draw calls. Games ported from PC tend to suffer from this a lot.
Also fillrate doesn't seem to be the issue, at least not yet. At 30 fps you'll use 30 times as much fillrate so it might become an issue then.

You could search for glDrawElements, increment a global int there and then every second print this value.
If it's bigger than 4-500 per second it might explain the FPS. Next would be to identify the cause.

Another cause could be the stencil shadows volumes that are created on CPU and submitted to the GPU per frame. Hopefully there's a way to disable them and test.

j0z0r
Posts: 52
Joined: Fri Oct 28, 2011 5:46 pm

Re: Doom 3 on Raspberry Pi 2

Tue Feb 17, 2015 12:58 am

I can't wait for my Pi 2 to come in, there's so many new games and emulators that are now within reach! I'm following this thread, so keep us updated on any new developments

User avatar
Forgotten01
Posts: 162
Joined: Sun Dec 01, 2013 6:06 pm

Re: Doom 3 on Raspberry Pi 2

Mon Mar 23, 2015 5:15 pm

is there any progress with this project? if not what needs doing? very interested here :D
Engineers like to solve problems. If there are no problems handily available, they will create their own problems.
Scott Adams

zandzak
Posts: 1
Joined: Wed Apr 15, 2015 6:29 am

Re: Doom 3 on Raspberry Pi 2

Wed Apr 15, 2015 6:59 am

Forgotten01 wrote:is there any progress with this project? if not what needs doing? very interested here :D
Yes, I have gotten the Doom3 code to compile on raspbian as well. I've found that Doom3 uses X11 for keyboard, video, mouse in/output. The problem is that we do not have 3D support on the VideoCore4 X11 display driver (yet?). I'd say there are two possibilities:

- Make Doom3 not use X11 for KVM in/output but instead the same in/output methods as Quake3 (this means rewriting a whole bunch of Doom3 code.
- Create a VideoCore4 3D driver for X11.

Because there is existing driver code for the VideoCore4, creating an X11 driver seems the most viable option to me? Anyone have comments on this?

fsck
Posts: 26
Joined: Mon Feb 23, 2015 4:49 pm

Re: Doom 3 on Raspberry Pi 2

Mon Apr 20, 2015 11:20 pm

zandzak wrote: Yes, I have gotten the Doom3 code to compile on raspbian as well. I've found that Doom3 uses X11 for keyboard, video, mouse in/output. The problem is that we do not have 3D support on the VideoCore4 X11 display driver (yet?).
But Henrik42 already got it running? What's the problem?
viewtopic.php?p=696713&sid=5ed45bd8eb8c ... 88#p696713

Metzelmaennchen
Posts: 4
Joined: Sun Jun 24, 2012 11:34 pm

Re: Doom 3 on Raspberry Pi 2

Tue Apr 21, 2015 4:30 pm

So I will step in here, too. Kind greetings from Germany!
zandzak wrote:I've found that Doom3 uses X11 for keyboard, video, mouse in/output.
Cannot confirm that, according to my logs it uses the VideoCore HW.

Code: Select all

GL_RENDERER: VideoCore IV HW
It uses X11 for input but opens a fullscreen EGL display in front of X11

I was able to compile doom3 with henriks package...
But even the main screen rendering mars in background is stuttering.
Having a look at the GL calls I can See that the data is pushed in small chunks to the gfx which results in a lot of calls for each frame just to upload the data (It's like the nvidia driver works when filling vbos, upload in small chunks).
I will try to go with bigger allocs/buffer small chunks in the vertexcache now... Let's See.
As there is no draw call in between, this should probably work.

The rest ist just plain drawing, okay there are a lot of redundant calls to disable/enablvertexarray but that should do so much.
It cannot get better due to the lack of OES_vertex_array_objects so every draw call will set up its own attribute/uniform set as required.
Due to the fact that other gles2 gfx seem to have no real problem I currently have the feeling for a bad driver. Sysprof shows too much action in vhciq...
Again, there are a lot of gl calls, we are talking about ~3400 per frame. But come on, other gles2 gfx are dealing with that!
I've read in this topic that more than 4 glDraw* are not good, I cannot guess that this is true. Keeping in mind that no instancing is possible on this gfx and we want to draw several models at different space with different textures, there is need to switch the call sometimes as this info needs to be provided via uniforms.
Otherwise you need to pack this info into the vertex stream which in contrast needs more memory streamed between cpu and gpu. I don't know where the limits are here, but these are just my thoughts. Correct me if I'm wrong and point me into the right direction.

I can provide sysprof and apitrace logs if a bcm dev is currently floating around and wants to have a look.
EDIT: apitrace attached

Next step would be to redefine some functions like glBindBuffer or glEnableVertexAttribArray. A lot of times the same buffer is bound and one could detect if the driver stalls here if the same buffer is bound again or such stupid things.
The same counts for glEnableV*, most of the time 1,5 are enabled/disabled and the same for the next draw call. This could be buffered. Only disable when not needed and not disable when not used any more.

This could drop a significant amount of calls. Upload data at beginning of frame are 200 calls, rest is 3100 (minus some general settings), each draw calls needs ~18 gl calls around so we do have ~172 glDraw* calls.
Disable/EnableVertexAttrib will be called four times each call, so there is a chance of removing around 680 state changes per frame. BindBuffer is called one time per drawcall, keeping in mind that we sometimes need to change the buffer there are 150 calls reduntant. So we could remove ~1000 gl calls per frame...

Bufferdata at beginning of frame, maybe mapping the buffer once until its full would be an easy thing to implement. But my experience says nooo, mapping buffer has bad performance if you cannot do it with unsync flag.

Currently I'm running on ubuntu 14.04, but that shouldn't make a great difference to Raspbian.
I have also disabled sound as I got a lot of erros from it. Afterwards it worked a little better, but still the main screen is stuttering which should work quite smooth.
In contrast my Nexus 7 runs it quite good, but I currently have no clue how powerful are both gfxs in comparison to each other.

apitrace dump : https://www.dropbox.com/s/fk55593ts6shg ... trace?dl=0

EDIT: So far using vbo's seems to decrease performance... loading the data directly in VertexAttribPointer is a heck faster ?? Sorry but why is the driver stalling when using vbo's ??
Does anyone know where I can submit bugs to bcm? I can provide a simple test application for them! This isn't normal, vbo's should increase your performance and not reverse ??

crossmodder
Posts: 11
Joined: Wed Mar 11, 2015 9:36 am

Re: Doom 3 on Raspberry Pi 2

Thu Apr 23, 2015 6:20 am

This is amazing... considering its running at 50% CPU on a single core; does the engine support multicore SMP? And whatabout turning off the bells and whistles? effects etc?

fsck
Posts: 26
Joined: Mon Feb 23, 2015 4:49 pm

Re: Doom 3 on Raspberry Pi 2

Wed Apr 29, 2015 2:29 pm

Metzelmaennchen, you may find help in the OpenGLES section: viewforum.php?f=68

I believe user jamesh is the one currently working on the graphics drivers.

Metzelmaennchen
Posts: 4
Joined: Sun Jun 24, 2012 11:34 pm

Re: Doom 3 on Raspberry Pi 2

Wed May 06, 2015 10:09 am

Thanks for the hint :) But currently I'm trying to sort some things out before contacting other people... too much stuff I need to investigate first. But for the time being, here is a little patch, just apply it in the neo folder.

Code: Select all

patch -p0 < raspi.1.patch 

It will get rid of some redundant state changes. It's far from being complete but at least it points into the correct direction.
You should see a 'little' speed up in game ;)
It's also advisable to set the image cache inside DoomConfig.txt to zero and reduce the sizes for specular and bump to 128. Looks not quite good but let's get some good frame rate before doing the visual candy ;)

I will have a look at the EGL and GLESv2 libs now. There is a lot of work going on just eating cpu time, this is the header of enablevertexattibarray for example

Code: Select all

   CLIENT_THREAD_STATE_T *thread = CLIENT_GET_THREAD_STATE();
   if (IS_OPENGLES_API(thread, api))
   {
      GLXX_CLIENT_STATE_T *state = GLXX_GET_CLIENT_STATE(thread);
      if (attrib_translate(state, &indx))
and attrib_translate is again a function checking for gles1 or gles2 state... this could be a lot smaller and without all the assert checks...
If I do something wrong the GPU will just lock up in a bad case instead of the driver reporting a bad value or something like this...
But this can be sorted out afterwards.
But currently there is a lot of overhead everywhere around :(
Attachments
patch.tar.bz2
(2.56 KiB) Downloaded 119 times

Metzelmaennchen
Posts: 4
Joined: Sun Jun 24, 2012 11:34 pm

Re: Doom 3 on Raspberry Pi 2

Sat May 09, 2015 9:18 pm

Here we go again ;) Now we are talking...
https://www.youtube.com/watch?v=4s63Of4bstg

Return to “Gaming”