Re: [tuxracer-devel] Keyboard

[Jasmin P. <jf...@mu...>]

On Fri, 7 Apr 2000, Peter Allen wrote:

> Could I have some more details please, as I would quite like to muck
> around trying to add a sharp turn, which slows tux down.  I'm not 
> sure whether it would work, hence why I want to try it myself rather
> than add it to the end of your todo list.

I quite like the idea of a sharp turn.  All of the motion in Tux Racer
is governed by particle physics (with the exception of tree collisions),
and calculated using an ODE solver.  There is a routine in phys_sim.c
called calc_net_force() that calculates the net force on Tux, and that
force is then used to update his velocity and position.

If you look at calc_net_force(), you will see that steering works by
taking the frictional force vector (which points in a direction opposite
of Tux's velocity vector) and rotating it about the surface normal.  If
Tux is turning left, then the friction vector will be turned to look
like this:

       ^ velocity
       |
       |
       + Tux
      /
     /
    L frictional force

The magnitude of the frictional force is also increased to reflect the
fact that drag is increased when Tux puts his hand down (so turning does
slow him down, a little bit).

There are problems with this approach, though:  Tux can actually "spin"
on surfaces with high friction coefficients (like rock) because the
frictional force is so large.  This hasn't bothered me enough yet to
make me fix it :) (though I can think of a few approaches that should
work).

For sharp turns, you have a few options.  You can play with
calc_net_force and change how the steering part works when a sharp turn
is being performed, or you can directly manipulate the velocity vector
in solve_ode_system (also in phys_sim.c).  In the latter case, you would
want to do that around the point where adjust_for_tree_collisions() is
called (that routine directly manipulates the velocity vector if a tree
is hit).  My bias is to try to do it with forces, but I realize that
some things can be tricky to do that way.

As for the keyboard code:  There are several different "modes" in Tux
Racer; the current ones are START (the start screen), INTRO (the intro
animation before a race), RACING (the race itself), PAUSED, and
GAME_OVER.  Each mode can register its own "loop" function (which gets
called between screen refreshes, and can also register its own keyboard
callbacks.  If you look at racing_register in racing.c, it creates a
keyboard callback for the braking action by calling (comments added):

add_keymap_entry( RACING,           /* the mode this entry is active in */
                  CONFIGURABLE_KEY, /* the user can change this binding */
                  "space",          /* if all else fails, use this key */
                  getparam_brake_key, /* fn ptr that returns current binding */
                  brake_cb          /* callback when key is pressed/released */
                );

brake_cb is defined as follows:

    START_KEYBOARD_CB( brake_cb )
    {
        plyr->control.is_braking = !release;
    }
    END_KEYBOARD_CB

The macros are defined in keyboard.h and expand to (more or less):

    void brake_cb ( int key, bool_t special, bool_t release, int x, int y )
    { 
        player_data_t *plyr = get_player_data( local_player() ); 
        {
            plyr->control.is_braking = !release;
        }
    }

I think it would make sense to implement sharp turns as a modifier key,
so you could add another field to plyr->control and implement it in the
same way as braking.

I hope this makes sense.  If you have another other questions, feel free
to ask.

Cheers,
Jasmin

-- 
Jasmin Patry               Master's Student, Dept. of Computer Science
jf...@cg...         http://www.cgl.uwaterloo.ca/~jfpatry/