Finger info for

 (I _STILL_ need to merge Bargle's code...argh.)

 MacOS X port is coming along. One or two nasty rendering glitches, and some
 byteswapping issues (networking, savegames...that's all?) to go, still.

 Managed to get the game to limp along on MacOS X before crashing. Some
 rendering glitches aside, I could watch the whole intro and tell what was
 happening. No sound yet. So much more to do on this yet. It'll be awhile.

 Server is out. Details here.
 Beta 1 of the Linux client is avaiable. Get it.

Serious Sam:
 The First Encounter: Beta three is out.
 The Second Encounter is now available, too!
 Details are here.
 Time to work on ssam is non-existant, and there will probably not be another
 build for Linux for the foreseeable future, if ever.

Unreal Tournament 2003:
 Mac version is gold, ships on June 11th. Go preorder from somewhere.

 There will be another Linux dedicated server patch (that's compatible with
 Spearhead 2.15), but...I'm fucking swamped. I'll let you know when it's here.

America's Army:
 Sent beta2 for the Mac (with all the ut2003 Gold Master fixes) to some
 testers. Progress is being made.

Other stuff:
 Can someone please explain to me what the hell is wrong with SDL on
 MacOS X? Everytime it comes up in a forum, there's always that one jackass
 that says "I ditched sdl because it was sloooooow!"

 I predict the following:
  1) This is probably always the same dude, he just trolls a lot of forums and
  2) He probably didn't convert his sprites to the screen surface's format
     before blitting or something equally as stupid, but SDL is bending over
     to accomodate him.

 What is this guy doing now? Writing to Quartz directly? That was clearly a
 better plan. Good job, guy.

 Then again, maybe SDL's 2D graphics layer _is_ legitimately slow on OSX right
 now. I seem to be getting decent performance out of it for Duke3D, though.
 It doesn't really matter, though: if there's a slowdown, it's not an
 architectural issue; SDL is designed to allow for acceleration at the
 hardware and lower-level API levels. So someone give me a good example of
 a correctly written program (SDL will try to accomodate even bad
 game programming practices!) that is unnaturally slow, and we'll profile it
 and figure out what the slowdown is.

 Also, I am sick of Allegro developers dissing SDL everytime they make
 a new release. For example: "We're on MacOS X now and we're 'lightyears'
 ahead of SDL!" The two libraries are totally different. SDL (without add-on
 libraries) is much simpler than Allegro, and intentionally so. Allegro is
 a better package if you want the kitchen sink, of course, but once you're
 willing to wrangle together any external functionality you might selectively
 need (like SDL_image, SDL_mixer, SDL_sound, PhysicsFS, etc) I'd question the
 superiority of Allegro there, too.

 Ultimately, it's all a matter of choice, and choice is good. Stop pissing on
 other libraries, though, please...there's so many more worthwhile holy wars
 you could be fighting instead. If nothing else, you only diminish yourself if
 you have to trumpet significant releases by comparing them to the


When this .plan was written: 2003-06-05 22:40:00
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.24
Stick it in the camel and go.