Finger info for

 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 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.

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. :(

 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,

 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 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 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).


When this .plan was written: 2003-11-17 17:12:19
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.27
Stick it in the camel and go.