Written by Hans "coelurus" Törnqvist 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.