the making of zxoom - the history of the creation of the game ZXOOM.

>the making of zxoom                           

Andrew771:                                       

  Probably many who have learned to program 
on Speck, created or dreams of creating a shooter from
first person on it.  This didn't go unnoticed
idea and me.  And the dream came true for me
only this year, 2011, 15 years after
start of development.   Together with the talented
artist ALKO and amazing screenwriter and
concept designer Black Cat, November 13, 2011 at
the public court was presented with alpha
version of the game ZXOOM. And it all began in the distant
1994, when I just bought my first one
home computer ZX Spectrum...                

  At that time I only knew how to program in
BASIC. I've always had a real Spectrum
only 48k. I liked it since school days
not only play various computer games,
like many, but also to write something of your own, and especially
your games. Most of my games are in BASIC
times and was written in 1994-1995.  Especially
I liked games where you had to walk around
labyrinths, then still two-dimensional.  This is Lode
Runner, Klad, Indiana Jones, Titanic and the like.
Naturally, I tried to write similar games in
BASIC.  The game was created under a simple
called "Labyrinth", where a little man in one
the character ran through the mazes, trying to escape from
twochasing him of the same size
enemies. There was no need to collect treasures in it, but
just look for exits from each labyrinth.  On
BASIC managed to fit 6 full screen
levels.   Performance was good.    K
unfortunately, at the moment the cassette with this game
lost, but hopefully within the confines of my apartment.
All other cassettes with other crafts,
by the way, were recently found, digitized in
formats for PC and released to the public.

  Around the same time I saw games for the first time
Wolfenstein and Doom on PC. Saw it on the monitors
computer store windows, in demo mode,
when everything just ran and shot.  To be honest,
it was a bit of a shock - is it really like that?
can I create? About buying your own pussy and
these games at home could not be dreamed of: then my
the scholarship was equal to two monthly travel passes for
bus. So, I had to look at the demo
mode (and I could stand like that for half an hour) or
how cool dudes play - computer sellers.
That's when the idea arose in me - to write
the same for Spectrum, so you can do it yourself
play. Not a single similar game on the Spectrum
I didn’t know then, a little later I only saw Total
Eclipse, but it greatly disappointed with its
speed.

  Naked Basic was immediately dismissed due to his
slowness for rendering and constructing scenes
vector graphics.Therefore it was decided
the solution is to draw these scenes in advance using
BASIC, each the size of a third of the screen at 2048
bytes, and then place them in memory. And withdraw
the desired scene quickly using machine code,
spied in the book "Machine Codes" of the company
"Solon", corresponding to ld assembler commands
hl,xxxx: ld de,16384: ld bc,2048: ldir, just
substituting the necessary addresses from BASIC with commands
POKE for hl register. It is worth noting that, in addition to
this sequence of commands and table
there are more symbols and variables in this book I
I didn’t understand anything then.  Thus, it is possible
it was possible to fit about 12-15 scenes and make
turns 45 degrees.   This idea was
embodied, but was soon rejected due to very
large discreteness. It wasn't the turn to 45 that was confusing
degrees, but only two or three levels deep
viewing, as well as monotony and repetition
scenes even with one 360 degree rotation,
which was disorienting and made the whole undertaking boring.

  So at the beginning of 1996 I decided to study
assembler, no matter what it costs me.  Was
purchased the most priceless book "How to write
game in Assembly language" (authors Kapulcevich and
Evdokimov) and its study began.  I study it
started not from beginning to end, but, as is often the case
happens with books, selectively - entered into the computer
only those examples that I liked orwere useful for the future of their Doom.

  I immediately liked the idea from Chapter 7 - that’s why
while some picture is visible on the screen,
form a different picture in memory
virtual screen, and then quickly copy it
to the screen. The example about
minibus driving along the highway against the backdrop of houses and
lanterns Then I began, on the advice of the authors of the book,
extend the highway and add fences, trees and
other things on your own. In general, I did it.

  Programming took place in GensCh and debugging in
MonsCh, and there was only one of the drives
tape recorder, so the whole process required
a lot of time and patience.     To
program some small bullshit,
sometimes it took half a day.  Especially long and
Stuffing sprite bytes was tedious.

  After squeezing out this example
everything that is possible (including trying to do
control the minibus from the keyboard on
interruptions), I finally approached again
impregnable fortress Doom.  The idea to do on
vector graphics, but in assembler, was
rejected: calculator program in ROM for
this was not suitable due to speed, but
creating your own trigonometry in assembly language with
pre-calculated tables of sines,
cosines and other things were, firstly, for me
it was difficult then, and secondly, it stood before my eyesbad example of the game Total Eclipse - in it I
I didn’t like not only the performance, but also
a small piece of screen on which
the game was unfolding. Although the game itself, of course
wow, a masterpiece!    For faster performance
there was no need to calculate with vector
graphics. About raycastings and ray tracings I then
I didn’t know, there was no Internet, and books
I was not interested in PC programming.  And
I decided to do it using pre-prepared ones
sprites rendered in 3D style and stored in
memory. And I decided to make the game full screen,
just like in the original Doom.

  The idea of the algorithm was the same as in
minibus - first we display it on a virtual
screen distant sprites, then over them more
the closest ones and end with the closest sprites.
The sprite output procedures were the same as
and in the book.  The bypass was written independently
maze cells when constructing a scene close up
player, starting from the farthest and ending with the nearest,
as well as moving the player around the cells
two-dimensional labyrinth.  Each cell can
contain not only a wall or passage, but also
any other element - column, barrier and even
the enemy in various phases of movement.  Enemies decided
do not make it a separate list, but embed it in
labyrinth cells - this unified the procedure
output the scene for all elements, as well assaved memory and increased performance.
There was no need to check every move
coordinates of all enemies, but only those that
are located in the nearest cells.

  To begin with, I decided to do only solid
walls, no textures. Took a checkered sheet of paper
32x24 and drew a grid on it with a pencil
prospects, I didn’t join Art Studio for a long time.  Here
along the way I decided that it could be done in color
sprites, if the mesh is slightly adjusted to
boundary of familiarity. Then the resulting ones on paper
rectangles, triangles and trapezoids introduced
manually in sprite format.  Because there was a lot
repeating bytes, the procedure was used
from the book of building blocks from identical
sprites, i.e. space was saved here too.

  Within a year, by mid-1997,
walls for all viewing depth levels and
the algorithm has been debugged. Everything worked - it was possible
navigate through a maze with monochromatic colors
walls that fill the entire screen.  Speed
movement was significantly higher than that of Total
Eclipse, however, is a bit slow for an arcade. But even
so it was a small victory - an idea
sprite engine had the right to life!  Now
it was necessary to optimize the code somehow.

  And then an event occurred that slowed down for a long time
my development on the Spectrum is a long-awaited purchase
PC. I finally played enough of the original Doom and
othersPC games. And the funny thing is, I realized that I
What I like most is not shooters, but strategies! Not
I will dwell on this period of life,
I will only say that during this time I mastered more
less programming in Delphi, which is now
very useful in cross development for
Spectrum. On PC I'm not so serious about anything
written, except for small text and two-dimensional
arcade games.

  And so, somehow wandering around at the end of 2010
Internet, I wanted to play something
old text - "Kingdom Euphoria",
for example. I found several different versions for PC,
I tried it and almost wrote my own in Delphi.  But
some kind of spirit in her was not the same - it seemed that everything
yes, but somehow more like MS Excel than
for the game. And, in the end, I decided to get an emulator
Spectrum, play with your old toy
"King". And at the same time look on the Internet, there is
Are there any other such crazy retrogrades? Immediately
I came across the spektrumist forum zx.pk.ru.  And,
Of course, I was amazed that he was alive, and a lot
participants! At one time in 1997 I thought
that he was the penultimate spektrumist, except
one friend there was no one else around at
Spectrum. And here it is!  That's when I woke up
renewed interest in the Spectrum, and wanted
surprise people with its long-standing development of Doom.
Now I have learned that Spectrum has also appeared
Doom, andWolfenstein, including on
similar sprite engine, for example, demo
game from Jukova. However, on a grand scale
There didn’t seem to be a screen yet (well, if you don’t count
games of lines and pseudo-symbols).

  After showing my demo at the beginning of 2011 from
ideas immediately poured in from forum participants on how to
the engine can be improved.  Valuable idea
submitted by NovaStorm - enter into the program
a kind of z-buffer that grew into
solution - display sprites in order not from
distant to near, and vice versa - from near to
distant Nearby sprites are much larger
sizes, so one sprite can cover
almost half the screen.  Previously nearby sprites
were displayed on top of distant sprites, nothing
checking, so often the same place is familiar
could be displayed several times. Now everything
there are more familiar places that the sprite overlaps
no need to output for other distant sprites,
which should have greatly increased performance.
At the border of sprites, masks are inserted according to
pre-calculated tables.

  The engine was rewritten and optimized along the way
procedures taken from the book. Now I have already written in
EmuZWin emulator by Vladimir Kladov, excellent
all-in-one tool. Game speed, like
expected, increased noticeably, so the engine
Already suitable for the arcade!  Also a huge help
rendered by Jerry,which is even successful again
remade the engine algorithm without using
virtual screen, and forming a table of addresses
displayed sprites in the required sequence.
Still, in my opinion, in terms of speed its code
was a little inferior with a large number of sprites,
but was faster in small quantities, and also
saved memory by a couple of kilobytes, which for
Spectrum is very essential!

  Sprites of walls and columns are stored in the new engine
not completely, but only their quarters, less often
halves, because there is their symmetry to the X and Y axes.
The remaining parts of the sprite are completed in the scene in
real time.   Moving algorithm and
shooting enemies was not difficult to write, it
solutions taken from my early BASIC
development of games for two-dimensional labyrinths and
simply rewritten in assembler.

  Now it's time to draw the elements
labyrinth, the player's weapons and enemies in various
phases of movement and shooting.  With this task
ALKO did a brilliant job, I liked it right away
his drawing style.  ALKO also gave valuable
instructions for the color scheme of the game, under
which had to slightly modify the engine.

  Projecting graphic elements
took place in a specially written for the game
cross development tool on PC C program
Y3D-ViewФ.  The program allows you to automatically
get sprites inassembly code from bmp-
files containing an image of the element's face,
for perspective projection at angles of 90 and 45
degrees and different distances of elements.
Now the perspective was built strictly according to formulas,
and not approximately by hand, as before. True,
Therefore, I had to abandon colored walls.

  The construction of the labyrinth was also not done manually, but
using another written cross-tool
on PC C U Labyrinth Generator F.  This program
allows you to generate random mazes
sizes from 3x3 to 128x128 (in our game
a 128x64 labyrinth is used) containing
various elements.    Can be adjusted
the probability of occurrence of elements, as well as
parameters for generating corridors and halls.  Ready
the labyrinth is output to assembly code.

  And finally, it was necessary to collect everything that had been done
put it together into the game, give it some kind of plot.  And
here the talent of Black Cat was revealed in full force,
created the concept and script for the game about the invasion
unknown civilization to just recovered from
World War III Earth.  The player in the face
the main character had to destroy the aliens
and their teleport. Thanks to Black Cat, the game received
name ZXOOM Ts after the underground city
Zetixum, where the game takes place.
The name is also deliberately consonant with the ZX Spectrum and
Doom by crossing them.

  Coming soonfinal release of the game.
We are currently refining and correcting the issues noted.
bugs, and also the splash screen and menu are written
luminary programmer Jerri, who knows everything
game code like the back of your hand.  In development
final release of the game will also take part
musician, I don’t know who yet.

  We hope you enjoy ZXOOM!

Share your thoughts about the article