tuxkart-devel — TuxKart Developers.

Re: [TuxKart-devel] Patch for smooth camera motion...

[Kevin C. <co...@ys...>]

Steve Baker wrote:
> Do you think the 0.2 and 0.1's here should actually be somehow
> related to the time delta between frames?
> 
> > !     steady_cam.xyz[0] = steady_cam.xyz[0] + 0.2f*diff.xyz[0];
> > !     steady_cam.xyz[1] = steady_cam.xyz[1] + 0.2f*diff.xyz[1];
> > !     steady_cam.xyz[2] = steady_cam.xyz[2] + 0.2f*diff.xyz[2];
> > !     steady_cam.hpr[0] = steady_cam.hpr[0] + 0.1f*diff.hpr[0];
> > !     steady_cam.hpr[1] = steady_cam.hpr[1] + 0.1f*diff.hpr[1];
> > !     steady_cam.hpr[2] = steady_cam.hpr[2] + 0.1f*diff.hpr[2];
> 
> It seems like this would look different on a high frame rate machine
> than on a low rate system.

Oh yes, you are absolutely right. The values either need to be scaled
proportionally to the time since the last frame, or there needs to be
some sort of time based history mechanism (which I presume is what your
cart history does).

I initially meant to have a look and see if this routine was driven off
a timer or off the frame update, and then didn't get round to it.

Also, from the code, it looks like there is the possibility
(unimplemented?) of flipping the view between karts. My patch will cause
the camera to spin erratically through walls if this happens.

Kevin

Re: [TuxKart-devel] Patch for smooth camera motion...

[Steve B. <sjb...@ai...>]

co...@ys... wrote:
> 
> Here's a patch which makes the camera move much more smoothly. It's not
> the right solution, but it is simple and to my eye rather better than
> the current effect.

OK - my son, Oliver, is yelling "Woahhh! Cool!", etc.

...it passes the "Mk I child" test.  :-)

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [TuxKart-devel] Patch for smooth camera motion...

[Steve B. <sjb...@ai...>]

co...@ys... wrote:
 
> Here's a patch which makes the camera move much more smoothly.

Thanks!

> It's not
> the right solution, but it is simple and to my eye rather better than
> the current effect. Its against 0.0.2 but applies OK against 0.0.3 too.

Do you think the 0.2 and 0.1's here should actually be somehow
related to the time delta between frames?

> !     steady_cam.xyz[0] = steady_cam.xyz[0] + 0.2f*diff.xyz[0];
> !     steady_cam.xyz[1] = steady_cam.xyz[1] + 0.2f*diff.xyz[1];
> !     steady_cam.xyz[2] = steady_cam.xyz[2] + 0.2f*diff.xyz[2];
> !     steady_cam.hpr[0] = steady_cam.hpr[0] + 0.1f*diff.hpr[0];
> !     steady_cam.hpr[1] = steady_cam.hpr[1] + 0.1f*diff.hpr[1];
> !     steady_cam.hpr[2] = steady_cam.hpr[2] + 0.1f*diff.hpr[2];

It seems like this would look different on a high frame rate machine
than on a low rate system.

I'll experiment.
 
> I guess the right solution is to give the camera its own physics model
> and collision detection with walls.

Yes - I agree...someday.  :-)

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [TuxKart-devel] Game design: list of possible game modes besides racing

[Steve B. <sjb...@ai...>]

Willian Padovani Germano wrote:
> 
> Hi,
> 
> As I told you, Steve, here is a first draft of possible game modes for Tux
> Kart, besides the racing one(s).

Thanks - some of these sound like good candidates for 'bonus games' between
difficult races - or perhaps as part of a 'DiddyKong Racing' type of
adventure game that ties everything together.

> 1) Collecting an item:

This seems simple enought to implement.  Since you can now call for the
'butterfly tux' to come and rescue you, we don't have to worry so much
about there being places in the 'level where you can get stuck.

The AI doesn't sound too hard either.

> 2) Variation on #1:

> An item (a big bouncing red ball, maybe) appears somewhere -- you find it
> first, you win.

Again - very easy to code - AI should be identical to #1.

> 3) Chase and bump:

There is a proper name for this kind of race - but I don't recollect what
it is.  Some English colleges race rowboats like this when they don't have
access to a river that's wide enough to race conventionally.

Again, shouldn't be too hard to do with the existing tracks.

> 4) The reunion:
> 
> Join #2 and #3, changing #3 a little: instead of leaving the match, a kart
> touched on its back freezes for T seconds.

Yep - that's not too bad.

> 5) Suggested by Steve: hide and seek -- one player seeks and the other(s)
> hide. Score based on time. Maybe like the kid's play, hidden karts have to
> reach some place before the seeker does (the seeker can only do that after
> finding a hidden kart) to be safe and not become the seeker next time. This
> way "finding" the others has to be coded properly, maybe it has to bump on
> them to "find" them.

I think this one would be no fun unless there is network play.  For a single
person, seeking a hidden kart isn't really different from seeking a coin or
your big red ball.  Hiding is even more boring.  Two player networked modes
are what make this fun.
 
> 6) Tag: one player is "it" and has to touch some other, who will then become
> "it".

Also pretty easy to do.

> 7) Normal battle mode like in Mario Kart, using the powerups.

Yes - I think this mode is essential - since without it, people will
inevitably wonder why it's not there when practically all comparable
kart games have it.  Dunno how hard the AI is - judging from MarioKart,
it's not that hard since the player can be sneakily outnumbered if the
AI players fire preferentially at human players to even out their
inferior tactical skills.

> Note: an important aspect to make these modes come "alive" is making events
> fun to watch, specially when something goes wrong for a player (he/she
> becomes "it", gets bumped, etc.). This surely stimulates players.

Yes - they need to carry flags and stuff like that.
 
> Suggestions, criticism, comments... welcomed.

Another one that occured to me was the game they added to PilotWings on N64.
That was a flight sim type of game - but with autogyro's, hang gliders,
cannons, people wearing wings (!), etc.  One sub-game that I liked was one
where a huge red bouncy ball had to be hit into a goal by driving (flying)
into it at speed.  The really rough terrain - with canyons and such
made this quite a challenge against the clock.

As a single player activity, no AI is needed.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [TuxKart-devel] Problem with Joysticks on Tuxkart for windows

[Steve B. <sjb...@ai...>]

Brian wrote:
> 
> Hello everyone, I did a crude port of TuxKart to work on MSVC and noticed
> that the joystick was not working.  The windows control panel was properly
> recognizing the joystick.  So I tried the Plib example on for joysticks.  I
> found that the demo did not work with my Gravis XTerminator gamepad, but
> would work with my old 2 button joystick.  Has anyone else every experienced
> this problem.

I have had no reports of that problem.

PLIB's JS "library" (it's really just a header file) uses the standard Windoze
joystick API - so there *shouldn't* be a problem.

Does your Gravis stick work with other programs?

> I definately not an expert on joystick programming, but do
> newer joysticks need to use DirectX to access them.

Perhaps.

I'm no windoze expert myself (I havn't used Windoze at all since 3.1!) but
IIRC, people have told me in the past that incorporating Direct-X into PLIB
would be a major headache.

Can someone comment on that?

> I am using Windows 98,
> Plib 1.2,Glut 3.7, MSVC 6.0.

Seems reasonable.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

[TuxKart-devel] Game design: list of possible game modes besides racing

[Willian P. G. <wge...@za...>]

Hi,

As I told you, Steve, here is a first draft of possible game modes for Tux
Kart, besides the racing one(s). Considering the AI involved, some of them
may be easy to code only for multiplaying without bots. Again, racing will
be treated later, separately.

1) Collecting an item:

Let's take big shiny golden coins as our item in this example. We need
freedom of movement for this mode, so it's better suited to larger envs,
where players can go off-road. If making bot karts find the items become
troublesome, we may need specially designed tracks, without places where
they could get stuck, for example. Or leave some or all levels to
multiplayer between humans only. The mode is basically this: all competitors
(alone or in teams) are put somewhere on the landscape and N copies of the
item are thrown in random places. Some START! signal happens and all
competitors are free to hunt for coins. When all have been caught -- or
time T has expired -- the match stops. The partial score (# of coins grabbed
by each player) is displayed. Another match, there or somewhere else,
starts, with coins and maybe even players placed randomly again. The kart
that grabs X coins first, or the one with more coins after Y minutes, wins.
This and the number of players, coins, matches, etc. should be configurable.

2) Variation on #1:

An item (a big bouncing red ball, maybe) appears somewhere -- you find it
first, you win. Optionally, there may be a radar, or easier, a point on the
2d map of the track showing where the item appeared. Players are initially
placed randomly, but when someone touches the ball, it reappears somewhere
else  without stopping the match -- players continue where they are and with
control of their karts. There are two completelly different possibilities:
with or without indication on a map or radar of where the ball is. The first
gives a fast paced "reach known points first", while the second puts players
in suspense, searching all around and counting on luck.

3) Chase and bump:

Divide players in teams: the objective of all groups is to chase and touch
the back of karts from the other teams. So players chase and try to escape
all the time, leaving the match when their backs get bumped X times.  The
remaining kart's team wins of course. Number of players in each team, of
teams and of times to be hit before exiting the game are configurable.

4) The reunion:

Join #2 and #3, changing #3 a little: instead of leaving the match, a kart
touched on its back freezes for T seconds. It's possible to join #1 here,
too: coins collected could give powerups (based on a choice after N coins
collected -- the more the better powerups one can choose) or based on random
powerups like Mario Kart. Number of times the ball was caught, last
player/team "alive" or time elapsed may end the match. Imagine this mode,
it's a fast paced action game with an interesting design. For ex., it can be
tweaked so that getting hit makes you loose points, so when there's little
time, the ones with more points will be more concerned about not being hit
than grabbing the ball, etc. With proper design, we may come up with a mode
where objectives and attitude of the players change during the match.
Actually more than one, so there are sub-modes in this mode.

5) Suggested by Steve: hide and seek -- one player seeks and the other(s)
hide. Score based on time. Maybe like the kid's play, hidden karts have to
reach some place before the seeker does (the seeker can only do that after
finding a hidden kart) to be safe and not become the seeker next time. This
way "finding" the others has to be coded properly, maybe it has to bump on
them to "find" them.

6) Tag: one player is "it" and has to touch some other, who will then become
"it". Players win points for, e.g., each 30 seconds they manage not to be
"it". And loose when they are (so players will concentrate on hunting the
ones with higher score). For this to work in bigger levels, there has to be
a mecanism to keep players not too far apart from each other. A sample
possibility: a kart freezes for X seconds when it gets a considerable
distance Y apart from "it", and a signal on the screen tells others about
it, so the frozen one becomes an easier prey. Another variation: no score,
but after T minutes (configurable, of course) "it" explodes -- I mean,
looses.

7) Normal battle mode like in Mario Kart, using the powerups.
-----------------------------------------
Variation is the keyword. Not just about game modes, but about objectives,
attitude, feel and gameplay, too. Make the player have to escape, or to
chase/hunt/seek or to compete for itens and so on. With changes even inside
a single mode or even match in some cases.

Note: an important aspect to make these modes come "alive" is making events
fun to watch, specially when something goes wrong for a player (he/she
becomes "it", gets bumped, etc.). This surely stimulates players.

Suggestions, criticism, comments... welcomed.
--
Willian, wge...@ma...

[TuxKart-devel] Problem with Joysticks on Tuxkart for windows

[Brian <ga...@ix...>]

Hello everyone, I did a crude port of TuxKart to work on MSVC and noticed
that the joystick was not working.  The windows control panel was properly
recognizing the joystick.  So I tried the Plib example on for joysticks.  I
found that the demo did not work with my Gravis XTerminator gamepad, but
would work with my old 2 button joystick.  Has anyone else every experienced
this problem.  I definately not an expert on joystick programming, but do
newer joysticks need to use DirectX to access them.  I am using Windows 98,
Plib 1.2,Glut 3.7, MSVC 6.0.
Thanks
Brian Gavin
ga...@ix...

[TuxKart-devel] Patch for smooth camera motion...

[<co...@ys...>]

Here's a patch which makes the camera move much more smoothly. It's not
the right solution, but it is simple and to my eye rather better than
the current effect. Its against 0.0.2 but applies OK against 0.0.3 too.

I guess the right solution is to give the camera its own physics model
and collision detection with walls.

Sorry the code is ugly, my first language is Fortran.

[TuxKart-devel] [Fwd: [TuxKart-users] I have a compilation problem]

[Steve B. <sjb...@ai...>]

Steve Baker wrote:
> 
> al wrote:

> Mandrake 7.1
> Glide_V3-2.60.15-3mdk.rpm & devel rpm
> Mesa3.2(compiled from source)
> plib-1.2.0-i586.rpm (NOT source)
> freeglut-alpha-1.3(source)
> VooDoo3 1000 AGP

...

> /usr/include/plib/sg.h:842: `FLT_MAX' undeclared (first use this function)

...

This seems to be related to the problem with FLT_EPSILON being undefined in some
places and <float.h> being "missing" sometimes.

Dunno if anyone can shed any light on this - but indeed, the classic C header
"/usr/include/float.h" is not present under my SuSE 6.4 system...and none of
the other headers in /usr/include or and of it's subdirectories seem to have
a definition for FLT_MAX.

In desperation, I wrote:

#include <math.h>

float x = FLT_MAX ;

...and ran:

  % cpp test.c

...which suggested that the definition of FLT_MAX was in

   "/usr/lib/gcc-lib/i486-suse-linux/2.95.2/include/float.h"

A SuSE specific directory?!?  Yuck!

Can *anyone* tell me why this might be fouling up under
Mandrake 7.1?

The first couple of lines of /usr/include/plib/sg.h are:

  #include <limits.h>
  #include <math.h>

I've had to avoif doing a:

  #include <float.h>

...under Linux *because* that file has ceased to exist in the 'normal' places.

My head hurts...somebody make it stop!

There must be some weird kind of magic going on inside the compiler
somewhere.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [TuxKart-devel] binary files in cvs

[Steve B. <sjb...@ai...>]

Norman Vine wrote:

> The binary files from CVS seem to work fine :-)

Excellent.

> I am a butterfly --  Whee !!

Erm, yes - now sit down and try to relax - I'm going to phone
those *nice* guys in the white coats with the strait jacket.

  :-)

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

[TuxKart-devel] [Fwd: [Plib-devel] Model Formats]

[Steve B. <sjb...@ai...>]

I thought the various artists who were thinking of modelling for TuxKart
would like to read this message which describes the current state of
model loaders for the PLIB graphics library (which is what TuxKart uses
to load and display 3D models).

I've snipped it about a bit so it makes sense to those who havn't been
following the thread over on the PLIB developers mailing list:

Steve wrote:

>> So far PLIB/SSG supports:
>>
>>   ASE SSG 3ds DXF TRI AC3D OBJ VRML
>>
>> Of these, I know that AC3D and SSG work well, I'm not so sure
>> about the others because I don't use them much.

Dave McClurg replied:
 
> The TRI loader was just a quicky I did because it was easy.  It is
> the same TRI format that AC3D uses.  I think it comes from Wavefront.
> 
> The 3ds loader was created by Per Liedman.  It is a very important
> *binary* format.  AFAIK, it works correctly and supports textures.
> 
> The DXF loader was adapted from John Burkardt's IVCON.  With
> Wolfram Kuss' help I've updated it to support quads, polylines,
> and MxN polymeshes.  It doesn't support textures, which are not
> in the DXF specification, but it is a widely supported format
> and a good way to import geometry into SSG.
> 
> The ASE loader is the one I wrote and use.  I have tested it and
> feel confident that it works correctly.  It has texture support.
> I'm willing to help anyone use it or improve it.  Any copy of MAX
> has the source code for the ASE export plugin.  I'm working on
> adding animation support which will require new SSG entities.
> 
> The OBJ loader was adapted from John Burkardt's IVCON.  I added
> texture support after looking at how Andreas Umbach handled it
> in gltron.  The Wavefront OBJ format is wonderfully simple and elegant.
> 
> http://www.cica.indiana.edu/graphics/object_specs/OBJ.format.txt
> 
> The "Nebula Device" project (http://www.radonlabs.de/) liked the
> OBJ format so much they extended it and use the "n3d" extension.
> But AFAICT, Wavefront OBJ lacks animation support.  Otherwise,
> I would dump ASE and switch over to it.
> 
> I hope to cleanup and improve the OBJ loader soon so it can import
> the object names and other things I missed the first time.

Dave goes on to talk about 'exporters'.  These allow PLIB programs
to write models.  Connecting a loader to an exporter with a 10 line
C++ program allows you to convert one model format to another if
you have the appropriate loader/exporter combinations.

The PrettyPoly modeller - whilst not yet ready to use as a modeller,
can none-the-less act as a fine 3D file format convertor because
it has all the loaders and exporters - and a reasonable 3D viewer
to let you see how the model would appear if loaded into TuxKart.

So, back to Dave's wise words about exporters:

Dave McClurg continues:

>  Also, the [...OBJ...] exporter currently lacks texture support.
> 
> Many of these loaders have an exporter.  The exporter feature was
> mainly needed for PPE (pretty poly editor).  If you want to *save*
> a scene graph, you should use ssgSaveSSG() which supports all the
> SSG entities.  Otherwise, you'll lose information.
> 
> Another *big* todo item is to add ssgIndexArray to the _ssgCreateFunc
> so it can support Mark's ssgVertexArray.cxx module.  That would
> make large ASE models load and render faster since they are
> naturally in indexed array form.
> 
> If someone has a specific use for an improved OBJ or ASE loader,
> please let me know.  The added motivation always helps.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

RE: [TuxKart-devel] binary files in cvs

[Norman V. <nh...@ca...>]

Steve Baker writes:
>
>OK - the CVS archive should now be set up correctly.


The binary files from CVS seem to work fine :-)


>(With a bunch of new code and some bug fixes...check out the 'D'
>button!)

I am a butterfly --  Whee !!

Norman

Re: [TuxKart-devel] binary files in cvs

[Steve B. <sjb...@ai...>]

Norman Vine wrote:
> 
> Bram Stolk writes:
> >
> >Norman Vine wrote:
> >
> >> Therefore, when you add a binary file, you have to tell CVS
> >to turn off both
> >> keyword expansion and line-ending conversion. To do so, use -kb:

OK - the CVS archive should now be set up correctly.

(With a bunch of new code and some bug fixes...check out the 'D'
button!)

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

RE: [TuxKart-devel] binary files in cvs

[Norman V. <nh...@ca...>]

Bram Stolk writes:
>
>Norman Vine wrote:
>
>> Therefore, when you add a binary file, you have to tell CVS 
>to turn off both
>> keyword expansion and line-ending conversion. To do so, use -kb:
>> > 
>
>I usually use a CVSROOT file to specify the binary nature of files only
>once for each extention.
>

Much better !

Thanks for pointing this one out :-)

Norman

[TuxKart-devel] binary files in cvs

[Bram S. <br...@ch...>]

Norman Vine wrote:

> Therefore, when you add a binary file, you have to tell CVS to turn off both
> keyword expansion and line-ending conversion. To do so, use -kb:
> 
> floss$ cvs add -kb filename
> floss$ cvs ci -m "added blah" filename
>   (etc)
> 

I usually use a CVSROOT file to specify the binary nature of files only
once for each extention.

You could add something like this to CVSROOT/cvswrappers
Note that I have uppercase variants in case window$ users
put something in cvs. Ugly.

The CVSROOT is updatable via cvs itself also. You do not need access
to the cvs server machine itself.

    Bram

--- cut here ----

*.jpg -k 'b'
*.JPG -k 'b'

*.tif -k 'b'
*.tiff -k 'b'
*.TIF  -k 'b'
*.TIFF -k 'b'

*.bmp -k 'b'
*.BMP -k 'b'

*.gif -k 'b'
*.GIF -k 'b'

*.wav -k 'b'
*.WAV -k 'b;

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Bram Stolk               "Linux - Why use windows, if there is a door?"
  work: br...@sa...
  priv: br...@ch...

[TuxKart-devel] [Fwd: tuxcart]

[Steve B. <sjb...@ai...>]

Looks like we have another offer of modelling effort - I suggested that this
guy joins the rest of us on this list so we can start a discussion of what
levels/racetracks we need.

Theta wrote <th...@ya...>:

> I think you game looks great and would love to help in whatever way I
> can.. I can do programming but I'm not very good yet..... but I am
> fairly good at 2d and 3d graphics so texture maps and level design is
> right down my ally... please let me know what I can do to help the most
> 
> =====
> Jerome Wild
> 
> Quote: "In 20 years when you look back at you life you will regret the
> things that you didn't do not the things you did"
> Mark Twain

Re: [TuxKart-devel] CYGWIN FIXES

[Steve B. <sjb...@ai...>]

Norman Vine wrote:
> 
> Steve Baker wrote:
> >
> >Norman Vine wrote:
> >
> >> Also were the images and sound files commited to CVS
> >> as binary files ?
> >
> >> If not they should be recomitted with the -b flag.
> 
> MY BAD that should read -kb

Aha!  I would have found that if I'd had the common sense to search
for 'binary' in the man page...but then it *is* Monday.   :-)

<snip>

> Therefore, when you add a binary file, you have to tell CVS to turn off both
> keyword expansion and line-ending conversion. To do so, use -kb:
> 
> floss$ cvs add -kb filename
> floss$ cvs ci -m "added blah" filename
>   (etc)

Ack!  I have to 'add' the file to do it!  That means I first
have to 'remove' the file - and it won't do that unless I really
do remove the file...(or at least move it somewhere else!)

OK - well I'm on the case.  Give me a day or so - I have lots of
stuff edited but not compiled that I don't want to check in right
now.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [TuxKart-devel] Keyboard works!

[Steve B. <sjb...@ai...>]

Bram Stolk wrote:
> 
> Steve Baker wrote:
> >
> > The latest version of TuxKart in CVS can be played without a joystick using
> > the keyboard.
> 
> Nice!
> I just finished as 3rd :-)
> 
> I like the sponsoring on the billboards.
> 
> And I wonder, do we hear Steve himself exclaiming 'ow' when
> you hit your competitor?

Close - my son, Oliver does the voices...we are currently recording
spoken phrases for people to say as they pass you.

  "Byeee!"

  "Coming through!"

  "Eat my dust!"

...and so on.

A 9yr old kids' voice sounds more like a penguin should sound IMHO.

> On a side note: the problem with a seperate builddir is
> caused by the $(wildcard *.wav) construction. The experts
> at the automake mailinglist told me that wildcards should
> not be used in .am files. However, I don't think that listing
> your installable files is an option. It's too easy to forget
> listing new additions. So I think you can forget about the 'Right Thing',
> it probably doesn't exist here.

Ack!  Point well taken.
 

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

RE: [TuxKart-devel] CYGWIN FIXES

[Norman V. <nh...@ca...>]

Steve Baker wrote:
>
>Norman Vine wrote:
>
>> Also were the images and sound files commited to CVS
>> as binary files ?
>
>> If not they should be recomitted with the -b flag.

MY BAD that should read -kb

From CVS book

CVS And Binary Files
Until now, I've left unsaid the dirty little secret of CVS, which is that it
doesn't handle binary files very well (well, there are other dirty little
secrets, but this definitely counts as one of the dirtiest). It's not that
CVS doesn't handle binaries at all; it does, just not with any great
panache.

All the files we've been working with until now have been plain text files.
CVS has some special tricks for text files. For example, when it's working
between a Unix repository and a Windows or Macintosh working copy, it
converts file line endings appropriately for each platform. For example,
Unix convention is to use a linefeed (LF) only, whereas Windows expects a
carriage return/linefeed (CRLF) sequence at the end of each line. Thus, the
files in a working copy on a Windows machine will have CRLF endings, but a
working copy of the same project on a Unix machine will have LF endings (the
repository itself is always stored in LF format).

Another trick is that CVS detects special strings, known as RCS keyword
strings, in text files and replaces them with revision information and other
useful things. For example, if your file contains this string

$Revision$

CVS will expand on each commit to include the revision number. For example,
it may get expanded to

$Revision: 1.3 $

CVS will keep that string up to date as the file is developed. (The various
keyword strings are documented in Advanced CVS and Third-Party Tools.)

This string expansion is a very useful feature in text files, as it allows
you to see the revision number or other information about a file while
you're editing it. But what if the file is a JPG image? Or a compiled
executable program? In those kinds of files, CVS could do some serious
damage if it blundered around expanding any keyword string that it
encountered. In a binary, such strings may even appear by coincidence.

Therefore, when you add a binary file, you have to tell CVS to turn off both
keyword expansion and line-ending conversion. To do so, use -kb:

floss$ cvs add -kb filename
floss$ cvs ci -m "added blah" filename
  (etc)

Re: [TuxKart-devel] CYGWIN FIXES

[Steve B. <sjb...@ai...>]

Norman Vine wrote:

> Also were the images and sound files commited to CVS
> as binary files ?

Not explicitly - I don't think I need to do that on
'poper' OS's.
 
> If not they should be recomitted with the -b flag.

I tried that and I got a very strange set of error
messages - so I did a 'man cvs' and searched for '-b' to check
out exactly what it meant and there are several occurrances of it:

1) As a 'main' option:
   "-b bindir: Use  bindir as the directory where RCS programs
    are located (CVS 1.9 and older).  Overrides the setting
    of  the  RCSBIN  environment  variable.  This value
    should be specified as an absolute pathname."

2) As a sub-option of 'tag', 'rtag':
   "The -b option  makes  the  tag  a  ``branch''  tag,
    allowing concurrent, isolated development.  This is
    most useful for creating a patch  to  a  previously
    released software distribution."

3) As a sub-option of 'history':
   "-b str: Show data back to a record containing the string
    str in either the module name, the file name, or
    the repository path."

4) As a sub-option of 'import':
   "Use  `-b  branch'  to  specify a first-level branch
    other than `1.1.1'."

None of those appear to force things to be binary files.

Weird.

> I had to use the ones from the tarball as the CVS
> versions appeared to be corrupted on Win32.

Hmmm - I immediately did a CVS download after I made
the repository, did a 'diff' against my existing files
and removed my originals once I was confident that they
were correctly in CVS.  So it MUST be some kind of binary/ascii
thing.

Do you have any other ideas what the appropriate option might be.
 
> I know --
> the text - binary file distinction is a Windows feature
> that programers working on real operating systems
> should not have to concern themselves with :-)

Grrr!

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [TuxKart-devel] Keyboard works!

[Bram S. <br...@ch...>]

Steve Baker wrote:
> 
> The latest version of TuxKart in CVS can be played without a joystick using
> the keyboard.

Nice!
I just finished as 3rd :-)

I like the sponsoring on the billboards.

And I wonder, do we hear Steve himself exclaiming 'ow' when
you hit your competitor?

On a side note: the problem with a seperate builddir is
caused by the $(wildcard *.wav) construction. The experts
at the automake mailinglist told me that wildcards should
not be used in .am files. However, I don't think that listing
your installable files is an option. It's too easy to forget
listing new additions. So I think you can forget about the 'Right Thing',
it probably doesn't exist here.

   Bram



-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Bram Stolk               "Linux - Why use windows, if there is a door?"
  work: br...@sa...
  priv: br...@ch...

[TuxKart-devel] CYGWIN FIXES

[Norman V. <nh...@ca...>]

Hi All

Two minor changes to get CYGWIN working with CVS files
  -see below-

Also were the images and sound files commited to CVS 
as binary files ?

If not they should be recomitted with the -b flag.

I had to use the ones from the tarball as the CVS 
versions appeared to be corrupted on Win32.

I know -- 
the text - binary file distinction is a Windows feature 
that programers working on real operating systems 
should not have to concern themselves with :-) 

Cheers

Norman


1)  start_tux.h

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#ifdef WIN32
+ #ifdef __CYGWIN__
+  #include <unistd.h>
+ #endif
 #include <windows.h>
#else
#include <unistd.h>
#endif


2) gfx.cxx -- initWindow(int w, int h)

void initWindow ( int w, int h )
{
/*
  Already done in start_tuxkart

  int fake_argc = 1 ;
  char *fake_argv[3] ;

  for ( int i = 0 ; i < 512 ; i++ )
    keyIsDown [ i ] = FALSE ;

  fake_argv[0] = "Tux Kart" ;
  fake_argv[1] = "Tux Kart by Steve Baker." ;
  fake_argv[2] = NULL ;

  glutInitWindowPosition ( 0, 0 ) ;
  glutInitWindowSize     ( w, h ) ;
  glutInit               ( &fake_argc, fake_argv ) ;
  glutInitDisplayMode    ( GLUT_RGB | GLUT_DOUBLE | GLUT_DEPTH ) ;
  glutCreateWindow       ( fake_argv[1] ) ;
*/
  glutDisplayFunc        ( tuxKartMainLoop ) ;
  glutKeyboardFunc       ( getGLUTKeystroke ) ;
  glutSpecialFunc        ( getGLUTSpecialKeystroke ) ;
  glutKeyboardUpFunc     ( getGLUTUpKeystroke ) ;
  glutSpecialUpFunc      ( getGLUTUpSpecialKeystroke ) ;
  glutReshapeFunc        ( reshape ) ;
  glutIdleFunc           ( glutPostRedisplay ) ;
}

Re: [TuxKart-devel] Keyboard works!

[Steve B. <sjb...@ai...>]

Norman Vine wrote:
> 
> Steve Baker writes:
> >
> >The latest version of TuxKart in CVS can be played without a
> >joystick using the keyboard.
> 
> Great !
> 
> < snip >
> 
> FWIW
> 
> I could probably port the FlightGear Mouse Logic easily:

Thanks for the offer - but it's only going to be a handful
of lines of code - the worst part is always tuning the
sensitivity to make it playable with the same 'feel' as
the joystick version.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

RE: [TuxKart-devel] Keyboard works!

[Norman V. <nh...@ca...>]

Steve Baker writes:
>
>The latest version of TuxKart in CVS can be played without a 
>joystick using the keyboard.

Great !

< snip >

FWIW

I could probably port the FlightGear Mouse Logic easily:

- right button rotates between pointer, yoke and view mode

in yoke mode

- horizontal drag with no buttons moves ailerons
- vertical drag with no buttons moves elevators
- horizontal drag with left button moves brakes (left=on)
- vertical drag with left button moves throttle (up=more)
- horizontal drag with middle button moves rudder
- vertical drag with middle button moves trim

When In view mode view
View follows mouse deviation from center point of screen.
Left click will reposition the mouse to screen center point
and place view into normal straight-ahead mode.

Norman

[TuxKart-devel] Keyboard works!

[Steve B. <sjb...@ai...>]

The latest version of TuxKart in CVS can be played without a joystick using
the keyboard.

Dynamic key bindings will come in due course - but for now, the key assignments
are:

  LEFT/RIGHT ARROW: Steer.
 
  UP-ARROW   - Same as 'A' button - Accellerate
  DOWN-ARROW - Same as 'B' button - Brake
  ENTER - Same as 'C' button - Use an item
  A key - Same as 'L' button - pop a Wheelie
  S key - Same as 'R' button - Jump
  D key - Same as 'D' button - Unused
 
  SPACE - Pop up or Hide the menu bar.
  R key - Restart the race.
  P key - Pause.
 
  X key - Exit the game.
  ESCAPE- Exit the game.

Mouse control coming soon!

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net