Written by Hans "coelurus" Trnqvist	Homepage: coelurus.thorntwig.tk
                                        E-Mail:   thorntwig@telia.com
										ICQ:      102114962
										AIM:      groenkaal



		Development notes on GEMINI
	?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?


This doc is only for you who might want to get to the hard work to write your
own game, based on this raycasting engine.
Or, of course, you wanna learn some about raycasting.

PLEASE, don't massproduce new games on this engine! Somehow, things tend to
become very messy when many versions of the same genre is released...
But it sure would be fun if some of you actually tried to make something
new of it. Perhaps a 3D RPG, if someone's interested.


OK, let's begin with the sourcecode.
At the top of that file, there are a couple #define's where you can control
many important in-game values, such as weapon power etc. This might be
enough to code for some of you.
The code weighs in at a few thousand rows, so it's not an easy task to
understand it all. But there are actually very many comments in it.
Here's a little overview of the different parts of the code:

	main
		Initializes game, handles main game loop and quits nicely

	raycast
		The raycast routine. Here's where the walls, doors and pushables are
		calculated and drawn.

	objs
		Handles all objects in the level. This includes:
			Z-sorting
			Visibility check
			Picking up items
			Calculating object visibility and position
			So-called AI
			Drawing different sized objects
		You get the idea...

	weapon
		Draws player-carried weapon to the view

	hud
		Draws player status, such as health, armor etc

	update
		Handles doors/pushables, attacking, weapon update, player movement
		and more.

	decompressLevel
		LZSS-decompressor. If you want the LZSS-compression to be used
		elsewhere than for this raycasting engine, fell free to take the code.
		In case you do "borrow" it, just a tinsy bit of credit would be nice ;)

	There are other small functions at the bottom of the code, including
	'decompressLevel'. They should not be prioritized for changes, as they
	are pretty basic stuff and don't handle the real game-loops.

So, to change, for example, how long the doors should be open, you'd go into
the 'update' routine and search for the door-handling in it.
When the issue is enemy-related, you would go to the 'objs' function.

Note that the weapon-functions are hardcoded. That means, the reload-process
of the handgun must be changed in the code. If you want to make new weapons,
be prepared to mess around with this part... All of it was hacked together
rather quickly, so it might be really cryptic at some places.
My advice is: Try to keep your weapon somewhat similar to the originals in
GEMINI. The shotgun reloading might be a little out of place though...

I use A LOT of self-modifying code, so that you now know that. Also, at some
places, I've coded quite complex, so I suggest you try to see the whole
picture before changing something.

About external files then.

	tbls.inc SHOULD UNDER NO CIRCUMSTANCES BE CHANGED! In case you actually
	wanna play around with those values, use the source code in 'tables/'.
	I don't submit any programs for it, as this is a dead simple number
	generator. There are a couple of #define's at the top of the code,
	controlling wall height and stuff.

	tex*x*.inc all include visual data, such as wall textures, enemies etc.
	They are simple bitmasks and can be changed by hand. But they are stored
	as bytes, not bits, so it might be a lil' tricky.

	levels.inc contain level data.
	The levels themselves are compressed, and CANNOT BE ALTERED BY HAND!
	The object list for each level is a simple open list, so all you have to do
	is add/remove any objects you'd like.
	My advice is you get the GEMINI level editor program. Unfortunately, it
	cannot open already exported level files, you'll have to make new ones.

tex*x*.inc contain visual data, where each sprite is as big as the filename
indicates. Do not alter the labels, as they are vital to the engine. Keep a
backup copy of those files if you want to make new ones.
All sprites, except for wall textures and hud sprites, have a mask right after.
Therefore, each sprite needs two bitmasks. The first bitmask shows what regions
are to be drawn black and white. The second bitmask shows what regions are
trasparent/opaque. All bitmasked sprites, except the weapons, are transparent
at white regions. Weapons are vice versa...
As told, the current images are stored as bytes, not bits. I'd recommend you
make totally new weapons instead of messing around with bits. And you can
probably make better-looking weapons anyway :)

levels.inc contains compressed, 32x32 levels. Those are compressed using a
simplified LZSS technique, which allows varying data to be compressed better
than with RLE.
Use the program (source code) in the 'LZSS/' directory to compress files, with
32x32 values. But, to make things simpler, I'd recommend you use the GEMINI
level editor, which has support for the levels themselves plus all objects.
The level editor's choices are specially setup for GEMINI, but can be changed,
as the source code is open.
LZSS could be used to compress other files than for this raycasting engine, but
I cannot assure you it's the best for your data files.

I didn't make any sprite editor, since CalcGS works well, though it's buggy.
I used it for all my gfx (except testing the logo).

For even more hardcore programmers, I submitted a doc explaining the inner
workings and some features of the raycaster. Read blargh.txt for that info.

TODO:
I fixed some bugs rather ugly, and they often take unnecessary space. If you
could fix these, I'd be very glad.
The levels are very unsecure. I think it's somewhat fixed, but it was just an
ugly hack. Check out this section.
Texture-compression? Atleast, try to make the textures in 24x24 format, you
won't loose much quality.
Reduce code size! The code alone is > 7000 B, which is a lot. There are loads
of work to do here.
The wipe stuff. Instead of just wiping with white the second time, try to
wipe to the final image, like a crossfade. It'd look cool, but takes an extra
gfx buffer :/ Perhaps try to make the doom-like melt-effect.
Fix all small glitches and stuff you might encounter...



If you have ANY questions regarding hacking a new game of this engine, feel
free to contact me.
But please, don't request me to make a new game, I got other things to do :/
Also, don't ask dumb question. If you get problems, think a little for
yourself first. But if you just can't figure something out, I'm willing to
help.



