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
 MAC OR LINUX USER, 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:
 First, I'm talking at WWDC today, "205: 3D Environmental Audio with OpenAL".

 Now, about this Intel/mac nonsense. has some ramblings (to use a kind word) from me about
  Apple's Intel switch:
  (The rant about the Catholic church was less out of the blue in the
  original email, honest.) I have a few more observations since:

 - At the time, I hadn't heard Phil Schiller's comment about "we won't stop
   people from running Windows on the Intel Macs". Okay, now I understand
   everyone's panic. Apple, don't let people run Windows. Take active measures
   to prevent this. I know you don't personally care if someone runs it,
   because it doesn't affect your business, or, say, Adobe's business, but
   it WILL hurt the Mac gaming business when all their customers just boot
   Windows instead of waiting for the game to show up on Mac. Likely games
   will be the number one thing affected by Windows on a Mac.

 - The funny-sad thing about the Intel switch, especially if dual-booting
   Windows is made to work, is that Mac gaming has officially starting rowing
   the same boat as Linux gaming. I've been hearing the "dual-booting is
   killing Linux gaming" rants, and the "Wine is killing Linux gaming" rants
   and the "Linux users will buy Windows games and not support Linux
   companies" rants for five years. Welcome to my world. Let me give you a
   basic intro course:
     a) Windows emulation is going to show up without any doubt (and much
        faster, since they'll just get Wine running instead of having to write
        Wine in the first place). Right now, Gavriel State is probably
        somewhere popping open a bottle of champagne, too, since it blows open
        a huge market for Cegeda on MacOS, and Transgaming would be damned
        fools to ignore that. Expect these technologies to run some, but not
        all games. Expect a camp of vocal opposers to talk about how this is
        slower and "not pure" and whatnot. Realistically, both sides of that
        argument have valid points. Expect the consumer to pick and choose
        options where it lets them play games acceptably. Everyone that has
        ever said "Mac users demand quality, polished ports" will find out
        that they were flat out wrong when someone gets Wine to limp through
        Half-Life 2 on an Intel Mac.
     b) People will dual boot in about three and a half nanoseconds if they
        are able to. Expect to start hearing things like "I'd take Windows
        off my Mac if only I had this one specific game." Unlike the
        pain in the ass of dual-booting to run a word processor, people are
        totally willing to do this for video games. In my experience, they'll
        do it even if they have free access to a native port of the game, if
        there's a feature missing that's in the Windows version, or even if
        they get a minimally higher framerate.
     c) Expect people to start wanting shit for free. Expect to hear a lot
        more of "I bought this game for Windows, why should I have to pay
        again for the Mac version?" and "This game is 10 bucks in the bargain
        bin for Windows, why do I have to pay 40 for the Mac version?"
     d) Expect me to laugh at everyone that thought the Linux users were the
        only shitty game customers over the years. It may pan out that really,
        the Mac users weren't loyal customers so much as loyal hostages. If
        this is the case, expect that loyalty to dry up with a quickness.

 - Apple's documentation says that you have to build with XCode (or
   rather, GCC instead of CodeWarrior) to support x86, which is an obvious
   requirement, but the new docs on say you have to use
   gcc 4.0. Seriously, Apple, do you know how long people used gcc 2.95 after
   it was good and obsolete, and you want people to jump to a major gcc
   release that is less than six weeks old?! I thought shipping this as the
   Tiger default was insanity, and this isn't much better. Then again, gcc4
   breaks the ABI again, so I guess that Apple doesn't want to support
   multiple ABIs out of the box, again, which I can respect.
   However, gcc4 is a total motherfucker about syntax, and even if you're
   just moving from gcc3 to gcc4, you're going to have to fix something
   in your code...or maybe a lot of somethings. Then, you can deal with the
   byte order issues.  :)

 - Apple notes that the default compiler settings for Intel builds include
   gcc's -mfpmath option...that is, use SSE instructions for even scalar
   math. Partially this is because this route is faster, I suppose, but I
   wonder if x86 MacOS will take the Win64 route of not preserving the FPU
   stack on context switch (and if so, it explains the need to force gcc4
   onto developers to get this functionality in the compiler).

 - More as I continue to think about this.


When this .plan was written: 2005-06-07 14:12:46
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.24
Stick it in the camel and go.