Trixter's Scene Collection/trixter.zip/trixter/Demos/ZOX3D15.ZIP/ZOX3D.DOC

Text File | 1993-12-10 | 14KB | 373 lines

Zox3D version 1.5
by Robert Schmidt <[e-mail]>
(C) Copyright 1993 of Ztiff Zox Softwear



Disclaimer:
-----------

No warranty or guarantee of any kind whatsoever is provided regarding
the software, the fitness of the software for any purpose, or the
software quality or robustness.  The software consists of the
executable(s), the data file(s), the source file(s), the documentation
and the graphic file(s).

Under no circumstances is the author, named above, to be held
responsible for consequential or inconsequential damage or any other
incident arising from the use or abuse of any of the components of the
software mentioned above.

Note that the source code is not made available with the standard demo
distribution archive.

This software is put into the public domain.  This does not include
the freedom to use the graphic images, which I might want to use in
later products of my own.



General information:
--------------------

Zox3D is a demonstration of the idea behind the 3D graphics
engines in games like:

        Castle Wolfenstein 3D from Apogee/id
        Ken's Labyrinth from Epic
        Catacomb Abyss from Apogee
        Dracula from Psygnosis

Also, there was a lot of talk about the $25,000 XOX library and its
demo.  My goal was to develop a usable 3D game library which had all
the essential features of XOX, and which would be a LOT cheaper...
Well, there are missing features from Zox3D, most notably the lack of
objects.  Thus, the sources (see below) should be taken only as an aid
in understanding the principles of ray casting, as Zox3D is not a
complete library of what you would want in a 3D maze game engine.

As will be obvious, this engine will by outclassed _by far_ when
compared to the upcoming Doom from id software.  Doom has gotten rid of
the square walls and flat levels.  Rooms can have (almost) any shape,
walls can be at any angle around the y axis, floors and ceilings can be
at any height and are movable.  This opens up for realistic scenarios
with stairs and elevators.  Enough about Doom.

Currently only unchained (planar), 256-color VGA modes are supported in
Zox3D, from 256x240 to 400x300.  Mode 13h and the likes are not
supported, because two or more pages are required for satisfactory
performance.  On fast computers, using a temporary buffer in
conventional memory and copying this to the video buffer might be an
alternative for die-hard mode 13h'ers, but this is not supported as of
yet.  16-color (EGA) modes are definite no-nos.



The sources:
------------

I am making the sources available for a modest sum of $100.  As a
private hobbyist, this gives you the right to do anything with the
source archive, except making it, or any part within, freely available.
You can use any of the modules or individual functions in your own
projects.  If you're going commercial, i.e. if you want to make
money on your product, let me know, and we'll arrange something.

To compile Zox3D from scratch you will need Borland C++ 3.1 or 4.0, and
Turbo Assembler 3.1 or later.

Make a check of $100 payable to "Robert Schmidt", and send it
to the snail-mail address at the bottom.  When I receive it, I
will mail you the sources, preferrably via e-mail.



Usage:
------

Zox3D requires a VGA and about 400 Kb of free DOS memory to run.  (I am
not quite sure how much.)  The highest resolution requires a pretty
capable monitor.  A mouse and a joystick are optional input devices,
but the keyboard works OK.

When ZOX3D.EXE is executed, a menu of available screen modes will
be offered.  Simply press the number in front of the mode you want, and
you're off.  256x240 is the fastest, while 400x300 is the slowest.
400x300 might not work with your VGA monitor, due to the demanding
horizontal sync timing.

After selecting a mode, a logo will appear, and a couple of seconds
will be spent loading the graphics.  This will be really slow from
diskette, so you would prefer to copy everything to a directory on
your harddisk.  If the screen goes blank forever, simply press ESC to
quit the demo, and try another mode.  If this doesn't help, send me
a flaming mail with a few facts about the incident.

The following controls are currently functional in the demo.  Note that
several keys pressed at once are detected correctly.  For example, you
can walk and turn at the same time.

Mouse & keyboard:
    Up - forward
    Down - backwards
    Left - turn left
    Right - turn right

Keyboard:
    Home - turn slow left
    PgUp - turn slow right
    End - move left
    PgDn - move right
    -/+ - move up/down

    ESC - quit demo
    H - toggle help text on/off
    F - toggle floor texturing on/off
    S - toggle sky texturing on/off
    ,/. - resize view window
    J - recalibrate joystick

Mouse with right button pressed:
    Up - move up (raise)
    Down - move down (crouch)
    Left - move left
    Right - move right

Joystick A should work the way you expect it to.  Joystick B doesn't
do anything.  I use my own autocalibrating driver, with a fairly large
timeout value, so please let me know if it doesn't work.

Autocalibrating means that you calibrate the joystick in-play by moving
the joystick to all the extremas (any two opposite corners are good
enough).  Note that the joystick is polled only once each frame, so you
might need to keep it still for a moment to make sure the extrema is
registered (on a slow machine).

The joystick buttons don't do anything yet.  Hitting 'J' will reset the
driver entirly, so you can plug in your joystick even after Zox3D is
started, then recalibrate with 'J'.



Implementation notes:
---------------------

ZOX-3D is written in C/C++, except from the fixed point macros, the
division by 0-handler, and the direct screen drawing routines.  The
fixed point library was based on the one Michael Abrash introduced
during his development of XSHARP.

A word about the inline assembly routines for wall drawing ---
conditional defines are provided for enabling and disabling at wish:

    Inline assembly vs. pure C++, and
    Static assembly code vs. self-modifying assembly code.

Thus, it is possibly to compile, link and run a C++-only version of
Zox3D.  This is of course much slower than the self-modifying assembly,
but the C++-code might prove valuable in the future, if Zox3D is to be
ported, say, to a 32-bit protected mode environment.  It also
helps providing an algorithmic explanation of the inline assembly.

At the moment, speed is not the main issue.  Rather, I'm working on
adding as many effects as possible (transparency, moving bitmaps,
etc.).  Eventually I might find the code stable enough to optimize the
time critical code in pure assembler.  I don't think it will be worth
it though.  Because of the new dimension added by mirrors and
transparent walls, ZOX-3D is bound to have a lower frame rate than
Wolf3D.

Textured floors and ceilings also make things much slower, as it is
impossible to interpolate linearly through the bitmaps when drawing the
floor/ceiling column by column.  If it weren't for the mirrors, the
floor/ceiling could have been drawn line by line, which is potentially
*much* faster.

The RESOURCE.DAT file is a text file describing the bitmaps used in the
demo.  The first number is the number of bitmaps, then the bitmap
descriptions follow, one on each line, in this format:

<width> <height> <type> <filename>

The bitmap used is cut from the file, as the rectangle with corners
(0,0) and (width-1, height-1).  The type field is ignored in this
version, but will tell the resource loader wether the bitmap is
transparent, mirroring, or does some other effect.  Currently, only
Deluxe Paint II Enhanced 256-color .LBM files are supported, and the
resulting uncompressed raw data must be smaller than 64 Kb.  The .LBM
files supplied with Zox3D are all 320x200 and use the same palette.
The palette used in the demo is loaded from PAL.LBM.

A word about the LBM files.  DeLuxe Paint II Enhanced does something
strange to the file if it is saved when a stencil is enabled.  DP2E
reads it fine later, but I