

                             G R A V I T Y  W A R S
                             ======================
	
                                      v1.1
                                  (August 1996)


             "A Gravity Force clone for the Linux operating system"


                                    Credits:

                         ...Programming by Sami Niemi...

                        ...Graphics by Pär Johannesson...

                     ...Title picture by Mattias Johansson...



   INTRODUCTION
   ------------

	
      Gravity Force is based on Gravity Force, one of the greatest games
   for the Amiga. This version is a little different, with a much higher
   resolution, and better graphics.  It also includes  some new features
   like water, exploding doors, bonus objects, fans (ie. wind), and some
   other special effects like exploding bullets, and splashing water..
   
      Gravity Wars has been developed from scratch by Sami Niemi in June
   1995.  The game comes with a DOS based level editor which is coded by
   Pär Johannesson,  the gfx dude.  The level editor  hopefully  means a
   longer  lifespan for the game,  since everybody can now design  their
   own levels. I've also included a C source/bin for converting the edi-
   tor output to an object map.  More about that in the technical secti-
   on.  The game also gives a level code, so you can start from the last
   level. 





   REQUIREMENTS
   ------------

    The game (v1.1 or higher) should run on a 386, with  enough memory.
   You also need an SVGA card that is  supported by  SVGALIB.  The game 
   runs in  UNLINEAR mode, which means that  it should  run on all SVGA
   cards.  (The unlinear mode  also consumes  a lot of  CPU power.) The 
   game uses only the normal VGA functions, the  only real SVGA funtion
   sets the screen on..

   USAGE
   -----

   GravityWars [code-to-a-given-level] [beam-adjustment]

     You'll receive the codes after a completed level. The beam-adjust-
   ment is a number somewhere between 0 and 30000,which adjust the ras-
   terbeams position while drawing the graphics. It should be higher on
   fast computers,  and lower on  slow ones (If it's wrong,  the screen
   might flicker a bit). The default is 0.

   HOW TO PLAY
   -----------

     The goal is to get all the keys without getting killed. After you've
   picked up the last one, the hidden StarGate opens.  You're supposed to
   fly into it, and it'll  beam you into the next level.  You can pick up
   bonus objects on the way. The round (look kinda like the European Uni-
   on logos) objects are extra lifes. The bottles with an "F" on  contain
   extra fuel. The clocks give you extra time.  Rest of the  objects just 
   give  you points.  You can shoot  yourself through the  red doors (try
   to shoot into the water),  and fill your tank by  landing on the  fuel   
   platform. That should get you started..

   CONTROLS
   --------

    - Left/Right cursor keys turn the ship. 
    - Forward cursor key turns the throttle on.
    - CTRL shoots.
    - ESC/CTRL-C kills the game. Mouse buttons also kill the game.
    - ALT-F1 switches to the first console
       (if you started the game in some other)

    POLICY
    ------

     The  programs and  graphics are  public domain, with the following
   restrictions: You're free to modify the code and the  graphics as long
   as  you state that  the original  code was written by  Sami Niemi, and
   that the original graphics were drawn by P<E4>r Johannesson (If you're
   using any parts of it).  You're not allowed to sell the game or use it
   for other commercial purposes without my permission, modified or not.

     Please inform me of the latest changes to the game. 


    TECHNICAL 
    ---------

     The game uses a  640*1440 256 color virtual screen, which leaves no
   space for a doublebuffer.  The graphical mode is a  normal NON-Linear
   640*480 screen. I decided to use a NON linear mode(What a sacrifice!)
   to make it possible for people with NON linear gfx cards to also play
   the game. Unfortunately, the NON linear memory is more than ten times
   slower to access, and with it's complex structure even slower to wri-
   te to! (and a LOT harder to code a fast 'blitting' routine for!).

      Because of the  slow MEM->VIDEOMEM copying,  it would've been  too
   slow to do a real hardware-software  scrolling, with a double buffer.
   This  means that everything  has to be drawn to the  screen while the
   rasterbeam is far away from the drawn object.. Problems.. As you mig-
   ht know - this is not fully possible...  Atleast not on any slow con-     
   figurations. Sorry about that, but you have to admit that playing the
   game on a standard VGA screen would've been boring...

      As you know, Linux is a multitasking OS, which means  that someti-
   mes the OS just wants to do it's little disk access, and 'gives a sh-
   it' about eventual undubbelbuffered games running on it.. (No offence
   on the OS!  I love it,  even though it seems like  it's running a bit
   unevenly, with occational peaks. Any comments from the OS development
   side?) This means even more problems for an undubbelbuffered game, so
   to get the best results (smoothness, with no flicker), you should use
   a fast computer! There is also a  parameter that'll change  the  beam
   tracking position. The default value is 5000. If you have a fast mac-
   hine, you should use a higher value, otherwise same or smaller. 

   (The above text is about the v1.0, the newer versions are much faster
   and should run without flicker on slow machines too.)    

      The game hasn't been through much beta testing, since I just don't
   have time to supervise the hole thing. My military service in Finland
   starts in 12 days... This also means that the eventual second  better
   version won't be  released for a while,  and that the bugs  won't get
   fixed unless someone living in HELSINKI (where I'm  doing the  manda-
   tory service) with a nice Linux machine let's me use his machine.. ;)

   (Yeah.. I'm still in the service... 7th Nov 1995.. What a waste...)



   
    THE LEVEL EDITOR
    ----------------

      Not much to say about.  Saves a map containing internal an external
   information about the level. The last part contain the information th-
   at the Converter.c reads, and processes. That data contains 20*45 blo-
   ck numbers.  The blocks are contained in the  data/blocks.gw in my own
   raw image format: 

     768 bytes - first palette
     768 bytes - second palette
     ??? bytes - data

     data: 
        x size      - 320 pixels
        y size      - 792 pixels
        block_size  - 32*32, separated with a grid to the 'north'
                      and 'west'.
              
        (This means that there are four 320*198 screens attached
        to eachother, with 32*32 blocks starting from the (1,1)
        position, not from (0,0), due to the grid) 

     Some important blocks are: (You'd have to use the same colors, be-
   cause of the way the collision controll works.. Ofcourse you can have
   a different palette.)

    36-38        background

    18-20        Start

    41           End

    45-50        Ship Explotion

    51           Key

    54,60,61     Game Over

    67,76,85     Out Of Time

    68,69,70     Level, Get Ready
    
    67,105,154   Out Of Fuel
    
    108,109,117,
    119,120,122,
    127,130,136,
    139,144,146,
    147,153      Congratulations message

    112-116      Water Splash

    123-125,
    132-134,
    141-143,
    150-152      Fan Anims   

    157-161      Ship Implotion 
    
    170          Water Key

    204          Water Background

    207          Ship with thrust
    208          Ship
    
    
    So, if you decide to change the graphics to the game, you have to keep
  these blocks. 

    The level maps consist of three things:

    1. level??.gfx, which contains 20*45 block numbers starting from 0
       meaning the upperleft corner of the blocks.gw
    
    2. level??.obj, which contains the object, water, red wall, etc in-
       formation. Check out the Converter.c source. The only things that
       are not handled by the converter are the wind motions:

        Q  W  E   If the ship flies into a block with one of the letters, 
         \ ^ /    it'll be accelerated into the given direction. The Con-
          \|/     verter places an 'S' to the place  where the fan is ro-
       A<--o-->D  tating, so the designer can edit the file easily with a
          /|\     text editor.
         / v \
        Z  X  C

    3. level??.dat, which consist of the remarks  on the level, amount of
       fuel, and time at the start, and after explosions.  It also conta-
       ins the animation information:

       Starting with 'anim', followed by: (numbers)

       X coordinate,
       Y coordinate,
       Start frame times eight,
       Stop frame times eight,
       Actual frame times eight,
       Speed (1,2,4,8,16,32,...) Small numbers are slow, and require less
        processor power.


       Current animations consist only of these: (plus different explosions)

       animation           start   stop 
       -----------------   -----   ----
       Fan blowing down    984     1007
       Fan blowing left    1056    1079
       Fan blowing right   1128    1151
       Fan blowing up      1200    1223

   Well, I hope this is enough of information for y'all to get started..
 I hope to see more levels, a new editor, and why not a level to postsc-
 ript converter too.. So you could print out  your favourite  levels.  I 
 don't have time to code anymore on the game,  and the source is not re-
 ally ready for release, so just hang on.. I'll be baeck..

 (Ok, so I'm back... Fixed the worst bugs.. So, just fill my mailbox with
  comments...)


       

    TO DO, BUGS
    -----------

   Oh.. There are thousands of things to do.. The best thing is that the
 source supports all these features, me and Pär just haven't had time to
 implement all that. The source (some parts of it) supports for  example
 two players, and a magnet object  which pulls the  ship towards  itself 
 etc...  If you'll  get me encouraged enough,  I might just write a much
 better version. Network support is ofcourse one of the top  priorities,
 and is fairly easy to write. The Top priority should  be to convert the
 whole thing to X11.      





    THANKS
    ------

 - Linus Torvalds, for the kernel.
 - All the people behind the Linux, and the GNU software.




   CREDITS
   -------

 - Sami Niemi:        Coding, Design, Graphics, Levels

 - Pär Johannesson:   Graphics, Design, Levels

 - Mattias Johansson: Title Picture

 - Paul Fritzsche:    Levels





             
    CONTACT ADDRESSES
    -----------------




        Sami Niemi (Coding, level design)
        ---------------------------------

          Address:      (Sandvägen 4b)   
                        (374 53 Asarum)
                        (Sweden)


          Voice:        (+46-454-84704) 

          Fax:          +46-454-84992

          email:	e96sn@efd.LTH.se
                        sniemi@kuai.se

          WWW:          http://www.kuai.se/~sniemi
                        http://www.efd.lth.se/~e96sn





        Pär Johannesson (Graphics, level design)
        ----------------------------------------

          Address:        Knäpparestigen 6
                          374 51 Asarum
                          Sweden.
    
          Voice:          +46-454-87249
          email:          pt95pjo@pt.hk-r.se






        Mattias Johansson (Raytraced title picture) 
        ------------------------------------------

          FAX:            +46-8-330892
          BBS:            +46-8-54062686
          email:          mjoh@kuai.se






































