Sunday 2nd May 2010

Ubuntu 10.04 on HP Compaq nx9005

Ubuntu 10.04 LTS (Lucid Lynx) is the slickest new Ubuntu release in a long time. But installing on my crusty old notebook (an HP Compaq nx9005 of 2003 vintage), I had some trouble with the onboard graphics, the R100-based Radeon IGP 320M.

Running glxgears, I'd get about 20 frames of smooth animation, then a 2 second stall, a single frame, another stall, etc. Even after disabling compiz desktop effects, this jerkiness blighted the entire desktop experience, regardless of whether I was running any 3D applications. The machine seemed to run even hotter and noisier than usual, and games like Beneath A Steel Sky and Armagetron Advanced were unusable.

Tom Morton (creator of open source space sim Pioneer) suggested the culprit. Recent Ubuntus have enabled kernel mode-setting (KMS), which you can disable by passing "nomodeset" to the kernel at boot. Here's how to do this permanently:

Edit /etc/default/grub and add nomodeset to GRUB_CMDLINE_LINUX_DEFAULT, so it ends up looking something like this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"

Then run sudo update-grub and restart the machine. Now Lucid Lynx is usable — even snappy.

Posted by pwr (site) at May 2, 2010, 5:24pm. Category: blog. semipermalink Tags: linux

10 comments

Share this:
Sunday 25th April 2010

Building Boost for iPhone revisited

I upgraded to Snow Leopard, Xcode 3.2.2, etc. I tried to rebuild Boost for the iPhone Simulator, and got this error:

/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.1.3.sdk/usr/include/c++/4.2.1/cmath:49:28: error: bits/c++config.h: No such file or directory

Fixed it by adding architecture=x86 to the bjam command line.

Posted by pwr (site) at April 25, 2010, 1:17pm. Category: blog. semipermalink Tags: iphone, boost

6 comments

Share this:
Monday 15th February 2010

fillratetest 1.13 released

Last week, I released an updated version of fillratetest, the minimal video card benchmark for Windows. Fillratetest now aborts if the Direct3D device is lost (e.g. on ALT+TAB), instead of carrying on blindly and generating bogus results. Yeah, it was never intended to be bulletproof, but it's still embarrassing to admit that it was oblivious to a lost device. Let's just say I'm a bit more obsessive about detecting and handling error conditions now than I was when I threw fillratetest together back in 2003.

During testing, one user running Windows 7 with a Radeon 4850 found that fillratetest now immediately detects a lost device and aborts. I tried resetting the device after a short delay, with no luck. A normal Direct3D application should be prepared to reset the device at any time and carry on — this is what my game engine does — but this introduces an indeterminate delay, which would render a benchmark run useless. For now, disabling Aero allows fillratetest to run successfully.

Posted by pwr (site) at February 15, 2010, 12:48pm. Category: blog. semipermalink Tags: directx

3 comments

Share this:
Sunday 6th December 2009

Boost libraries built for iPhone

I'm a heavy user of the Boost C++ Libraries, and spent a while earlier this year figuring out how to build Boost for iPhone OS so I could port my existing game engine and libraries. When I got it working, I planned to write a detailed guide, but as I still haven't got around to that, I figured I'd just make some binaries available instead. I gather less hacking is required now than used to be, but this still might save someone some time.

The archives linked below include both debug and release versions, built from Boost 1.41.0 sources against iPhone OS 3.1 on GCC 4.2, with threading=multi. All libraries are static versions only, because (afaik) you're not supposed to do your own dynamic libraries on the iPhone.

The 'release' builds are built with optimization=space, because I had a runtime crash (in Boost.Signals, IIRC) when using the default optimization=speed. The iPhone (not Simulator) versions are built with -mno-thumb because of a code generation failure when Thumb instructions were enabled. I suggest you modify your Xcode project settings to match — set Optimization Level on your release build to 'Fastest, Smallest' (-Os) and turn off 'Compile for Thumb'.

Boost Iostreams have been built with support for gzip but not bzip2.

Finally, the Program Options library is omitted altogether, as it failed to build for iPhone, and doesn't really make sense on the platform anyway.

boost_1_41_0_iphone.tar.bz2
boost_1_41_0_iphone_simulator.tar.bz2

Distributed under the Boost Software License.

Posted by pwr (site) at December 6, 2009, 8:28pm. Category: blog. semipermalink Tags: blog, programming, c++, iphone

9 comments

Share this:
Saturday 5th December 2009

MacJJFFE updated

I've released a new version of MacJJFFE. Still based on JJFFE 2.8a7, and imaginatively labelled 2.8a7-mac2, this version adds in-game music support using the Core Audio MIDI synth. You'll need to provide the music files from the original game, as explained in the installation instructions on the MacJJFFE page.

The Apple MIDI synth certainly sounds nicer than the DirectMusic one on Windows. There are a few notes being dropped which I haven't been able to figure out, but on the other hand, there are none of the cacophonous stuck notes that plague the Windows version of JJFFE.

Also new is fullscreen support, configurable via the config file seen in other versions of JJFFE. As in those versions, CTRL+F12 toggles windowed/fullscreen mode.

You'll find binary and source downloads on the MacJJFFE page.

Posted by pwr (site) at December 5, 2009, 11:39pm. Category: blog. semipermalink Tags: games, retro, elite, frontier, blog, development, mac, ffe, macjjffe

4 comments

Share this:
Sunday 29th November 2009

MacJJFFE released

Back in April 2009, I bought a Mac Mini to do iPhone development. One of the first things I did with it was port John Jordan's JJFFE to OS X. For the uninitiated, JJFFE is a reverse engineered, bug-squished version of David Braben's Frontier: First Encounters, a classic PC space sim from the 1990s. FFE is the third game in the famous Elite series, and inspired me to get into game development probably more than any other single game.

JJFFE wasn't difficult to port, and was mostly done in a single evening. The only major hurdle was OS X's x86 ABI, which specifies 16 byte stack alignment for function calls. The monolithic hunk of x86 assembly that makes up most of JJFFE doesn't know anything about this requirement, and terrible things happen when it tries to make direct calls to libc routines with an unaligned stack. The messy but practical solution was to create wrapper functions for sprintf and the few dozen other libc routines that ffe.asm uses. The wrappers live in C land and just pass through to their libc equivalents. If we set -mstackrealign, GCC handily fixes up the stack for us on the way through:

-mstackrealign
    Realign the stack at entry.  On the Intel x86, the -mstackrealign
    option will generate an alternate prologue/epilogue that realigns
    the runtime stack.  This supports mixing legacy codes that keep a
    4-byte aligned stack with modern codes that keep a 16-byte stack
    for SSE compatibility.

It's pretty surreal seeing an old DOS game running natively on a Mac in 2009. That's despite knowing there's no magic involved, since x86 is x86 and essentially I just recompiled the thing. Kudos to John Jordan for the superhuman reverse engineering effort involved in freeing FFE from its MS-DOS roots in the first place.

The port had been sitting on my hard drive for six months, but I finally got around to packaging it up for release. So, Mac-owning retro space sim fans (all six of you), go check out MacJJFFE and tell me if it works.

MacJJFFE

Posted by pwr (site) at November 29, 2009, 9:02pm. Category: blog. semipermalink Tags: games, retro, elite, frontier, blog, development, mac, ffe, macjjffe

3 comments

Share this:
Wednesday 28th November 2007

Parallel builds in Visual C++ 2005

(via Herb Sutter's blog)

If you haven't upgraded to Visual Studio 2008 yet, or like me, discovered that the mighty Boost doesn't build with it yet, then you might be interested to know that one of its most useful new features for C++ developers is available, undocumented, in '2005.

If you've got SMP (which is pretty likely these days), you probably know that Visual C++ 2005 already offers parallel project builds, and that they're useless if your solution contains a single monolithic project, or a bunch of interdependent projects.

However, VC 2005 actually has the ability to parallelise compiles at the source file level, too. In your project's properties, go to C/C++ -> Command Line, and in the Additional options box, add "/MP". Now it'll build as many compilation units (i.e. .cpp files) in parallel as you have CPUs. I did a "dual core on a budget" upgrade last week, and /MP has actually halved my build times. Now I can stop rueing my liberal usage of slow-building C++ templates!

Caveat: The compiler output can look a little mixed up, but you get used to it.

Don't let this revelation stop you upgrading to 2008, but if you're stuck with 2005 for reasons financial, technical, or political then /MP might be the most productive three characters you could type.

Posted by pwr (site) at November 28, 2007, 6:31pm. Category: blog. semipermalink Tags: visual studio, development

4 comments

Share this:
Thursday 17th May 2007

DLL Hell and the first DirectX 10 game

The first ever DirectX 10 game demo appeared on the 'net on Tuesday. I found out about it Wednesday night, when I found some 20 new comments on my D3DX DLL download page. Turns out the site had over 12,000 unique visitors on Wednesday, an order of magnitude above the usual daily few 747s-full.

So that's a lot of folks unable to run the latest big PC game (it's "Lost Planet: Extreme Condition", incidentally) because they're missing the latest D3DX DLL. Did Capcom actually test on any PCs besides their latest-DirectX-SDK-having dev. machines?

Developers, it's pretty trivial to create a basic DirectX "redist" and include it in your installer. I know, you're under enough pressure to ship the game on time as it is. But I added DirectX setup to an NSIS install script at work just recently, and it took minutes to get it working. If you're bothered about space, you can assume DirectX 9.0c, and just install the incarnation of D3DX that you built your game against. In this configuration, it'll add a few MB to your installer, which is nothing when your h0t game demo is pushing 500MB anyway. Make sure your installer runs dxsetup with the /silent option, so the user doesn't get a chance to say "Hey, I've already got DirectX!" and cancel it, which I suspect may be the problem in many cases.

The more gamers have to hunt for DLLs to get their new games running, the more of them are going to jump ship for the plug'n'play ease of the consoles. You can debate the ethics of updating DirectX "by stealth" if you like, but in reality all it's going to do is copy a DLL or two that the user is bound to need anyway. The core components (D3D9.DLL et al) haven't been updated since DirectX 9.0c - so if this is already installed (likely), it doesn't even require a reboot. We're long past the murky days when installing a new DirectX (like, say, DirectX THREE) could actually break stuff.

Lost Planet is significant in PC games land, since it's the first commercial game demo to use DirectX 10 on Windows Vista, and the first chance for Geforce 8800 owners to give their pricey early-adopter toys a proper run. In honour of the moment, I downloaded the Lost Planet demo (the DX9 version) and had a go. Sadly, my ageing single core processor and sixth generation graphics card couldn't really deliver the immersive experience I believe the designers intended. There sure is a lot of snow, though.

Posted by pwr (site) at May 17, 2007, 10:22pm. Category: blog. semipermalink Tags: games, directx, d3dx, blog, gamedev, lost planet

12 comments

Share this:

Video conversion cheat sheet

I was faffing around with batched video conversion at work today, trying to recall how to get the powerful yet forboding interfaces of MEncoder and ImageMagick to play ball. I've used them both quite extensively before - most recently when encoding in-game footage from Millennium 3. As a younger hacker, I could remember arcane command line options forever, but these days it's a frustrating cycle of never using these tools quite often enough for the syntax to really stick. Such are the ravages of maturity on the capacity to learn!

Anyway, having wasted a load of time today scouring through 1,000KB man pages, I figured I'd jot down the command lines that did what I wanted, and publish them here for future reference. In my experience, what you want is an example of a use case that's vaguely similar to what you want to do, and then you can go look up individual options in the documentation and tweak things to fit your needs.

I'll expand this page as I find new examples. If you have any to share, or if I've said something blatantly wrong, post in the box below.

Examples

Open foo.png, resize to 640x480 ignoring aspect ratio, save to foo.jpg with JPEG quality 60.
The ! (ignore aspect ratio) may need to be escaped in some shells (e.g. \!).

convert -resize 640x480! -quality 60 foo.png foo.jpg

Extract audio track from foo.avi, resample to 32KHz, output to foo.wav.
-ni means force non-interleaved mode, useful for reading badly interleaved files correctly.

mplayer -ni -vc null -vo null -af resample=32000 -ao pcm:file=foo.wav foo.avi

Output frames of foo.avi to BMPs named foo_00001.bmp, foo_00002.bmp, etc.
The % needs to be escaped if you're inside a Windows batch file, i.e. foo_%%05d.bmp.
ffmpeg infers the output format from the filename. For JPEG, though, I couldn't find a way to control the compression level (quality), so I output to BMPs and then converted those to JPEG with Imagemagick's "convert".

ffmpeg -i foo.avi -f image2 foo_%05d.bmp

This outputs frames of foo.avi to JPEG files. Each frame is scaled to 640x480 and saved in directory foo_frames with JPEG quality 80.
-noframedrop stops MPlayer from trying to do the conversion in realtime. Without this option, it drops frames, and you end up with fewer JPEGs than you expected.
-noframedrop wasn't included in the MPlayer man page's huge list of command line options, but was sneakily mentioned in a usage example at the end.

mplayer -ni -noframedrop -vo jpeg:quality=80:outdir=foo_frames -vf scale=640:480 foo.avi

This creates a video foo.avi from all the JPEGs in the current directory, with foo.wav as the audio track.
Video format is MS MPEG4 v2 (a good lowest common denominator format for Windows XP/Vista systems) at 25fps. The audio track is encoded to MP3 format using LAME.

mencoder -audiofile foo.wav mf://*.jpg -ovc lavc -lavcopts vcodec=msmpeg4v2 -mf fps=25 -oac mp3lame -o foo.avi

For each foo.avi in the current directory, extract the audio track to foo.wav.

FOR %%i IN (*.avi) DO CALL :encode "%%i" "%%~ni.wav"
GOTO :end

:encode
mplayer -ni -noframedrop -vc null -vo null -ao pcm:fast:file=%2 %1

:end

For each foo.avi in the current directory, make a new movie with_new_audio/foo.avi, with a video track copied from foo.avi, and a PCM audio track from foo.wav.

FOR %%i IN (*.avi) DO CALL :encode %%i
goto :end

:encode
mencoder -ovc copy -oac pcm -audiofile "%~n1.wav" -o with_new_audio/%1 %1

:end

Finally, I always end up needing a list of the codecs available via mencoder -ovc lavc -lavcopts vcodec:codec_name. So here are the possible values for codec_name:

mjpeg, ljpeg, h261, h263, h263p, mpeg4, msmpeg4, msmpeg4v2, wmv1, wmv2, rv10, mpeg1video, mpeg2video, huffyuv, ffvhuff, asv1, asv2, ffv1, flv, dvvideo, svq1, snow

Links

IBM developerWorks ImageMagick tutorial
ffmpeg Windows binaries (you'll need 7-Zip)
Gentoo MEncoder HOWTO

Posted by pwr (site) at May 17, 2007, 8:38pm. Category: blog. semipermalink Tags: blog, video, mplayer, ffmpeg, imagemagick

4 comments

Share this:
Monday 9th April 2007

Towards a non-data-driven design

In the specific case of the Object Orientated system, some of the boxes are round and some are square, which suggests complexity not found in the functional model, where all the boxes are square.

My learned colleague, Tom Morton, has published his groundbreaking paper on what you can get away with handing in on a Computer Science degree and still get a 2:1. Software Architecture Design and Analysis: A Spellchecking System Specification Or Something.

Posted by pwr (site) at April 9, 2007, 3:58am. Category: blog. semipermalink Tags: blog, humour, degree mills

13 comments

Share this:
[Go earlier]

Site Copyright © 1996-2009 Paul Roberts. Opinions expressed are mine and don't represent the view of my employer.
Powered by clunkyblog release 3.10. Generated in 22ms.