Hi Timers & Steppers!

Thanks so much for your thoughts and suggestions!  I'll try to reply in the
order I received them...

Michael Rueger:  I am very interested in seeing what you've produced.  It
certainly sounds like Timer (or Scheduler?) should be a general class that
everyone can enjoy (instead of just those pesky morphs ;-).  I appreciate
any and all suggestions that will help make my game faster (it's pretty
darned slow right now!).  I wish I could show it to you now, but I'm not
ready to post it yet...

Jim Benson:  Thanks for the tips on speeding up Morphic stepping.  I'll give
them a try real soon!  I had read about Andreas' project on supporting
hardware graphics acceleration -- I'm anxiously awaiting this.  However, I'm
not certain that supporting hardware graphics accelerators will "solve my
problem" on machines that do not have wonderful graphics cards (like PDA's,
old machines, etc.).  For those machines, I've got to be smarter about my
game's activities.  Your suggestions regarding 'temporal aliasing' sounded
interesting too.  And using pre-rendering morph images is right up my alley,
as I'm planning on creating some morphs that have multiple views, based on
their state -- thus a morph may have many different graphical
representations, each of which represent the state of the morph.  That part
about damage rectangles, though... well let's just say that I'll have to
look into it.  I was never a graphics programmer.  My experience is
primarily in applications programming and business model/logic stuff.
Perhaps this degree of tuning can wait until the game is closer to being
done?

Lex Spoon:  Your tip about reducing screen depth definitely makes a
difference!  I was working in 32 bit.  8 bit does seem snappier.  Thanks.
Regarding tinkering with morphic's drawing capabilities...  Well, I agree
with you.  I think Andreas and company have probably optimized this far, far
beyond my meager abilities.  That's why I want to use morphs for my game
pieces.  But I think that if I can de-couple their stepping mechanisms from
the World, I may be able to better tune their movements.  I have already
coupled a "business model" object (which I call a GameActor) with all of my
GamePiece morphs.  The actor holds onto all of the state information of the
game piece.  Based on the game piece's state, it might move faster/slower,
look different or simply disappear.  So it would be appropriate if each
actor had its own Timer and then it (rather than the World) could directly
control the activities of its game piece.

Karl Ramberg:  Thanks for the tip on SqC's plans.  I had read this once
before, but not recently.  Regarding that bit on "Stepping will also
probably be replaced by a more generalized form of event/response
architecture" -- well, I hope that the powers that be intend on adding
event/response _in_addition_to_ traditional morph stepping.  The step timer
mechanism is useful.  It is just not perfect for everything that Morphic
tries to use it for.  My PII 266 misses mouse clicks when I get too frisky
in Morphic.  This is bad.  But the general stepping ability of morphs is
very cool for demos, clocks, etc.  Stepping is a good idea, but I'd like to
factor it a bit so that it can be tuned to my needs (I need to have LOTS of
animated morphs, all doing their own thing, all in the same World -- AND I
don't want the user to be clicking his/her mouse saying: "This sucks!  This
stupid game is ignoring my input!"  The game may suck, but that should be
the game developer's fault -- not the environment).  [ Sorry to drop all
that on you Karl -- I know you didn't write that stuff on the Swiki!! ]

Ooops... Another reply for Jim Benson:  Regarding "The real trick in
animation is how you synchronize all of your events that you need to
process, especially ones that have different timebases/timescales? Or
different priorities."  In a word, YES!  My morphs do have different timer
scales and priorities.  The user, of course, should have the highest
priority.  I don't want to miss a thing that human does.  Thus, the actions
of the game piece that represents the GamePlayer, has a different priority
and its movements are tied directly to the keyboard/mouse/joystick/whatever.
The actor, owned by the game piece representing the player, may also have a
Timer of its own, so that it can handle batch operations over time, but that
timer is definitely separate from the World's stepper (it's owned by an
actor, not a game piece).

Andrew Greenberg:  Regarding "[I]f you have many more morphs than the frame
rate can handle, the only way to assure a consistent "real-time" feel is
precisely to keep track of absolute time since the last step, compute the
frames to drop, if any at each step, and display accordingly."  Yes.  This
is the realization that I have been facing.  I had hoped that performance
would not be an issue, and that I could simply focus on the "game."  But we
are still living with slow computers.  BTW:  I used to love your
Wizardry(TM) game!  I played that game for years on my folk's Apple ][e!

And just when I thought I could go to the gym... Andreas Raab wrote "In my
understanding we really need to have both since stepping is often 'the
simplest thing that could possibly work' and therefore a very good solution
for many, many problems. It's just getting nasty if you need more control
about how some of the aspects of stepping are handled and that is where
another mechanism is needed."  And I reply:  absolutely.  That is just what
I was getting at (above).  I think the step mechanism should not be replaced
with an event driven system.  I would prefer for an event system to be added
to Squeak for user and system activities.  Morphs should be able to handle
both stepping and events.  But stepping, IMHO, should be generalized into
its own class, as it is a genuinely useful thing.

Friends:  thanks so much for all of the great thoughts, ideas and
suggestions!

---==> Chris

PS>  Sorry I was out of the loop over the weekend!  My stepper must have
been disabled.  :-)