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