## Re: [tuxracer-devel] Keyboard

 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/ ```

 [tuxracer-devel] Keyboard From: Peter Allen - 2000-04-06 20:58:48 ```Hi, I want to muck around with the controls on tuxracer, and have had a quick look at the code, and am now confused. Could someone give me a brief explanation of the structure of it, if it doesn't take too much time. TIA, Peter Allen btw tuxracer is a _great_ game. Thanks for all the hard work... ```
 Re: [tuxracer-devel] Keyboard From: Jasmin Patry - 2000-04-07 00:08:43 ```On Thu, 6 Apr 2000, Peter Allen wrote: > Hi, > I want to muck around with the controls on tuxracer, and have had a > quick look at the code, and am now confused. > Could someone give me a brief explanation of the structure of it, > if it doesn't take too much time. If you simply want to change the key bindings, you can do that in ~/.tuxracer. It's documented in the README. If you actually want to change the way the keyboard code works, let me know and I'll try to provide relevant details. > btw tuxracer is a _great_ game. Thanks for all the hard work... Thanks! Cheers, Jasmin ```
 Re: [tuxracer-devel] Keyboard From: Peter Allen - 2000-04-07 06:59:00 ```Jasmin Patry wrote: > > On Thu, 6 Apr 2000, Peter Allen wrote: > > > Hi, > > I want to muck around with the controls on tuxracer, and have had a > > quick look at the code, and am now confused. > > Could someone give me a brief explanation of the structure of it, > > if it doesn't take too much time. > > If you simply want to change the key bindings, you can do that in > ~/.tuxracer. It's documented in the README. If you actually want to > change the way the keyboard code works, let me know and I'll try to > provide relevant details. 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. Thanks, Peter Allen ```
 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/ ```
 Re: [tuxracer-devel] Keyboard From: Peter Allen - 2000-05-28 15:27:26 ```Jasmin Patry wrote: > > ^ 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). Thats neat.... > 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, I am not sure on the physics yet (I've only done first year 'A' level physics so far...) (Please comment and say thats not going to work etc) 1. Tux could stick a leg hard into the snow, and use it a as a pivot. For practical reasons I think the pivot would need to be a lot further out that tux's leg, so this wouldn't look 100% realistic. The physics of this are fine, but I was planning on making it so the pivot could only take a certain force, so if tux was going faster than that the pivot would slip, and tux would lose velocity (due to friction). I can't quite work out the physics of this, despite my best efforts with the ascii art. The keyboard stuff seems niceley set out so it shouldn't present any difficulties. Thanks for the explanation. Peter Allen ```
 Re: [tuxracer-devel] Keyboard From: Jasmin Patry - 2000-05-29 17:15:38 ```On Sun, May 28, 2000 at 04:25:13PM +0100, Peter Allen wrote: > I am not sure on the physics yet (I've only done first year 'A' level > physics so far...) (Please comment and say thats not going to work etc) > 1. Tux could stick a leg hard into the snow, and use it a as a pivot. > For practical reasons I think the pivot would need to be a lot further > out that tux's leg, so this wouldn't look 100% realistic. The physics > of this are fine, but I was planning on making it so the pivot could > only take a certain force, so if tux was going faster than that > the pivot would slip, and tux would lose velocity (due to friction). > I can't quite work out the physics of this, despite my best efforts > with the ascii art. It's not easy to do this "correctly" because of the model that's being used. For physics purposes, Tux is modelled as a single particle. This means that torsion on Tux can't be modelled, since the particle is infinitesimally small. A better model would take into account the fact that when Tux's left arm (or foot) is sticking into the ground, the drag on his left side is greater than on his right side; as a result he would turn in that direction. As I see it, there are a couple of options. You could just copy and modify the current turning code so that the magnitude of the frictional force was increased when doing a sharp turn; this probably won't do exactly what you want, but with sufficient tweaking it might come close. The other would be to forgot about implementing this with forces and manually manipulate Tux's velocity and/or position (instead of having it automatically updated by the ODE solver). There might be some gotchas there, though -- I haven't looked at that code in a while so I'm not sure what problems might crop up. (There is also a third option -- implement a better physical model that takes into account angular momentum, etc. -- but that's probably more work than you had in mind. :) Hope this helps, Jasmin -- Jasmin Patry Master's Student, Dept. of Computer Science jfpatry@... http://www.cgl.uwaterloo.ca/~jfpatry/ ```