
Quake III bounty: we have a winner - benn_88
http://www.raspberrypi.org/archives/6561
======
raverbashing
"We need plenty of space to build the kernel. Compiling will take around 12
hours, so it is helpful to overclock the Pi for this task."

Or, you know, use a cross-compiler?

~~~
warsheep
You probably already know this, but setting up a cross-compiler toolchain is a
super annoying task, and is very dependent on the distro you're using. I'm
sure the author knows about cross-compiling, but he probably preferred clear
instructions that work for any RPi user.

There might be even stronger reasons to not use cross-compilers such as weird
bugs or compiler version compatibility issues.

~~~
captainmuon
I wonder why its so hard? I once built a modern gcc + glibc in my home
directory on an older linux (to be able to run modern programs), and it was
mostly "relocatable" or "portable" (what I mean is that you could copy it
around and run it from other directories).

Couldn't somebody build a full cross-compiler toolchain as "relocatable"
binaries, depending on an older kernel, and then just offer that as a binary
download to run on most recent distributions? It's not a typical way to
distribute a linux application, but it should work in principle.

~~~
sarnowski
I suggest looking at LinuxFromScratch[0], especially II.5. It's hard to do a
"real" cross-platform compiler because your target system might not only be a
different architecture but also has different libraries on the system with
which the compiler has to work. All in all, doing it right and being able to
ship binaries is a lot of work and constant maintenance as your target system,
in this case Raspbian, also changes their libraries.

[0]
[http://www.linuxfromscratch.org/lfs/view/stable/](http://www.linuxfromscratch.org/lfs/view/stable/)

------
fit2rule
Very cool - hope this becomes a template for other companies as to how to
properly handle open sourcing the various important parts of the stack in the
future. Seems like this is a very smart move by Broadcom - as demonstrated by
the community response, which is mostly positive.

~~~
hrjet
It is nice, but a little late for many people. Couple of years back when I was
investigating the RaPi for building a video recorder, the lack of open video
drivers prevented me (and apparently many in the forums) from integrating
camera modules. I ended up using the TI boards, which have open source stacks
since a long time now.

~~~
beagle3
The RPi video core driver might not be fully open, but it has a usable camera
API and video compression API.

Which boards are those? I didn't find a single board that had an open video
driver - not Allwinner based ones, not Beagle Bone Black (no encoding/decoding
hardware at all).

~~~
hrjet
I am not familiar with Beagle Bone, but if it doesn't have encoding/decoding
hardware, how did you expect a driver for it?

The APIs in RPi that you mention are high-level APIs. Before Broadcom open-
sourced the implementation (which they called IDL I think), it was not
possible for RPI users to interface a custom camera module with RPi (without
signing NDAs with Broadcom).

After some investigation, I went with LeopardBoard. I haven't progressed far
on the project [1], but AFAIK, it and other boards had completely open stacks.

[1] I am stuck with a simple issue: Not able to get the right serial cable to
connect to the board.

~~~
beagle3
I did not expect drivers for Beagle Bone, but I preemptively responded to "But
BeagleBone is better" responses, which I've gotten every single time when
discussing RasPi limitations.

> it was not possible for RPI users to interface a custom camera module with
> RPi

That's correct. But the RPi's camera modules (standard and noir) are very well
supported (even if source is not all open), and they work very well -
reasonable quality 5MP@15fps, FullHD@30FPS, 720p@60fps, with access to the
encoding/decoding pipeline that allows you to e.g. insert an overlay _before_
h264 encoding the original stream (in fact, that's the most cost effective way
to add overlays to an already encoded 1080p h264 video even if you don't
connect a camera).

I find that it's pretty hard to beat RPi on price, support,
functionality/price, community, openness etc. in general - to the point that
if the RPi is not the right solution for a project, it is unlikely that any of
its competitors (low power sub $100 cpu+gpu+network on a small form factor)
is.

------
Luc
How very cool. I didn't see any mention of the frames per second that can be
expected other than the 133 FPS in the screenshot, but I assume that's not
from a Raspberry Pi!

~~~
buro9
The screenshot comes from here:

[http://blogs.wefrag.com/cedzekill3r/2010/04/24/fps-engine-
id...](http://blogs.wefrag.com/cedzekill3r/2010/04/24/fps-engine-id-tech-
deuxieme-partie/)

Definitely not a Pi.

~~~
johnchristopher
Haha, is that the day HN meets NoFrag ? :)

------
mk3
What interests me is what are implications for general computing performance
while using GUI/xServer on raspbian or raspBMC? As I was told rPi has
ridiculously powerful GPU compared to processor, but basically it's unusable
due to lack of proper driver support. With such quantity of Raspberry Pis sold
one would expect more support from Broadcom.

~~~
dannypgh
Not sure if you saw
[http://www.raspberrypi.org/archives/6299](http://www.raspberrypi.org/archives/6299)
but even before then I'm not sure I would imply that Broadcom hasn't been
supportive. The thing was designed by someone employed full-time as a Broadcom
engineer, after all.

------
Pxtl
I don't know much about the q3 infrastructure - does Q3 use DLL mods or some
kind of bytecode? I'm curious if this means that all the Q3-based standalone
games - OpenArena, Smokin' Guns, Q3Rally, etc. can get a RasbPi distribution,
that would breathe some new life into those old projects.

~~~
dmead
you've got the option. IIRC, q3 itself generally runs bytecode blobs rolled by
ID and compiled with their speical tool to that does quakeC -> qvm. q3 based
games generally have compiled dll or .so files that may or may not make
external OS or library calls.

source: i cloned orange smoothie pro for jk3

------
Cyph0n
That is so damn cool! I need to get started on my Gameboy Color emulator.

------
dave1010uk
This is really great! I'd be interested to know what framerate the Pi can
output at 1080p.

Someone ported Quake 3 to ARMv6 Symbian smartphones in 2008 [0]. I remember
running this on a Nokia E90 Communicator and the framerate was over 15fps most
of the time.

[0]
[http://koti.mbnet.fi/hinkka/Download.html](http://koti.mbnet.fi/hinkka/Download.html)

~~~
DanBC
The competition rules said at least 20 fps, which seems playable.

~~~
TheCraiggers
I used to run Doom 2 on my 386sx. Doom 2 required a math co-processor, which
the sx didn't have, so I had to use a TSR which emulated one, slowing my CPU
down even more. It probably ran at 1-2 FPS, but it was "playable" enough for
me to spend countless hours playing it. Ahhh, memories...

So yeah, 20 FPS is definitely what I would call playable. ;)

~~~
crwll
Doom (or Doom 2 which had basically the same engine with just bugfixes and
support for Doom 2 entities) didn't actually need an FPU. Even 386DX's or
486SX's had no FPU so no games from the pre-1995 era really depended on it.

I remember Falcon 3.0 and perhaps some other simulation games having support
for FPU for those few who had one however...

------
xedarius
Shocking that the PI can produce 133 fps and my 27" iMac Quad core monster
gets a random and feable 70-90fps.

Nice work though Simon.

~~~
Macuyiko
If you're only getting 70-90 FPS there must be something badly broken with
your iMac. The thing should be able to run at 125 FPS (capped) on high res
without breaking a sweat.

~~~
xedarius
Yeah I agree, I did quite a bit of looking into it as well. In bootcamp I was
able to manage a solid 125fps, yet when in OSX it varied between 70-90.

Although I performed many tests I was never able to get the bottom of it.

~~~
a8000
Apples OpenGL drivers are known to have sub par performance compared to those
for Linux and Windows.

