Finger info for icculus@icculus.org...



(Stuff deleted that I don't have new updates on. Things like MojoSetup, etc,
 will be back when there's stuff to announce. These things haven't been
 forgotten, though!)

Normally I don't section off stuff in this .plan, but there's so much in this
 one...so, if you want to link to a specific thing, try these links:

UT3 and Gears.
America's Army.
Google Reader.
SDL 1.3.
Amazon MP3.
Toby on the iPhone.
RSS feeds for icculus.org .plans.
Other stuff.



UT3 and Gears:
  It's still being worked on. I'm not commenting about this at the moment, but
  will soon.


America's Army:
  The Army has taken the 2.x maintenance in-house. If you want a 2.8.2 Linux
  server or any specific fixes, please ask them, not me.


Google Reader:
  I ditched Sage for Google Reader for my RSS needs, and I'm loving it. I've
  started flagging things I think are interesting. It's a fairly eclectic
  bunch of stuff from a fairly eclectic bunch of feeds:

  http://www.google.com/reader/shared/12200048204252564112

  Since the shared items become an RSS feed in themselves, it's nice to start
  resharing from other people's shared lists. It's useful to have other people
  filter out the crap for you sometimes, if they happen to have similar
  opinions of what is and is not "crap".


SDL:
  Here's the rough checklist for new features in SDL 1.3 (which will
  eventually become SDL 2.0). This list is subject to change, so while some
  of this work is already done, none of it should be taken as a promise of
  any sort. Comments, complaints, and requests are still welcome.

  First, some bad news: we'll probably drop a lot of platforms/targets that
  no one is maintaining (but happily add them back in if someone steps up
  to support them). Also, backwards compatibility is not law in 1.3/2.0. In
  many cases we have added a compatibility layer that wraps the 1.3 interfaces
  in the old 1.2 functions, but if we have to break binary or source
  compatibility, we will. We don't think the damage will be extensive, but
  there will probably be some pieces of code in the wild that need to be
  updated (or continue to use SDL 1.2). You have been warned. With that out
  of the way, here's the rough list of cool, shiny, new things...

  Video and events:
  - Multiple windows! You don't need to have a single video surface anymore!
  This is a new API (but SDL_SetVideoMode() still exists in the
  compatibility layer).
  - Multiple displays: SDL exposes details of what physical monitors are
  hooked up to a machine and lets you control them individually.
  - Formal API for positioning SDL windows: it sort of comes with the
  multiple window/display support. No more setting environment variables
  for this!
  - Video device enumeration: you can get an idea of what APIs and hardware
  are available to you.
  - 2D acceleration: SDL can use OpenGL or Direct3D behind the scenes with
  the 2D interfaces, so we can get acceleration on modern systems where
  X11 or DirectDraw just aren't the fast paths anymore. The framebuffer-
  oriented interfaces, like X11, are still there, though, for legacy
  platforms and hardware.
  - Texture support: the 2D interfaces now concern themselves with "textures"
  and not surfaces. The assumption is that, even in 2D graphics, you now
  want to try to push all the effort to the hardware when you can,
  falling back to software where you can't. On the most basic level, this
  just means you can't get at pixel-based framebuffers without locking
  the "texture" and doing so may be much more expensive than in 1.2, but
  in many common scenarios, a well-designed program can be significantly
  more efficient in 1.3. There are some basic texture operations to offload
  common per-pixel operations to hardware so you may not have to lock the
  texture and do it yourself. This is meant to be a very simple API,
  however: those needing more, even in 2D, should consider using OpenGL
  directly.
  - Multiple input devices: we'll be merging ManyMouse into SDL, which
  will let us handle input from more than one connected mouse on at least
  Linux, Mac OS X, and Windows. If all you care about is the usual generic
  pointer input, that'll still work, too, but if you want to make a game
  where all your friends plug in a USB mouse and compete, that'll now be
  possible. This is also interesting for experimental work that has nothing
  to do with games, or Photoshop-style things that want mice AND pens, etc.
  - Pressure/tilt support: mouse-like input devices like tablets will be
  able to report their pressure/tilt through SDL, for those that want to
  write art programs. TuxPaint, I'm looking at you here.
  - Horizontal mousewheel events: SDL 1.2 only responds to the oldschool
  vertical mousewheel, but many mice you buy now can scroll horizontally,
  too, including the Mighty Mouse that ships with Apple desktops. There's
  a formal event for this in SDL 1.3.
  - Mousewheel no longer looks like a button: SDL 1.2 treats wheelup as
  button 4 and wheeldown as button 5. This was an accident of history,
  since XFree86 mapped the wheel to these buttons back when Loki had an
  interest in making this work Right Now, but it wasn't guaranteed to be
  those buttons, and it never was on other platforms. These have been
  moved to formal events in 1.3.
  - Separation of text input and key events: Basically, we're fixing the
  Unicode support. The keyboard can be treated as a 101-button gamepad
  with the usual KEYUP/KEYDOWN events, but there will be separate
  events for text input, so IME implementations can let users compose
  characters as they'd expect to on their platform. This will replace the
  "unicode" field in 1.2 key events, which was universally unreliable
  once you stepped outside of America and Europe.
  - Formal API to permit screensaver: no more environment variable hack!
  This is useful if you're writing a windowed application and not a game.

  Audio:
  - Audio capture support: You can record from a microphone, etc, and recover
  this data through SDL.
  - Audio device enumeration: You can find and choose specific audio devices.
  - Multiple audio device support: You can open multiple devices and playback
  different audio from each at the same time. Take all these things and
  you could, for example, have a game where the audio plays through a
  set of speakers, but speech from your teammates comes to a USB headset
  while you reply through a microphone...and probably other interesting
  things we haven't thought of yet.
  - Audio device disconnect notification: if someone accidentally kicks out
  their USB audio widget, the app can be notified, so they can pause and
  let the user get reconfigured, etc.
  - Support for PCM data in int32 format.
  - Support for PCM data in float32 format.
  - Non-power-of-two resampling. If you had to do something other than
  double or halve your sample rate, SDL 1.2 would break (and probably
  corrupt memory). This will be fixed in SDL 1.3. This is useful for
  programs that worked fine with data at 22050Hz when everyone was using
  audio cards at 11025Hz, 22050Hz, or 44100Hz, but now there are a lot of
  motherboard cards that only eat at 48000Hz and break badly in 1.2.
  - 7.1 output support.
  - Macros to parse audio format enumerations.
  No more need to do things like this:
  const int bitsize = MyAudioFormat & 0xFF;
  Now you can do the more readable:
  const int bitsize = SDL_AUDIO_BITSIZE(MyAudioFormat);
  (...and others like this.)
  - SDL_MixAudio() won't need an open audio device: In SDL 1.2, you could
  only mix audio buffers based on the opened device format. This has been
  changed to a generic interface in SDL 1.3 that allows mixing data without
  dependency on a specific device, or a device at all.
  - Better audio format converters: these should be faster and work better,
  since we generate all the possible cases in a perl script now instead of
  trying to tapdance at runtime. This means converting a buffer takes one
  pass regardless of format, instead of a pass to change bitsize, another
  to change the format, another to change the signedness, etc. This is
  cleaner to maintain and extend, and doesn't thrash the CPU cache as much,
  etc.

  Joysticks:
  - Connect notification: In 1.2, you needed to restart the
  joystick subsystem to find new sticks. In 1.3, your friend can walk up
  and plug in his controller, and your game will be able to announce "a
  new challenger approaches!"
  - Disconnect notification: ...and you'll also be able to deal with the
  controller getting kicked out midgame, or your friend getting tired of
  losing and leaving with his controller.
  - Force feedback: sticks and platforms that support vibration, rumble, etc,
  will be controllable via SDL.

  SDL_main:
  - No longer required on any platform. Now it does what it was intended
  for: hiding differences in main/WinMain/etc. Initialization details
  are being moved into SDL_Init() where they belong. This makes it easier
  to have SDL as a plugin, or use a non-SDL path without it hijacking your
  mainline just to function. This is really useful for scripting languages,
  since, say, a Python program might want to use SDL without linking SDL
  directly to python.exe and replacing its main() function.

  Misc:
  - Atomic operations API: a way to deal with atomic operations like
  test-and-set and compare-and-swap will be added. This is becoming
  increasingly important in game development, and every processor and
  platform handles this differently, so it'll be nice to abstract the
  details into SDL.
  - SDL_KillThread() is gone. It was never safe or portable. The function
  will continue to exist for binary compatibility, but it will always
  be a no-op that reports failure. If you need this, your program has
  problems anyhow and needs minor reworking to cleanly handle thread
  termination, even if KillThread was still available.

  Planned but not yet fully considered:
  - Some minor cleanups and clarifications to the RWOPS api are planned
  to fill some gaps, but this is still work in progress.
  - A basic API to read/write from the system clipboard would be nice.
  - A basic API to support drag'n'drop with the system would be nice.
  - Probably other stuff! Let Ryan know what you want!


Amazon MP3:
  Amazon's MP3 store is actually pretty good when held up against the iTunes
  Music Store. You can use it in a web browser with the familiar Amazon
  interface, which is actually pretty comforting. If you are just buying
  single songs, it can just download like any other file, but since they
  won't let you redownload purchases (argh to both Amazon and iTunes!), and
  can't let you do this for album purchases, you really have to use their
  Mac/Windows downloader for your own safety if nothing else. Now, granted, I
  usually just lose interest at this point, and would have with Apple too if
  it didn't magically appear in an update to an application I was already
  using...but I gave it a try.

  The downloader is a minimal application that just gives you a progress bar
  and adds songs to your iTunes library automatically (but not the "Purchased"
  playlist, unfortunately, but you can do that manually). It appears Amazon
  didn't want to put any features into this downloader app, but rather just
  make the process more idiot^H^H^H^H^Hfail proof, which was probably a good
  call. It simply serves as glue to make this more or less equal to the iTunes
  Music Store experience. While it's obviously not as tightly integrated, the
  overall experience basically feels like iTMS and bridges the differences
  acceptably, so users shouldn't feel too scared to try it. They even give you
  a free song to demonstrate what using the downloader app will be like. In the
  end, when you're looking at your iTunes library and syncing your iPod, any
  differences between the stores matter not one bit.

  Using the downloader app is probably roughly the same experience if using
  Windows, either iTunes or Windows Media Player.

  It's interesting that the store's front page pictures an iPod playing a
  Radiohead album, since that band is still conspicuously absent from iTMS,
  but very available from Amazon. It's also nice that you can choose to buy
  the retail disc instead of the MP3s, for the one time in your life that you'd
  rather do that.

  The fact that Amazon is doing 256k MP3s is really smart. I don't know how
  they pulled that off with the record labels. Not dealing with DRM basically
  opened them up to anything that plays music, including no-hassle iTunes/iPod
  integration. Making that deal is all the difference in the world. No
  screwing around with finding devices that can play Windows Media, or AAC, or
  some encrypted crap, just download and go. Want to burn a disc? No problem!
  Want to play it on that ancient music player no one's heard of? No problem!
  Not having to make a Faustian bargain with a merchant to use the content I
  purchased is fantastic. I like this about iTunes Plus, too, but that hasn't
  seen any momentum after the initial announcement, not to mention that
  it costs significantly more. I really don't know how Amazon pulled this off.
  Either this is costing them dearly, or the labels just really want to stick
  it to Steve JObs. Maybe both.

  Amazon really does seem best positioned to compete here, due to all their
  existing market infrastructure and customer base. It's astonishing no one
  did this before. It's nice to have options, but I could see myself going to
  Amazon much more than iTMS, starting right now. Could be interesting.

  Also, I still don't understand why Valve will let me redownload 50 gigabytes
  worth of games when I switch machines, no questions asked, but I can't
  recover an 89 cent, 5 megabyte song from either Apple or Amazon if my hard
  disk crashes. I predict that there will be a news story some day about
  someone that diligently backs up his thousands of dollars of music purchases,
  and still loses it when his house burns down; the headline will be
  "Apple ignores homeless man's pleas" when they refuse to let him recover
  his music collection. The negative publicity will make them change their
  policy.


Toby on the iPhone:
  Since moving, every time I take a call, inevitably I'm told "I can't
  hear you, you're really quiet!" Apparently it's my phone plus Sprint's
  network in Charlotte, since I'm the only one having a problem, and my phone
  is fine in other parts of the country.

  Then one night my friend called to tell me his wife might have had a stroke
  and Sprint told me "all circuits were busy!" and that was the last straw.
  The next day, I bought an iPhone and switched to AT&T.

  I can't help but void my warranty on any gadget, so I had to unjail it:
  My iPhone.

  Just for a goof, I tried targetting Toby at the iPhone. The toolchain took a
  little while to build, and someone already had an SDL port for the iPhone.
  With those two components, Toby compiled and ran without any source changes,
  which is pretty cool:

  
psychedelic2.toby running psychedelic2.toby finished gradient.toby completed.


  ...ran fairly fast, too. When they get homebrew up on the 1.1.1 firmware and
  crunch time is done, I'll probably build a real UIKit interface for the
  thing and polish it up really nicely.


RSS feeds for icculus.org .plans:
  You can get an RSS feed for an individual i.o user's .plan file now:
  http://icculus.org/cgi-bin/finger/finger.pl?user=icculus&rss=1

  ...this is probably a last gasp for people that haven't moved to a real
  blog yet, like me. IcculusFinger 3.0 will probably just be a port-79
  interface to Blogger. :)


Other stuff:
  "That's like trying to Google 'Chuck Norris getting his ass kicked.' You'll
  get zero results, because it just doesn't happen."
  --Wil Schroter.

--ryan.


When this .plan was written: 2007-10-07 16:50:57
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.27
Stick it in the camel and go.