home *** CD-ROM | disk | FTP | other *** search
-
-
-
- ffffllllyyyyiiiinnnngggg((((1111)))) XXXX VVVVeeeerrrrssssiiiioooonnnn 11111111 ((((11114444 MMMMaaaarrrrcccchhhh 1111999999995555)))) ffffllllyyyyiiiinnnngggg((((1111))))
-
-
-
- NNNNAAAAMMMMEEEE
- flying - pool/snooker/carrom/hockey/curling simulator
-
- SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
- ffffllllyyyyiiiinnnngggg [-options ...]
-
- DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
- _f_l_y_i_n_g 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 ----ddddeeeelllluuuuxxxxeeee 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).
-
-
- SSSSTTTTAAAATTTTUUUUSSSS
- The flying package contains many subgames, that are more or
- less in an experimental stage. Here is a tiny summary of
- version 6
-
-
- PPPPoooooooollll,,,, SSSSnnnnooooooookkkkeeeerrrr,,,, CCCCaaaannnnnnnnoooonnnn
- 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.
-
- CCCCaaaarrrrrrrroooommmm
- Very similar to pool, just with another background (and more
- friction)
-
- HHHHoooocccckkkkeeeeyyyy
- experimental air-hockey implementation (see option -_i_n_2 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.
-
- CCCCuuuurrrrlllliiiinnnngggg
-
-
-
- PPPPaaaaggggeeee 1111 ((((pppprrrriiiinnnntttteeeedddd 6666////33330000////99995555))))
-
-
-
-
-
-
- ffffllllyyyyiiiinnnngggg((((1111)))) XXXX VVVVeeeerrrrssssiiiioooonnnn 11111111 ((((11114444 MMMMaaaarrrrcccchhhh 1111999999995555)))) ffffllllyyyyiiiinnnngggg((((1111))))
-
-
-
- experimental curling implementation, which is even more
- worth to look at because of the control: Hold the _l_e_f_t
- button to take one curl. Move it in the right direction and
- let it go...
-
-
- CCCCOOOONNNNTTTTRRRROOOOLLLLSSSS
- 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 _l_e_f_t 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 _r_i_g_h_t
- pointer button and shot by simultaenously pressing
- the _l_e_f_t button. When you release the _l_e_f_t 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
- _r_i_g_h_t 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 _r_i_g_h_t button
- once.
-
- SSSSuuuummmmmmmmaaaarrrryyyy
- lllleeeefffftttt select cueball
- introduce easy shot
- pick ball from pocket
-
- rrrriiiigggghhhhtttt deselect cueball
- introduce tricky shot
- move ball
-
- AAAAddddddddiiiittttiiiioooonnnnaaaallll KKKKeeeeyyyy----CCCCoooonnnnttttrrrroooollllssss
- QQQQ quit game
-
-
-
- Page 2 (printed 6/30/95)
-
-
-
-
-
-
- ffffllllyyyyiiiinnnngggg((((1111)))) XXXX VVVVeeeerrrrssssiiiioooonnnn 11111111 ((((11114444 MMMMaaaarrrrcccchhhh 1111999999995555)))) ffffllllyyyyiiiinnnngggg((((1111))))
-
-
-
- RRRR reset game
-
- OOOOPPPPTTTTIIIIOOOONNNNSSSS
- XXXX11111111
- ----ssssiiiizzzzeeee _n window size
-
- ----rrrrooooooootttt full screen (the default)
-
- ----ddddiiiissssppppllllaaaayyyy _n_a_m_e
- the output-display (default is contents of $DISPLAY)
-
- ----iiiinnnn1111 _n_a_m_e
- name of the main display for input (default is: same
- as the output display)
-
- ----iiiinnnn2222 _n_a_m_e
- 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 _x_h_o_s_t ...)
-
- ----ssssoooouuuunnnndddd 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.
-
- AAAADDDDDDDDIIIITTTTIIIIOOOONNNNAAAALLLL
- ----nnnnoooohhhhiiiinnnnttttssss
- the hinting arrows are not drawn (for the experts)
-
- ----ddddeeeelllluuuuxxxxeeee 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 _f_l_y*-*._d_t_a in a special data-
- directory for reusability.
-
- ----fffftttt _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.
-
- ----rrrreeeedddd ----ggggrrrreeeeeeeennnn ----bbbblllluuuueeee
- select color of the billard table. If not given, a
- random table is selected.
-
-
-
-
- Page 3 (printed 6/30/95)
-
-
-
-
-
-
- ffffllllyyyyiiiinnnngggg((((1111)))) XXXX VVVVeeeerrrrssssiiiioooonnnn 11111111 ((((11114444 MMMMaaaarrrrcccchhhh 1111999999995555)))) ffffllllyyyyiiiinnnngggg((((1111))))
-
-
-
- DDDDEEEEBBBBUUUUGGGG
- ----ttttiiiimmmmeeee _s stop process after _s seconds
-
- ----ddddeeeemmmmoooo demonstration (without pockets). By the way, there
- are some tiny meters on the bottom of the screen
- (when using the full screen), 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.
-
- ----mmmmaaaaxxxxssssppppeeeeeeeedddd
- 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)
-
- ----pppprrrreeeesssseeeettttssss
- shows the current internal values of static
- variables on stdout. The values can be dynamically
- altered by setting them in the file _p_r_e_s_e_t_s._t_x_t 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.
-
- FFFFIIIILLLLEEEESSSS
- 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.
-
-
-
- Page 4 (printed 6/30/95)
-
-
-
-
-
-
- ffffllllyyyyiiiinnnngggg((((1111)))) XXXX VVVVeeeerrrrssssiiiioooonnnn 11111111 ((((11114444 MMMMaaaarrrrcccchhhh 1111999999995555)))) ffffllllyyyyiiiinnnngggg((((1111))))
-
-
-
- SSSSEEEEEEEE AAAALLLLSSSSOOOO
- X(1), xhost(1)
-
- BBBBUUUUGGGGSSSS
- 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 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
-
- The program constantly produces a load of one and grabs the
- pointer, since it was not meant to run it simulaenously with
- other programs.
-
- 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.
-
-
- CCCCOOOOPPPPYYYYRRRRIIIIGGGGHHHHTTTT
- Copyright 93-95, Helmut Hoenig, Mettmann/Bad Camberg
-
- email (for any comments):
- Helmut.Hoenig@hub.de
-
- smail (for gifts):
- Helmut Hoenig
- Hopfenstrasse 8a
- 65520 Bad Camberg
- GERMANY
-
- ********************************************************
-
-
-
- Page 5 (printed 6/30/95)
-
-
-
-
-
-
- ffffllllyyyyiiiinnnngggg((((1111)))) XXXX VVVVeeeerrrrssssiiiioooonnnn 11111111 ((((11114444 MMMMaaaarrrrcccchhhh 1111999999995555)))) ffffllllyyyyiiiinnnngggg((((1111))))
-
-
-
- * *
- * 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 :-) *
- * *
- ********************************************************
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Page 6 (printed 6/30/95)
-
-
-
-