OpenAL: I'm considering porting my MacOSX OpenAL implementation to Linux, for a few reasons: - to shake out some poor assumptions in my code. - aid in restructuring the code to handle multiple mixers/output targets. - let me run it through valgrind. - give me an alternative implementation on Linux...the "mini-AL" concept has really worked well for ut2003 and ArmyOps on the Mac, and I'd like to have an optimized implementation that isn't spec-perfect but wicked fast on Linux, too...let someone else worry about how the Doppler effect should sound. :) If I do this, it'll probably use SDL for output...which gives me oss, alsa. esd, etc out of the box. Plus, it lets me start the port on MacOS. This will remain a MacOSX thing, but having the same codebase run well on both platforms benefits everyone. It's the Right Thing To Do. Recently I've been fighting with resamplers (AGAIN!), and making little tweaks here and there. The next big thing is in process (linux port aside)... I think you'll like it, but it's too soon to talk about it now. Duke3D: Stuff on the MacOS TODO list: 1) x86 compatibility for savegames 2) keeping Mac/PC networking in sync 3) Coming up with a server browser/matching service. 4) Add Cmd-Q as a quit key. 5) Race condition in audiolib causes occasional crash. 6) Ship it. UTPG: Please stop emailing me to ask if this is done yet. There's a memory corrupting in the GL renderer, and ALAudio broke. We're like three steps back recently. :( Valgrind flips out all over the place in the GL renderer on Linux, but the game renders and runs fine regardless...MacOS isn't so lucky...you get something between corrupted textures and crashes there. This is really frustrating. Unreal Tournament 2003: Mac patch is out: http://www.macgamefiles.com/detail.php?item=17882 New patch coming soon to fix some things that broke in the last patch, mostly. Call of Duty: The Linux server floating around is prerelease; don't run it. Postal 2: Please stop emailing me to ask if this is done yet. The karma source is in my hands now, but the legal paperwork is still being done. :( MOHAA: Yes, I know the binary expired. A new binary will be along shortly. Sorry about that. Talked with EA today about Breakthrough, hoping source will be coming my way shortly, once all the NDA stuff is cleaned up. America's Army: Linux and Mac 2.0 is coming soon, we're still in beta right now. Other stuff: It's been awhile since I updated this, so here's some things I've been doing and thinking, in no particular order. Alright, I'm taking the plunge. I'm installing Gentoo on a spare box. It's become an increasing annoyance to be stuck on Slackware, to be honest...but to be fair the specific reason I sought out Slackware in the first place is really what's killing me now. That is, the thing I love (and still love) about Slack is that it stays the hell out of your way in all things. I never once, in almost a decade of using it, found myself feeling that the distro was preventing me from doing my thing...which I felt almost every time I tried to do something new with Red Hat, which I used for that period when Slackware didn't bother moving from libc5 when everyone else did. The biggest problem with Slackware, though, is that is basically impossible to upgrade it holistically. Last I checked, Slackware's upgrade instructions were something like "wipe your hard disk, insert the CD-ROM and reboot." In day to day operation, I don't care about that, since in many ways, a lack of "real" package management is actually quite liberating. As time goes on, you find that your /usr/src directory is getting big and pkgtool is listing less and less. You might have to dig in and run some configure scripts and read a few READMEs, but if you needed something, you installed it and went on with your business. What I've discovered, though, is that as I started working commercially on this system, there was never a good time to reinstall from scratch...this wasn't even just a matter of backing up my homedir, there's little custom scripts I've written in /usr/local/bin, careful bits of personalized config in a million places, and apps that have landed in random directories. Over the years, you accumulate a lot of duct tape on a Slackware box, and it would be seriously crippling to throw it all away and start again just to get newer versions of the same software you already use. Then you _need_ a newer version...gtk+ is usually the primary culprit here in my experience...some package has 12 million dependencies (who said code reuse was THAT great anyhow? Probably someone with a Red Hat 9 box), and you end up needing bleeding edge everything to satisfy one of those dependencies. In addition, the universe is proving Richard Stallman's point by starting to ship binaries that need glibc 2.2...I'm on Slackware 7.0 (yes, you read that right), so there's just no prayer. In conversations over the years, I've grown interested in the idea of being able to update a package (or a system) over the net with a single command... my experiences with RPM really didn't sell me on package management, since there's always an RPM you need and don't have, so it's easier to have a central repository where other people can keep track of this for you. This pretty much narrowed it down to Debian, Gentoo, or (well) FreeBSD. Someone pointed out Lunar Linux, but these things are only really useful with a critical mass of users supporting it, and somehow I think Debian or Gentoo will fit that bill better. A Slackware user told me that Gentoo was somewhat less frightening than Debian if you're migrating from Slack, so that cemented it for me. Nothing personal, Debian. I figured if I was going to do the Gentoo thing, I was going to be hardcore about it and do a stage 1 install. I was rather surprised to find, in 2003, there's a wildly popular Linux distro that features exactly zero user-friendliness in it's installer...in fact, there isn't an installer. The instructions take you through everything from fdisk to grub installation. It's terrifying that Slackware is more straightforward to install. Seriously, guys, I know you're for the "power users", but at least stick a shell script in there that automates the basic install...even starting at stage 1 and building everything from source, probably 95% of the work could be automated trivially. There's a few packages in stage 2 (i.e. - you still don't have a working system at this point, so you would think this would be something to be vigilant about maintaining) that were missing...and month old bug reports about these issues on the mailing list. Finding new copies of these packages on other sites gets you through it...but this is fairly scary to the new user...your system is half-installed, some thing that should be there is missing, and there's nothing in the docs covering "what to do if shit goes wrong at this point". It's one thing if your net connection died and you couldn't get the packages, but the damned sites hosting them moved the files (or moved to a new site) and no one updated the portage tree. If nothing else, I now understand why openbox's tarball on icculus.org gets so many hits more than openbox's webpages...the portage tree points to it. :) Then I finished the basic install, rebooted, and went to "emerge links" and it wanted to install X11, which kinda defeats the purpose of links, if you ask me. :) Anyhow, the Gentoo experiment continues. Meanwhile, I'm dicking with other OSes...specifically, eComStation, which is an updated (some say "mangled") version of OS/2. The fact that the install disc is bootable and can install to hard disks bigger than 2 gigs out of the box makes it worth the price of admission over Warp4. Still, I want to know what the hell the OS/2 kernel does at startup. There is some black evil magic in there that strikes fear into the hearts of emulators everywhere. It crashes vmWare. Virtual PC on MacOS can't handle it. Bochs can't handle it. twoOStwo can't handle it. The only thing that can handle it is Virtual PC on Windows, which is annoying. I thought about installing it on a real machine, but honestly, I'd rather use the "hardware" that Virtual PC exposes, since I know there's OS/2 drivers for the thing. After much dicking around, it seems that OS/2 subsists entirely on ported Linux software and Win32 emulation. There's nothing worse than native OS/2 software. And I say that as someone who used to write OS/2 software (and still does, tangentally...the exercise started as an attempt to update PhysicsFS's OS/2 target). --ryan.