Provided by: flying_6.20-6_i386
flying - pool/snooker/carrom/hockey/curling simulator
flying [-options ...]
flying was actually meant to be a test program to implement some
classes to control flying objects on the screen. After the classes were
implemented there was the need of some real tests and a game of billard
was just the first idea. By now, many subgame-classes are already more
or less completely defined. They can either be selected by the options
or by making a link to the original with a special name. Unfortunately
having so many subclasses means that the classes themselves can’t be
too complicated. (There’s just too less time in the world :( )
Therefore the games don’t have any rules yet. This means you have to
play fair and watch your opponent.
Anyway, the main thing was animation and controlling and that works
fine, especially with the -deluxe version of pool-billard. Since the
main intention was to get an excellent billard game, I will mainly
describe the pool-version in the following pages. The other subgames
are similar to control (and there are no special rules anyway).
The flying package contains many subgames, that are more or less in an
experimental stage. Here is a tiny summary of version 6
Pool, Snooker, Cannon
As already mentioned above, pool is the most comprehensive subgame,
especially due to the deluxe version. It is very playable even though
spin is not implemented. Rules will have to be added in later revision.
Very similar to pool, just with another background (and more friction)
experimental air-hockey implementation (see option -in2 to set the
display for the input-pointer for the second player), which is worth
looking at because of the unconventional control mechanism. The players
have to select one of the big discs before they can play.
experimental curling implementation, which is even more worth to look
at because of the control: Hold the left button to take one curl. Move
it in the right direction and let it go...
The pointer (or pointers) run fully simultaenously and are like the
hand of the players. At every time it’s possible to pick one of the
objects to select it as the cue-object (It should better be the
cueball, if you don’t want to lose some friends). After you have aimed
in the desired direction there are 2 ways to play the ball:
easy: Press and hold down the left button to increase the strength
of your shot. Release the button to shoot. There is a
maximum power! If you hold down the button too long, you will
just make a very poor shot as a penalty.
tricky: You might notice on that the queue stays on the table for a
moment. This is a problem, if you are very close to the
cushion. Then, the cueball might hits the queue again.
Therefor you can alternatively gather power by pressing the
right pointer button and shot by simultaenously pressing the
left button. When you release the left button after the shot,
the queue is removed from the table and you can therefore
remove it earlier.
After shooting, you can only wait and see what will happen. By the way,
there actually are some tiny rules implemented. The billard classes
know, that cueballs shouldn’t stay in the pocket after a shot. When
they are back on the table, you can roll them to the position you like
by using the right pointer button.
By the way, if you picked the wrong ball as the cue-object, you can get
rid of it by just clicking the right button once.
To overcome the hurdle of the mouse resolution, you can use the middle
pointer button for fine adjustments. With that help, you can actually
position the mouse in fractions of pixels. To make shoting a thrill,
you’ve got to release the button again for shoting. (The fraction is
stored in that case)
left select cueball
introduce easy shot
pick ball from pocket
middle fine adjustment via interpixel motion
right deselect cueball
introduce tricky shot
SPACE reset game
Q,Esc quit game
R restart game
^L redraw screen
-size n window size
-root full screen (the default)
don’t use OverrideRedirect for the background window, when the
-root option is used.
don’t grab the server, when problems with the colormap occur.
the output-display (default is contents of $DISPLAY)
name of the main display for input (default is: same as the
name of a second input display. If given, a second pointer
object will be installed in the program and can be controlled
by the pointer of the given display. (The pointer will get
invisible on that display as it is grabbed anything)
As for every display connection, you have to make sure that all
displays are accessible from your host. (by using xhost ...)
-sound a subprocess is started, which gives some clicks when balls hit
together, but the smooth motion gets distorted in that way, at
least on my workstation.
-deluxe a special version of the pool with animated balls by using
hundreds of precalculated pixmaps. The construction of the
pixmaps at game start is very time consuming. Therefore the
computed pixmaps are cached in files fly*-*.dta in a special
data-directory (usually just /tmp) for reusability.
-tv since the deluxe-option is default, this can be used to switch
back to the set of TV-balls.
-ft n sets the size of the table in pool-billard to n foot. The value
should be in a range of 6 to 9 feet. If not given, the size is
selected randomly, except in the deluxe-version, where it
default to 8 feet. This was done because every size would need
other pixmaps for the balls.
-mode n selects the update mode for the animation in the deluxe version
of pool. There are 3 (internal) different implementations of
the ball animation, which depend on the implementation of some
specific routines of the x-server. Since mode 2 is usually the
fastest one, it is turned on by default.
runs a small benchmark with the available update modes. If a
mode other than the second is the fastest on the current
machine, you should use the mode-option to select it.
-time s stop process after s seconds
-demo demonstration (without pockets). By the way, there are some
tiny meters on the bottom of the screen (when using the full
screen and the binary was compiled with statistic features),
which have the following meanings:
rate: shows the number of cycles per second. A cycle means
the loop for doing collision detection and recomputing
the corrent position of all objects.
moves: show the number of ball moves, that were neccessary in
one seconds. If all objects are moving, this would be
<object number> x <rate>
offset: if shown, it tells you, how much the real time has gone
ahead of the current internal calculation time. It
should never light up during the game, except probably
at the first shot into the triangle.
the collision calculation is done only in those moments, when a
collision takes place. In the intermediate time, only the
motion graphics are updated as fast as possible. The switch
disables that intermediate calculation to get measures for the
speed of the collision calculation. (Good combinations to
check the speed of your machine would be: -demo -maxspeed -time
shows the current internal values of static variables on
stdout. The values can be dynamically altered by setting them
in the file presets.txt with the same syntax as in this output.
There are many additional debugging options, when the executable was
compiled for debugging. They are shown when no argument or -h is given
at the commandline. You can try flying -pool -deluxe Intro (if you’re
lucky) to see the some information about the pixmap-usage.
presets.txt file to overwrite internal static values
fly*-*.dta files containing the pixmaps for the ball animation in
deluxe-pool. They are created automatically when they
As I told, this is a very uncompleted version without any rules, but
you can perfectly play billard, so why worrying ...
The friction is not exactly integrated in the computations, since that
would have cost too much performance. Instead the objects move without
friction for a given amount of time. Then their speed is re-adjusted.
When the granularity gets smaller, the friction gets more exact. But
that works against a caching-mechanism and therefore would extremely
increase computation time, if many objects are on the table.
Spin is not implemented
There seem to be problems, when moving objects directly with the
pointer (like in hockey or curling or with the right button in billard)
when the host is not fast enough. At least I can not use it on my 386.
There are some minor problems when drawing static parts of the screen.
Sometimes they are misplaced for 1 pixel, e.g. there is a one pixel gap
below the line representing the pocket
There is a problem in the start-shot of carrom. Due to the weight of
the striker, the other stones might get pushed so close together, that
the collision detection will fail and objects will overlap (or the
algorithm gets stuck in a loop, only to be escaped by entering ’q’).
Sorry for that.
Usually, the program needs it’s private colormap. To get a nicer
appearance, a black OverrideRedirect window is placed above everything
else when the -root option is given. This confuses some window managers
and a struggle for the colormap begins. If anythings else fails, flying
will grab the server and installs the map on it’s own ...
Copyright 1995, Helmut Hoenig, Mettmann/Bad Camberg
email (for any comments):
smail (for gifts):
65520 Bad Camberg
By the way, I am collecting banknotes! If you want
to join into my collection, get any bill of your
country, sign it on the backside and send it to me
so I will pin it on my world map.
(Don’t forget the exact location for the pin :-)
But you can also just send me a picture postcard ...
Permission to use, copy, modify, and distribute this software for any
purpose and without fee is hereby granted, provided that the above
copyright notice appear in all copies.