Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project!

## tuxracer-devel — Mailing list for Tux Racer developers

You can subscribe to this list here.

 2000 2001 Jan Feb (7) Mar (90) Apr (39) May (9) Jun (2) Jul (3) Aug (10) Sep Oct (8) Nov (2) Dec Jan Feb Mar Apr May (2) Jun Jul Aug Sep Oct Nov Dec
S M T W T F S

1
(6)
2
(1)
3
(1)
4

5

6
(1)
7
(2)
8
(1)
9

10

11
(6)
12
(3)
13
(6)
14

15
(3)
16
(1)
17

18

19
(4)
20
(3)
21

22

23
(1)
24

25

26

27

28

29

30

Showing 1 results of 1

 Re: [tuxracer-devel] Keyboard From: Jasmin Patry - 2000-04-08 16:00:46 ```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 jfpatry@... http://www.cgl.uwaterloo.ca/~jfpatry/ ```

Showing 1 results of 1