Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
flying(6)			 Games Manual			     flying(6)

       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 :(  )	There-
       fore  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  de-
       scribe  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, es-
       pecially	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 dis-
       play for	the input-pointer for the second player), which	is worth look-
       ing  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 ob-
       jects 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 maxi-
		 mum 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 cush-
		 ion.  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

   Additional Key-Controls
       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.

       -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 ob-
	       ject will be installed in the program and can be	controlled  by
	       the pointer of the given	display. (The pointer will get invisi-
	       ble 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 hun-
	       dreds 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-direc-
	       tory (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  de-
	       fault  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 ma-
	       chine, 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 mo-
	       tion graphics are updated as fast as possible. The switch  dis-
	       ables  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  std-
	       out.   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 al-
       gorithm 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 ap-
       pearance, 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):
	       Helmut Hoenig
	       Hopfenstrasse 8a
	       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.

X Version 11			 18 July 1995			     flying(6)


Want to link to this manual page? Use this URL:

home | help