Finger info for

Ok, well, I'm cleaning this .plan out. Just because you don't see some
 previous project listed here doesn't mean it isn't being worked on anymore,
 it just means there isn't anything worth noting at the moment. Most will
 reappear over time. Also, right now a lot of what I'm working on hasn't
 been cleared to mention publically, even though they aren't Big Fancy Top
 Secret Projects. Time will change this, too.

But in the meantime...

Don't email me asking for updates. You really just aren't entitled to any.
 Sorry if that's rude, but really, so are most of your emails.

 2.4.0 for Linux is in beta testing Right This Very Minute. The MacOS version
 isn't far behind. I expect the Mac one to go to beta during WWDC, if I can
 find somewhere to upload the whole thing. Like Windows, there will be no
 patch from 2.3.0, so expect to be downloading the whole thing. There is no
 patch because the patch version was basically the same size as 2.4.0's full
 install...2.4.0 is the first version based on ut2004's codebase (all the
 previous ones were sort of a pre-ut2003/ut2004 potluck thing), so basically
 all of the data file formats changed. The next version after 2.4.0 will have
 a patch from 2.4.0, for what that's worth. In the meantime, start making
 friends with people that own both cable modem and a DVD burner. :)

Postal 2:
 We're working out last minute kinks in Apocalypse Weekend, then we can put
 this one to bed. If you buy this off AND TELL THEM YOU'RE A
, you'll get one CD that works on Linux, Windows, and
 MacOS. Otherwise, you're likely to get a CD that only contains a Windows
 installer...we'll make sure you get a downloadable installer to work with
 that disc, but just be aware when ordering your copy!

Unreal Tournament 2004:
 So the latest Nvidia Linux drivers added support for the extension
 GL_EXT_framebuffer_object, which, to those not in the know, gives OpenGL
 functionality roughly equivalent to Direct3D's concept of render targets...
 this is the render-to-texture support that has been sorely needed for several
 bits of important functionality: namely, detailed shadows, motion blur,
 the Hellbender license plate, and the scoreboard in DM-Morpheus. I have this
 roughly working in my codebase already (the extension is sweet and
 exactly what I've wanted since ut2003 shipped). An hour of effort got me an
 upside down license plate and blocky shadows, so this isn't ready for the
 public yet, but it looks like you'll have this sooner or later after all. If
 the extension shows up in MacOSX, I'll support it there, too.
  Screenshots, warts and all:
  (ArmyOps 2.4.0)

Other stuff:
 Blatant Plug: Buy Brian Hook's book, "Write Portable Code". I proofread
 some earlier drafts, and it's got some really good information for anyone
 who's developing's useful even if you're just targeting
 Windows, and anyone that's serious about writing quality code should have it
 on their bookshelves.

 The WWDC talk went pretty well. Glenda is clearly better at this than I am,
 since Feeding Frenzy's simple sound effects kept distracting me during my
 talk, but Glenda not only wasn't distracted by Doom 3, she played the game
 and had headphones on and didn't miss a beat during her speech. I was
 impressed, personally.

 Then the audience abused the poor Apple engineers during the Q&A, but I
 think a lot of good information got out there, overall.

 Speaking of good information, there was actually several games-specific
 sessions at WWDC this year, which is really a dramatic change for the better.
 Most of these talks were filled, even though there weren't really that many
 full-time developers there...which is probably something Apple should
 consider relevant.

 The Subversion session was packed. There was a line of people waiting to get
 in, including me, who got turned away. I consider this a good sign that maybe
 we actually will get rid of CVS someday.

 Otherwise, I pretty much chained myself to an Intel-based Mac in the
 Universal Binary Lab. Here's my basic impressions at this point, and then
 I swear I'll shut up about the topic for at least a few months.

 - It's pretty clear that this is not ready to ship to the public as a
  Complete Retail Thing, for obvious reasons that will be addressed in the
  next few months, I'm sure. As such, I'll omit specific benchmark numbers
  and highlight that anything that looks rough actually IS rough at this
  point, and shouldn't be held against anyone.

 - Rosetta isn't as bad as I anticipated. In fact, it's pretty darned good.
  For everything but games, you probably wouldn't even know you were running
  it. I'd even go as far to say that if you have a game that isn't absolutely
  dependent on framerate, you probably wouldn't even know you were running
  a PowerPC app. There are some bits in it that are still buggy, but in
  terms of raw performance, even fairly CPU-intensive things performed better
  than I expected. Granted, we're using 3.6GHz, Hyperthreaded Pentium 4s,
  if they ship a Mac Mini with a 400MHz Celeron or something like that, then
  I might be singing a different tune, but there's more potential to Rosetta
  across the board than my original flinch reaction granted.

 - I spent almost the entire conference porting things to x86 MacOS, and when
  they kicked me out at the end of the day, I went back to my hotel and
  worked on converting things to gcc4 on my Powerbook in preparation for the
  next day. I'm very tired, now. Here's where I am at the moment...

  Unreal Tournament 2004: Runs. I had a little more difficulty with this
  than I anticipated; I knew exactly what to change to make it x86-friendly,
  but moving to gcc4 bit me in a few places, including one place where I
  stalled out for over 12 hours trying to coerce the compiler to not crash.
  Eventually, I got this resolved with the help of an Apple engineer who's
  name I didn't catch, but if I figure it out, I'm sending him a Christmas
  card this year. Probably about 300 lines of changes, counting the Karma
  physics libraries, since that needed a recompile too. Still, three days
  qualifies as a success story for this work, as far as I'm concerned. Even
  though the game is playable, this needs more work still...but the exact day
  Intel-Macs hit the retail stores, I fully expect to ship a patch to
  support these machines.

  Duke Nukem 3D: Runs. I wanted something CPU-intensive that didn't require
  a powerful video subsystem so I could compare against Rosetta, and this was
  a perfect fit. Unlike most games now, this one renders the entire 3D scene,
  pixel-by-pixel, to a block of memory, and then copies it to the screen, so
  the entire renderer gets basically zero benefit from the GPU and relies
  entirely on the CPU. Granted, it ran acceptably on a 386/33MHz in the DOS
  era, but that isn't relevant, since we're running at a much higher
  resolution, and we can always note a higher framerate. Since this thing's
  been ported to more platforms than "Hello World" at this point, there
  wasn't a whole lot of effort involved. We had #ifdef PLATFORM_MACOSX where
  we really wanted to check for a PowerPC in a few places, which I cleaned
  up, and one or two gcc4 things, but nothing too painful. Fairly impressive,
  since most people consider the Build Engine to be the most successful
  collection of violations to the ANSI C Standard ever. Performance was
  _extremely_ good compared to, say, my 1.25GHz Powerbook. Orders of
  magnitude faster. Rosetta's run was actually almost exactly neck-and-neck
  with my Powerbook. None of this was scientific, I was just running around
  watching the framerate counter in the corner...but when it's got an extra
  digit on the PC, you know one's definitely beating the other. These changes
  are all going into CVS, since all the Duke sources are GPL'd, then you can
  build your own Universal Binary directly. :)

  Feeding Frenzy: Runs. This one needed a GL_UNSIGNED_INT_8_8_8_8_REV swapped
  out with a GL_UNSIGNED_INT_8_8_8_8 to fix the texture colors (my bug, not
  Apple's), and a few gcc4 things, and poof, running great. Granted, since
  I moved this to OpenGL and no longer use the original software renderer, I
  can't use all the SSE code that originally existed in the Windows version,
  but then again, moving to OpenGL gets me thousands of frames per second on
  a Blueberry iMac, so I guess I can live with that. What's interesting is
  that moving to gcc4 actually caught a really serious bug that I could never
  track down before...Microsoft's C runtime gives you an "abs" function for
  calculating Absolute Value, but it takes a float and returns a float. Apple
  (and the rest of the world) uses an "int" here, so you suddenly get whole
  numbers where you expected a fraction to come back. gcc4, unlike gcc3,
  catches this, alerting me to switch these to "fabs" as they should be, so
  that's one less problem that'll be nagging me when I try to sleep nights in
  the future.

  Torque Game Engine: Runs. Needed minor patches in a few places where it
  says "mac" but means "bigendian cpu" and one (and, really, I think, only
  one) thing needed tweaking for gcc4...even in a more or less foreign
  codebase, this all took me literally minutes to find and fix. What took
  longer was the realization that compiled TorqueScript is byte-order
  dependent with the platform that built it, so you have to delete all your
  .dso files and restart the game to stop Bad Things from happening. Once I
  did that, I was good to go, and watching the Orc Town demo rendering
  perfectly and at a comparable framerate to my Powerbook, which has better
  video hardware than the devboxes.

  Various open source things: SDL, SDL_sound, SDL_mixer, Ogg Vorbis, zlib,
  libjpeg, etc...all compiled and ran without any changes. Not a single line.
  Take that as a ringing endorsement of free software if you like.


When this .plan was written: 2005-06-12 16:24:02
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.27
Stick it in the camel and go.