Finger info for icculus@icculus.org...




Lugaru:
 Hey, that didn't take long at all.
  http://icculus.org/~icculus/dotplan/lugaru_linux_firstrun.jpg
 Email me if you want to beta test. We'll probably be done within a day
  or two, though. The game is already basically done, so the beta is mostly
  sanity testing (hmm, as all betas should be, I guess).


ArmyOps:
 Mac version just went out to the MacNinjas for beta testing.


Postal 1:
 Running With Scissors, myself, and the MacNinjas spent some time moving
  the original Postal to MacOS X. If you want it, the complete game is on
  the MacWorld "Total Tiger" disc, which hits newstands today, July 26th.
  Make sure you get the right magazine, since this is a special edition of
  MacWorld and not the usual issue.

 You can buy it online here.

 This is currently the only place you can get a real MacOS X version of
  Postal 1, and it's the full single-player game, not a demo, so don't miss it!


Postal 2:
 If you bought the "Meal Deal #3: Minority Combo" disc from gopostal.com, it
  has installers for Mac, Linux, and Windows included. This went to press
  today, so those will be shipping sometime soon.

 If you have a Windows-only AW disc, you can use these installers:

  Apocalypse Weekend installer for MacOS X:
  http://0day.icculus.org/postal2/postal2aw-macosx-installer.zip

  Apocalypse Weekend installer for Linux:
  http://0day.icculus.org/postal2/postal2aw-linux-installer.tar.bz2

 The installers will patch your Postal 2 install to 1409.1 if needed.


Unreal Tournament 2004:
 I wedged in a hack for the license plate. There's some depth test mojo
  going on that I can't figure out, so I hacked around it.

 So, here's a first shot at ut2004 for Linux with all the render-to-texture
  stuff.

 Some things this fixes:
  - The scoreboard in DM-Morpheus3.
  - Motion blur in Red Orchestra and UnWheel, etc.
  - Realistic player shadows.
  - The Hellbender license plate.

 Some notes, first:
  - This is Linux only right now; MacOS doesn't have the GL extension I want,
  at least not as of 10.4.2. The second it shows up in the OS, I'll pull
  the trigger there, too.
  - You MUST have version 3355 installed. Earlier (and later, later) versions
  WILL NOT WORK, and the GAME WILL CRASH. You have been WARNED.
  - You MUST have Nvidia's latest drivers, or this WILL NOT WORK (although
  it will probably work like it does now, no render targets). ATI's drivers,
  or anyone else's, will probably work if they support the OpenGL extension
  GL_EXT_framebuffer_object.
  - You MUST set "UseRenderTargets=True" in the "[OpenGLDrv.OpenGLRenderDevice]"
  section of your UT2004.ini, or it WILL NOT WORK.
  - To get realistic shadows, you also have to set "bPlayerShadows=True" and
  "bBlobShadow=False" in the "[UnrealGame.UnrealPawn]" section of your
  User.ini...the GUI config will not let you set this in 3355 (but the next
  official patch will correct this). You can also enable vehicle shadows
  in User.ini.
  - Realistic player shadows (or even blob shadows) won't render on terrain
  on the Nvidia drivers, because of their 4 TMU limit for fixed-function
  pipeline apps. There is no fix planned for this at this time. Go buy
  an ATI card if it bothers you, and mail the receipt to Nvidia's
  engineering department.
  - The DM-Morpheus3 scoreboard renders strangely in Windows too; this is not
  an OpenGL renderer bug, it matches the behaviour of the Direct3D renderer.
  - Red Orchestra's motion blur now works (and, unrelated, their splash
  screen got fixed, too), but the sniper scope is still broken; use the
  "texture" setting and not "model" for the sniper scope in the options.
  This is my bug, to be considered later.
  - This was not built on the Holy Build Box. If it refuses to start up on
  your machine because of a glibc conflict, etc, sorry. Wait for an
  official patch.
  - This was built with all my gcc4 mangling from MacOS/x86, and all my Win64
  changes...there is a LOT of code changed over 3355, so if it crashes, too
  bad, wait for an official patch.
  - This is x86 only. amd64 will not be forthcoming until, you guessed it,
  an official patch. If you write me asking for an amd64 build, I will
  delete it without replying.

  If you read all that, here you go:
  http://icculus.org/~icculus/tmp/ut2004-lnx-3355-with-rendertargets.tar.bz2

  Unpack it in your game's System dir, overwriting ut2004-bin ...



Second Life:
 Here's 3k words worth of pictures:
  http://icculus.org/~icculus/dotplan/secondlife_screenie1.jpg
  http://icculus.org/~icculus/dotplan/secondlife_screenie2.jpg
  http://icculus.org/~icculus/dotplan/secondlife_screenie3.jpg


Other stuff:
 This is a brief rambling about what I've learned about fast prototyping.

 This all started with an offhand comment, and ensuing disagreement, that
  Gradius (you know, the side-scrolling space shooter from the Ghetto
  Nintendo?) would be a better game with mouse control.

 I wanted to explore the idea, but I really didn't want to rewrite Gradius
  from scratch. Mostly all the effort would be thrown away as soon as I had
  a "yes" or "no" result, so all time spent is wasted time. I mean, we all
  know I've got loads of free time, right?

 Just to give you an idea of the (ahem) fine craftsmanship that went into this,
  here's a screenshot of the final prototype:
  
gradius-wannabe screenshot


  ...So here are my notes after about a day of hacking on this.

  * I tried this with FreeBASIC (http://www.freebasic.net/). I wanted to know
  if a "high-level language" (and not high-level in the way that C is
  "high-level") would help, and BASIC is widely-considered to be a Rapid
  Application Development language, and this was the first thing that
  looked appealing to me when I Googled for "SDL language bindings". Some of
  this will be talk about FreeBASIC itself and not BASIC in general.
  * As painless as FreeBASIC was to use, compilation of the prototype source
  was a pain in the ass. I miss QuickBASIC's startup time when you hit F5.
  * The compiler only reports one error at a time, so fixing syntax bugs was
  even slower.
  * FTE (the editor I use) doesn't have a BASIC syntax highlighter or function
  regexp, so editing was slowed down, too.
  * FreeBASIC is x86 only, since it generates x86 asm that it then assembles
  into an object file, so I can't work on my powerbook, which limits my
  development comfort, etc. It DOES work on Linux and Windows, though, which
  was nice.
  * The totally clean C integration was great; it ships with SDL support, and
  I could wedge any C-callable shared library into it by adding a few lines
  of BASIC code. So if I wanted to use PhysicsFS in the prototype, or, say
  BSD sockets, I could. That was great. It actually worked well with gdb,
  too, which was a huge plus.
  * Remembering BASIC syntax was a slowdown. I haven't written any BASIC in 10
  years, so there was some amount of slowdown in getting back in the groove.
  I still forget to stick a "then" at the end of my IF statements after a
  full night of working with this.
  * FreeBASIC added a bunch of stuff to what was more or less QuickBASIC or
  VBDOS...basically, all the stuff that was becoming problematic to not
  have in QuickBASIC that made me switch to C back in high school...notably,
  you can use and manipulate pointers. This makes the C integration much
  easier, and it really does make some tasks cleaner even within BASIC
  itself...I would have _loved_ to have this package 10 years ago. However,
  this led to one of the main problems that you use BASIC to avoid. I
  actually had a bogus pointer dereference (my fault!) and had to spend
  time tracking it down, removing some of the benefit of using BASIC in
  the first place. However, being able to turn on runtime exception
  handling for array bounds checking, etc, was nice to have...but having
  access to real pointers became a wicked temptation. You really have to
  think in terms of BASIC to do this right, even if you know that
  deferencing that array every time you want an element is "way slower"
  than just keeping a pointer to that element. Once a C programmer, always
  a C programmer. It might be better to remove the temptation altogether.
  * The real issue with rapid C development is probably memory management,
  and string manipulation, which is a specialized form of memory management.
  But for this prototype, there wasn't a lot of either...very few strings,
  none with any meaningful manipulation, and two dynamic arrays. One of
  those arrays I could have (and should have) done without, and the other
  introduced the pointer bug...and could have been static with an assert
  if it overflowed, if we're being practical. So in this case, memory
  management wasn't a big win for BASIC, but in other programs, it should be.
  * The prototype (an extremely basic shoot'em'up) turned out to be about 500
  lines of code. Easily less than 100 of those are actually specific to the
  game and the rest were more generic...maintaining actor state, blitting
  stuff to the screen, etc. In this case, the whole thing really turned out
  to be, line for line, what I did in BASIC with SDL and what I would have
  done in C with SDL. Prototyping is more about the framework than the
  language, perhaps.
  * Prototyping is about making bad design decisions as a tradeoff for time.
  It should be a mess of inefficient code and corner cases and "!!! FIXME"
  comments that will never really get fixed. I spent way too long trying to
  be abstract and elegant, when I should have been expecting to throw this
  out and design it right later.
  * A sort of unspoken benefit of BASIC is that I won't ever ship this
  particular code as a serious project, since the compiler isn't optimizing
  and it locks me out of the Mac, etc...and hey, it's BASIC and I Have My
  Pride and all that. The end result? This guarantees that, no matter what,
  the first draft gets thrown away, which is good, since it lets you get the
  bad choices out of the way early.
  * It's important not to write a game when writing a prototype. In this
  exercise, I wanted to know, "is Gradius better or worse with mouse
  control?" This can be determined without rewriting Gradius. The source
  has stubs for rendering terrain and such, but really, all I needed was
  some sprites to come from the right side of the screen that I could shoot
  at. Keeping focus on the specific goal trims out a lot of work and time.

  * To Summarize:
  - Automatic memory management is good.
  - Interpreted languages are good. Removing the edit-compile-link-run-debug
  cycle is good.
  - Frameworks are good. More important than the language that uses the
  framework.
  - Implementing the bare minimum is good.
  - Throwing out everything at the end is good.

  * I haven't looked into Torque2D too heavily, but I suspect if the
  learning curve is extremely low, it'd've been perfect for this
  endeavor...even if the final product was rewritten in something else.

  * Comments are welcome. I'm interested in refining my thoughts on this.

  Oh, and if you want to laugh at the program, here it is:
  http://icculus.org/~icculus/dotplan/gradius-mouse-prototype.zip

--ryan.


When this .plan was written: 2005-08-09 18:28:26
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.27
Stick it in the camel and go.