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.
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.
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.
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.
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.
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.
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
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.
Pianoteq demo review
David Ellis linked me to Pianoteq, a brand new VST instrument from French team MODARTT. What Pianoteq apparently achieves is particularly satisfying for me, as I had often wondered whether (and when) such a thing would be possible on a PC.
Pianoteq is a piano virtual instrument, but not in the same vein as the likes of Native Instruments' Akoustik Piano and Steinberg's The Grand. Rather than playing back recordings of individual key strikes on real pianos, Pianoteq is a simulation - it models the horribly complex vibrations of the strings and soundboard when a key is struck.
This has all sorts of cool implications - the obvious one being that the vibrations of different strings can interact properly. You also (finally) get realistic sustain pedal response - you can half-pedal, quarter-pedal, or 1/128th-pedal, or depress the pedal after releasing a chord, capturing notes during their decay.
Whether the "nice" pianos Pianoteq produces are as good or as "real" as those of sample-based instruments will be open to debate. I tried the time-limited demo, and the treble range sounded slightly weird to me, but being a decidedly average pianist raised mostly on digital pianos, I'm hardly an expert judge. Try it and make your own call!
Besides, the potential for customisation is where I think this product will shine. You see, with the default patches, the lower treble ranges were rather overpowered by the bass for my liking, but altering the hammer hardness quickly improved things. Then, when I tired of my concert grand, I adjusted the unison width slider (which controls the difference in frequencies across the multiple strings that combine to play a single note), and increased the octave stretch. I immediately had the reassuring sound of a homely beast that hadn't been tuned in a while. You do not get this kind of control with a sample-based digital piano.
Indeed, an eternal limitation of sample-based pianos (both hardware and software) has been that everything they can create is derived from the same set of samples of some huge, expensive, "perfect" grand (or three). But the Steinway sound gets boring, and isn't necessarily what you want if you're trying to be Bill Evans. Native Instruments included a wonderfully mellow upright in their Akoustik Piano package, which was a step in the right direction. But with Pianoteq you can create your own instrument, from the massive concert grand to the cantankerous pub stalwart, via faithful reproductions of tinny early proto-pianos.
That appears to be the beauty of Pianoteq - there are no right answers for everyone, just a big array of variables you can tweak until you find a piano that suits your taste and mood. You can alter dozens of parameters which affect how the "piano" sounds and responds - with the potential to create some entirely new and alien instruments. In that sense, Pianoteq has the synthesiser's spirit as much as it has the piano's. It's not hard to see a future in hardware synths and digital pianos that have piano modelling technology built in.
In case you can't tell, I want the full version, but I'm holding off on an immediate purchase, as I haven't tried playing it through the X8 yet - only the V-Synth, with its decidedly non-piano-like keys. That, and I don't have a job!
Quest for the Celestine Spatula
Download: Quest for the Celestine Spatula.mp3 (MP3, 18.7MB).
Blurb:
Quest for the Celestine Spatula tells the story of a perilous journey to find a lost kitchen implement of interminable power. It was written and recorded at our student digs in Leamington Spa in Feb/March 2006, in my final year at Warwick University.Credits:
Guitar: Hywel Bennett
Keyboards: Paul Roberts
Vocals: Ollie Curnick, Hywel Bennett, Charles Gill, Paul Roberts
Powered by clunkyblog release 3.10. Generated in 27ms.