I'm considering porting my MacOSX OpenAL implementation to Linux, for a few
- 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.
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.
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
Unreal Tournament 2003:
Mac patch is out:
New patch coming soon to fix some things that broke in the last patch,
Call of Duty:
The Linux server floating around is prerelease; don't run it.
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. :(
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.
Linux and Mac 2.0 is coming soon, we're still in beta right now.
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,
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).