9 ms·
Quake III bounty: we have a winner
- Luc 13y agoHow 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!
- rangibaby 13y agoIIRC it was highly possible to get 60FPS even on old hardware ~10 years ago.
- Macuyiko 13y agoI remember playing Quake III on a 450Mhz with 60FPS. So yes, it might well be possible.
- frik 13y agoI remember playing Quake 3 on a Pentium 2 233 MHz in 1999 and a Voodoo 3D graphic card (30+ fps). This was the first game that had no software renderer. All other games (til ~2001) including Unreal Tournament just run fine on a Pentium 133 MHz with a software renderer (exceptions were also Outcast and Ultima 9).
- lotharbot 13y ago> "This was the first game that had no software renderer." Descent 3 came out a few months earlier, and also had no software renderer.
- ido 13y agoyep, p2 @ 450mhz + dual voodoo2 cards gave me a lot better than 60fps at the time (don't remember exact numbers). the rpi's gpu is much better than a voodoo2 so I can believe 133fps.
- varkson 13y agoI had a pentium 233 and couldn't run Half Life at any playable FPS. Hell, I had to run Quake 2 at 512x384. SiN was only playable at 384x288, and looked awful.
- frik 13y agoI played Half Life 1 on a Pentium 133 at 640x480 in software mode, run fine (Win95). It also depends on your memory. I had 40MB, but I remember that my initial 8MB RAM were not enough to play even Age of Empire back in 1997 (horrible mouse lags on bigger mid-sized maps).
- varkson 13y agoI think my machine had 32mb, so that was probably it.
- Narishma 13y agoThat 450Mhz CPU of yours is very likely much faster than the 700Mhz CPU on the Pi.
- buro9 13y agoThe screenshot comes from here: http://blogs.wefrag.com/cedzekill3r/2010/04/24/fps-engine-id-tech-deuxieme-partie/ http://blogs.wefrag.com/cedzekill3r/2010/04/24/fps-engine-id... Definitely not a Pi.
- johnchristopher 13y agoHaha, is that the day HN meets NoFrag ? :)
- Cyph0n 13y agoThat is so damn cool! I need to get started on my Gameboy Color emulator.
- fit2rule 13y agoVery 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.
- zanny 13y agoIntel / AMD should be the template - actually hiring FOSS hackers to make you a proper driver for whole-stack support. It is nice that they released an older chips driver code, it is better than nothing (and better than just programming manuals) but we have companies like Qualcomm with the Atheros driver, Intel with their wifi, gpu, and ethernet drivers, and AMD with their chipsets, gpus, etc all contributing engineers in the kernel to make foss drivers, and we shouldn't give any company too much credit for doing any less than the same.
- hrjet 13y agoIt 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 13y agoThe 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 13y agoI 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.
- xedarius 13y agoShocking 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.
- Kliment 13y agoThat image is not from a Pi
- xedarius 13y agoFair enough.
- Macuyiko 13y agoIf 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 13y agoYeah 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 13y agoApples OpenGL drivers are known to have sub par performance compared to those for Linux and Windows.
- Amadiro 13y agoCheck if your iMac defaults to software rendering for some reason.
- raverbashing 13y ago"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 13y agoYou 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.
- pjc50 13y agoIndeed. Either you give distro-specific instructions (long) or you make people build a gcc cross-compiler from scratch (also long) or you gloss over that bit (prone to failure). Many Pi users' only linux system is the Pi.
- ihnorton 13y ago> cross-compiler from scratch (also long) Building GCC shouldn't take more than a couple hours on a modern machine, and it's a one-time cost for a drastic speedup of every subsequent RPi build. So the aggregate time should still be considerably less than 12 hours.
- joezydeco 13y agoVirtualbox is free. Debian is free. Code Sourcery ARM/GCC Lite is free. I've set up ARM crosscompile environments this way in under an hour. This isn't really a superhard thing to do. [EDIT] Vendors do this too. I went to a workshop on the Freescale i.MX line and guess how everyone got the development system? A VMware image on a thumb drive. You don't have to be a hero when it comes to cross-compiling, just get the work done.
- 13y ago
- dave1010uk 13y agoThis 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 13y agoThe competition rules said at least 20 fps, which seems playable.
- TheCraiggers 13y agoI 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 13y agoDoom (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...
- shinratdr 13y agoOn an N95 I remember it running even better than that. That port was actually amazing, and it even supported a full KB & Mouse via Bluetooth.
- ekianjo 13y agoNot sure about the Pi, but the Pandora which has similar ARM class of hardware can run Quake 3 at 25-30+ fps in 800*480 resolution. The GPU of the Pi may be more powerful while its CPU is weaker.
- mk3 13y agoWhat 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 13y agoNot 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.
- chmullig 13y agoSuch quantity? It's like 2 million units. That's roughly equivalent to a mildly popular android phone model.
- Pxtl 13y agoI 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 13y agoyou'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