Table of Contents
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
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
move ball
- SPACE
- reset game
- Q,Esc
- quit game
- R
- restart
game
- ^L
- redraw screen
- -size n
- window size
- -root
- full screen (the
default)
- -no_override
- don't use OverrideRedirect for the background window,
when the -root option is used.
- -no_grabs
- don't grab the server, when problems
with the colormap occur.
- -display name
- the output-display (default is contents
of $DISPLAY)
- -in1 name
- name of the main display for input (default is:
same as the output display)
- -in2 name
- 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.
- -chkmode
- 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.
- -maxspeed
- 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 10)
- -presets
- 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 are missing.
X(1)
, xhost(1)
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):Helmut.Hoenig@hub.desmail (for gifts): Helmut
Hoenig Hopfenstrasse 8a 65520 Bad Camberg GERMANY********************************************************By
the way, I am collecting banknotes! If you want to join into my collection,
get any bill of yourcountry, sign it on the backside and send it to meso
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.
Table of Contents