Search / View

[TheDoctor]

Well the good news is the R-Pi SG server functions!

Congrats. Try to play with three bots and tell us, what's the maximum peak of CPU utilization during one of the larger and more complex maps of SG, e.g. dm_alamo_2.

Also, do you plan to try out the free hosting offer you and /dev/random stumbled upon? If so, let me know when your server is operational. I like to take a look.

[/dev/random]

As I've said before, I'm not familiar with the RPi and the special libraries it may require. You might try omitting them entirely, since they're likely to be graphics-related anyways.
Out of curiosity, could you post (here or on a pastebin) the warnings as well? Maybe they are related and easy to fix.

When the server has been stress-tested, would you be so kind and post your binary? We could then even create a .deb for the Raspbian users (and include the binary in the plain unified zip download).

[Munny Shot]

@TheDoctor:
Even though I'm testing on my local LAN, I've been really pleasantly surprised at the server performance. However when I checked my stats in response to your query I was even more surprised! This is because I have the Pi set to work with a dynamic cpu governor in the range 350Mhz to 1000MHz (the Pi by default runs at 700MHz) ... BUT for some reason the Smokin' Guns server workload wasn't triggering the CPU off the 350MHz minimum setting!

SETUP: I had already moved /root off the SD card and mounted it on a Sandisk USB pendrive. An external powered USB hard drive would give the best performance of course but I wanted to test with an EDIS compatible arrangement*. The Raspberry Pi was set to run at the stock speed of 700MHz to reflect what others could experience out-of-the-box. All measurements taken with three ssh sessions running in the background, htop and a cpu temp/speed monitoring script.

IDLE: Vanilla Raspbian, observed peak CPU of 7.5% @700MHz with average 6%
SG SERVER: Running dm_alamo_2, observed peak CPU of 79.1% @700MHz with average 58%
... and because I had to find out, an overclock @ 1GHz:
SG SERVER O'CLK: Running dm_alamo_2, observed peak CPU 57% @1000MHz with average 42%

At no time during my tests did I perceive any server lag (even at 350MHz), althought the more complicated maps dropped the fps on my 7-year old laptop client. Notwithstanding, the Pi never drew more than 4.0W peak (measured by meter) and there's scope for boosting performance further by overclocking/over-volting and trimming all unnecessary running processes from the Raspbian build.

* No plans for this Pi to go to EDIS just yet .... further tests to conduct

+++

@/dev/random:
Here is the terminal output during compile on Pastebin. FWIW there's interest in Smokin' Guns on the Pi forums. Now it looks like we have a working ARM-based server, I guess a full client port would be cool for the community. Please let me know if I can be of further assistance.

Of course I'd be more than happy to provide the compiled ARM server binary (thanks to your help). I've posted it here for now
and I'll try and get some 'proper' testing done this weekend (my ADSL connection being the real limiting factor).


Cheers all

[/dev/random]

Just a quick post to remind myself to edit it lateron.

How many clients or bots were connected to your server during your tests?
Note to self; maybe one can reduce idle CPU usage even more with com_busyWait 0.

Thanks for posting the warnings as well. They are harmless, but could be fixed anyways. Will need to check with upstream ioquake3 whether they already have fixes (I guess they have).

I'll grab a copy of that binary of yours as well, thanks. If everythings works well, this'll most likely be the final binary, unless someone wants to change something about the build process (hint: libraries linked)?

It's good to hear that there's interest in the official forums. If I have some time to spend, I might try registering over there and ask for further input and/or testers.

A full client port should be possible, but Smokin' Guns added some optional OpenGL-based features, which we'd either need to omit during the port or have someone with OpenGL ES knowledge to port them as well. I guess it'd be more practical to join upstream ioquake3, since they're currently working on a new, alternative renderer anyways, so there are experienced coders.

[Munny Shot]

How many clients or bots were connected to your server during your tests?

Self-testing there were three bots and myself. I'm hoping to get some further testing in with "live" players over this weekend.

Some R-pi forum links mentioning Smokin' Guns: formally requested here and here (bottom of page 1) and also here. (honourable mention).

Understand re the potential extra work in resolving the OpenGL divergence issue. I take it that this means you the developers now need to discuss which of the two directions you feel you should follow (assuming Raspberry Pi/ARM in general will be supported moving forward)?

[/dev/random]

Understand re the potential extra work in resolving the OpenGL divergence issue. I take it that this means you the developers now need to discuss which of the two directions you feel you should follow (assuming Raspberry Pi/ARM in general will be supported moving forward)?

I am not one of the official developers, in fact I am just a random forum lurker. Your topic just caught my eye, since it seemed easy to do (and turns out it is) and you also are the right kind of person for "assistance".

Keeping the above in mind, the following is just guesswork of mine;
ARM in general is a interesting platform to keep an eye on. The basic groundwork to support this (CPU-)platform has already been laid out by the folks of ioquake3 (plus the usual POSIX compatibility).

The client on the other hand is something that's a bit trickier. Even with an open-source userland it does not make OpenGL ES development easier. That being said, I haven't even done OpenGL development myself. From what I've heard and seen the Smokin' Guns developers didn't develop the optional framebuffer code themselves. As such I think it's unlikely to expect the Smokin' Guns team to develop or port the engine changes on their own. I'd rather expect them to either get the ioquake3 team and committers to push RPi/OpenGL ES development or merge one of the existing (io)quake3 ports with their Smokin' Guns codebase.

The same principles apply to any other (io)quake3 based game. Their coder teams usually lack the knowledge and manpower to do such development (a fact, not meant as insult). This means if one can implement it into ioquake3, it is much more likely to get merged into the individual forks.
On a sidenote; other (ARM based) (mobile) devices also have the issue of requiring custom controls (touch based, no mouse or hardware keyboard etc.).

P.S.: On your stripped-down system, you could try a "sudo apt-get build-dep quake3" to get the required libraries and tools to build both a client and dedicated server. If I'm not entirely mistaken (not a Debian user myself) the quake3 package should be using ioquake3 behind the scenes, so you'd also get stuff like libcurl and libsdl, which weren't used by id Quake 3.
The libraries should most likely be properly included by extending the Makefile for ARM and appending them to CLIENT_LIBS/RENDERER_LIBS instead of linking them unconditionally via a build script.

[Munny Shot]

I'm writing this mostly as a summary to make sure I've understood you correctly and to reflect my thoughts sequentially as I read your reply.

I am not one of the official developers, in fact I am just a random forum lurker.

Ah ok. I think what threw me is when you requested the binary for inclusion, I naturally assumed you were on the Dev team

From what I've heard and seen the Smokin' Guns developers didn't develop the optional framebuffer code themselves. As such I think it's unlikely to expect the Smokin' Guns team to develop or port the engine changes on their own.

It might be the beer last night, or it be knocking on my ceiling of understanding about coding, but when I read this I was confused. Are you saying the SG customisations are purely cosmetic (i.e. the OpenGL stuff is the same as vanilla ioquake3)? Because if so then surely we could get a working client for SG along the lines of the ioquake3 port for Pi could we not?

Then during the last part about the makefile, you go on to essentially propose this: if I've got this right you're saying that the current Quake3 client for RasPi is a 'hack' by using a custom build file rather than doing it properly via a makefile, right? If this is the case then we should be able to get a working SG client by using the same 'hack' but medium term we should look to get the relevant changes included upstream so it can be copiled properly.

[/dev/random]

Are you saying the SG customisations are purely cosmetic (i.e. the OpenGL stuff is the same as vanilla ioquake3)? Because if so then surely we could get a working client for SG along the lines of the ioquake3 port for Pi could we not?

Smokin' Guns has some optional framebuffer/shader code for effects like "rotoscope" (that should be its name in the options). It's completely optional and iirc it defaults to off. All the remaining OpenGL code (which is a lot) is exactly the same as the opengl1 renderer in ioquake3.

Then during the last part about the makefile, you go on to essentially propose this: if I've got this right you're saying that the current Quake3 client for RasPi is a 'hack' by using a custom build file rather than doing it properly via a makefile, right? If this is the case then we should be able to get a working SG client by using the same 'hack' but medium term we should look to get the relevant changes included upstream so it can be copiled properly.

The current method of using the build.sh on top of the Makefile is more or less of a hack. The required libraries are hardcoded into LDFLAGS, which means they are linked into both the server and client when compiling.
The proper way would be to modify the Makefile and add those libraries only to those sections where the client is being compiled.
Building a complete client requires more changes, I've only posted the VCMODS_REPLACETRIG one that's needed by the server as well. The complete amount of changes in the RPi quake3 repository includes changes to the (OpenGL) code as well as small changes to the Makefile (though not those to properly include the required libraries).

Thus the approach I recommend would be taking those RPi specific changes and apply them to a current ioquake3 codebase. Then post that patch for discussion/improvement at the ioq3 bugzilla. Once it's been included in ioq3, the Smokin' Guns devs would need to pull the resulting changes (and any other ioq3 based game could do so as well).
The only issue I see along that path is that iirc none of the core ioq3 devs (those who can commit to the codebase) has an RPi to actually test 3rd party patches. Maybe donate one to @icculus?

[Munny Shot]

Well a pretty successful testing session this afternoon with a group of friends. Left the maps cycling and never had a single problem (inc alamo_2, newtown); no freezes, slowdowns, unexplained glitches in the couple of hours we played. Dead chuffed so I am

[Munny Shot]

The current method of using the build.sh on top of the Makefile is more or less of a hack. The required libraries are hardcoded into LDFLAGS, which means they are linked into both the server and client when compiling. <SNIP>

Thanks for taking the time out to provide explanations. I'm going to have a play during the week.

Levity aside, quite honestly I wonder if the RasPi foundation could spare a unit to send to Icculus. After all their stated target is inspiring kids, and there's no better welcome mat than getting them into a few games

[Munny Shot]

@/dev/random:
I was curious to see whether I could compile a graphical client over the weekend with the pointers you had given me, but my lack of knowledge bit me somewhere. The RasPi build platform was as before but I also pulled in the libsdl1.2-dev package and I set the available GPU memory to 128MB (to be safe). I then tried to piece together a new build.sh by comparing the successful server script with the client example provided in the Raspberry Pi ioquake3 git code. But this time the compilation failed (results below). I was scratching my head since the paths to the required libraries appear to be correct, I'd added back the missing flags and I assumed that the "cannot open display" error (below) isn't just permissions related (I checked with sudo) .... then I remembered

Mr jump-the-gun here read back toward the start of this thread to where you alluded to other diffs found when you compared the "working on RasPi" ioquake3 git code with the Smokin guns git code. Since we were concentrating on a working server I had glossed over this. So in your opinion, is it down to diffs missed or have I made an error?


++RESULTS++
build.sh I used:

Code: Select all

#!/bin/bash
# this script builds smoking guns arm client
# invoke with ./build.sh
# or ./build.sh clean to clean before build

# directory containing the ARM shared libraries (rootfs, lib/ of SD card)
ARM_LIBS=/opt/vc/lib
SDL_LIB=lib

# directory to find khronos linux make files (with include/ containing
# headers! Make needs them.)
INCLUDES="-I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads"

# prefix of arm cross compiler installed
#CROSS_COMPILE=bcm2708-

# clean
if [ $# -ge 1 ] && [ $1 = clean ]; then
   echo "clean build"
   rm -rf build/*
fi

make -j4 -f Makefile ARCH=arm \
        CC=""$CROSS_COMPILE"gcc" USE_SVN=0 USE_CURL=0 USE_OPENAL=0 \
        CFLAGS="-DVCMODS_MISC -DVCMODS_OPENGLES -DVCMODS_DEPTH DVCMODS_REPLACETRIG $INCLUDES" \
        LDFLAGS="-L"$ARM_LIBS" -L$SDL_LIB -lSDL -lvchostif -lvmcs_rpc_client -lvcfiled_check -lbcm_host -lkhrn_static -lvchiq_arm -lopenmaxil -lEGL -lGLESv2 -lvcos -lrt"

exit 0


After an hour, the compilation finished with warnings but no errors (output log on Pastebin).

On execution I get the following:

Code: Select all

pi@raspberrypi ~ $ sgserver/smokinguns.arm
Smokin' Guns 1.1 linux-arm Nov 18 2012
----- FS_Startup -----
Current search path:
/root/.smokinguns/smokinguns
./smokinguns/sg_pak0.pk3 (2562 files)
./smokinguns/included_fanpak0.pk3 (224 files)
./smokinguns
/root/.smokinguns/baseq3
./baseq3/pak0.pk3 (101 files)
./baseq3

----------------------
2887 files in pk3 files
execing default.cfg
couldn't exec q3config.cfg
couldn't exec autoexec.cfg
Hunk_Clear: reset the hunk ok

(zenity:2160): Gtk-WARNING **: cannot open display:
----- Client Initialization -----
Couldn't read q3history.
----- Initializing Renderer ----
-------------------------------
Smokin' Guns checks on
QKEY found.
----- Client Initialization Complete -----
----- R_Init -----
SDL using driver "fbcon"
Initializing OpenGL display
Estimated display aspect: 1.788
...setting mode 4: 800 600
Available modes: '1824x1020 640x480 768x576 800x600 1024x768 1152x864 1280x960 1600x1200 1280x1024 1024x1024'
Couldn't get a visual
...WARNING: could not set the given mode (4)
Initializing OpenGL display
...setting mode 4: 800 600
Available modes: '1824x1020 640x480 768x576 800x600 1024x768 1152x864 1280x960 1600x1200 1280x1024 1024x1024'
Couldn't get a visual
...WARNING: could not set the given mode (4)
Setting r_mode 4 failed, falling back on r_mode 3
Initializing OpenGL display
...setting mode 3: 640 480
Available modes: '1824x1020 640x480 768x576 800x600 1024x768 1152x864 1280x960 1600x1200 1280x1024 1024x1024'
Couldn't get a visual
...WARNING: could not set the given mode (3)
----- Client Shutdown (Client fatal crashed: GLimp_Init() - could not load OpenGL subsystem) -----
RE_Shutdown( 1 )
-----------------------
GLimp_Init() - could not load OpenGL subsystem

(zenity:2166): Gtk-WARNING **: cannot open display:
pi@raspberrypi ~ $

++FOOTNOTE 1++
I noticed that the byte size of the new dedicated arm binary differs from the one successfully compiled previously:
Known Good: 856450 Nov 14 20:53 smokinguns_dedicated.arm
Untested: 856660 Nov 18 20:51 smokinguns_dedicated.arm

++FOOTNOTE 2++
Incidentally, in the ioquake3 git folder with the build.sh script there is a build_arm.sh that contains the following (unsure if this is relevant):

Code: Select all

make ARCH=arm CC=arm-none-linux-gnueabi-gcc USE_CURL=0 USE_OPENAL=0 CFLAGS="-DVCMODS_MISC -DVCMODS_NOSDL -DVCMODS_OPENGLES -DVCMODS_DEPTH -DVCMODS_STARTKHRONOS -DVCMODS_REPLACETRIG -I../../../../interface/khronos/include"

Cheers.

[/dev/random]

Sorry for the delay. My main computer just died, thus I'm currently on a Windows (XP ) box from time to time.
I'll report back lateron as soon as I got a replacement box with a proper Linux on it.

The error very much looks like some OpenGL (ES) related code is not working as indended, which means it's just missing.
Like you've noticed, the RPi Quake 3 port contains more changes to the code, and I have only posted the one that's important to build the dedicated server.
The remaining pieces are #ifdef'ed and activated via the -DVCMODS_OPENGLES etc. compiler flags.

I'll post a full RPi Q3 port diff compatible with the Smokin' Guns git code as soon as my box is running again, promise
In case you don't hear anything from me (within say, the next 2 weeks), feel free to bump this thread. I'm sure others won't mind.

On a sidenote, have you tried cross-compiling for the RPi? Generic cross-compilation for ARM itself is not that difficult, I just don't know what you'd need in addition to cover RPi specifics. This'd cut down your compile times big time.

[Munny Shot]

Sorry for the delay. My main computer just died

No worries - sorry to hear of your woes.

I'll post a full RPi Q3 port diff compatible with the Smokin' Guns git code as soon as my box is running again, promise

Thanks very much, you're a decent chap. As I said, it doesn't affect me but it would make a nice additonal option for the RasPi community.

On a sidenote, have you tried cross-compiling for the RPi? .... This'd cut down your compile times big time.

I haven't no. Although this last iteration failed, the whole thing still took under an hour on the Pi, I can keep all the relevant code in one place on one machine and I can just set-it & forget-it whilst I get on with "other stuff", so I never really considered it

As a footnote, I still use an old laptop sporting a Pentium M 1.7 (Dothan). So although I expect it would be quicker, I don't think it would be an order of magnitude quicker, would it?

[Munny Shot]

Just thought I'd register here for anyone interested in this thread that I've been testing voip. I've been using mumble up to now so hadn't tried it before but seeing that there was a built-in voip facility I was curious to see if it would work. I just added the server cvar "set sv_voip 1" to the config and then tested on my home lan with 2 clients connected: a windows client and a linux client. All seems to function.

[Munny Shot]

FYI not unsurprisingly, EDIS have ceased the free RasPi CoLo offer. It also appears that the owner, William, is having legal difficulties after being held responsible for illegal traffic coming from his TOR exit. More here for interested parties