Code - Sector-by-sector engine for a 3D shooter from Destr.

Info Guide #12
Sector-by-sector engine
 Sector-by-sector engine for 3D shooter
Destr

   The main idea of the engine is the engine, opi─
sleigh in "Adventurer #13: Sharing Experiences -
How to write a 3D game like DOOM." 
(http://zxpress.ru/article.php?id=10028)
 But I was unable to convert their code to
my ideas, so I’ll just state them
general principles. The main difference is not
fill the walls.
   Those. we have a world made up of convex
sectors and display only the floor and ceiling.
All this is to speed things up (you want more...
more frames).
   So, take a sector - for example, like this:



   The camera is at point 0, "look"
directed in the direction of the arrow.
   It is necessary to project all points of the sector into
perspective and crop to the BORDERS OF THE SCREEN.
How exactly to project is up to everyone to decide,
but it is obvious that the perspective projection is here
most acceptable, i.e. "up" in the picture
- this is Z ("depth" of the screen).
   We get something like this:



   The red rectangle is the screen, i.e.
everything that is outside is no longer visible.
   We have "Gender" :)
   Now, if we want the floor height and according to─
sense in all sectors are the same (and this
will give an increase in frames per second, i.e. ceiling
no need to project separately), then “then─
lok" can be obtained by simple reflection
"floor" upside down.



   If different heightsthe ceiling is still ho─
It seems like a waste of time on projecting the ceiling
It’s still a pity, then we can compromise─
miss - print ceiling not with middle
reflection, but with displacement.

 

   If the shift is down, the effect is different
there are heights, although not perfect.
   If you want higher, then the offset should be
be up.

 

   But, as can be seen in the figure, you will also have to
clip once along the top border.
   This is not good for speed.
   Now all that remains is to connect the corners (those
visible on the screen) - and the view “into the room” is ready.

 

   So that the visual effect of volume can be felt─
Timaeus - it would be necessary to fill the floor and ceiling.

 

   On Speccy, filling is enough for this
"through the line" (again, for speed).
   So we got a poured floor, ceiling and
bare walls. Apply texture to them
- long, but we focus on speed. For
the shooter will work fine if all the walls are there
white - the main thing is the atmosphere.

   Now about the connection between sectors. For that─
go, so that you can see the content from one sector─
my others, you need to run through the handler and
on the neighboring ones. Which one is fully visible?
or partially, it’s not difficult to find out, but with
there are nuances in the display.
   First you need to build the farthest view─
the dark sector, then the one that is closer - and so on
as you get closer to the camera. But! Build─
tion occurs after FULL processing of all seconds─
tori that are closer to the camera - and here's why.
Let's say we want to expand ourmini world
for one sector, for example, like this:



   The green color shows the “adhesion” between
sectors.
   We project:

 

   Expanding the "ceiling"

 

   Here the BORDERS are highlighted in blue.
CLIPING for the "far" sector. If
from it you can see something even more distant, it
will be clipped along the next edge
"adhesions" (or screen border, if edge
climbs out for him).
   The speed gain here is that these
boundaries are always strictly vertical, and
cheat, the math doesn't take much time─
tny. The ceilings are drawn sequentially, and,
accordingly, their joints will not even be
bottoms (after all, you can upload all this byte by byte,
or even a couple of bytes).
   If you leave the same floor height/
ceiling for all sectors, then you can not
fill in and get an engine that will
quite smart, but primitive. By complexity─
No, it will be like a classic square one
raycast engine, but with the possibility of any
corners, but without textures.
   If you make the possibility of different heights
ceiling, then you can do more than just a corrido─
ry-rooms, but also interior doors (and they
They will even be able to move apart, revealing
what is behind them), but the speed of calculations and
rendering will drop so much that the shooter won't work anymore
you build, and you can create a beautiful labyrinth adventure game
make it on the 3D Construction Kit engine...
   For all this (even for the most simple matter─
that version, without fills) you need math─
ka good (8.8 asminimum) and fast.Where
I don’t know whether to take one, but what I myself
invented it, showing it is highly not recommended─
sulking.
   Surely you can adapt Adventure─
ny #13 engine from the article (whichDUKEmain), 
but first you have to spread it out on the floor─
kam that, again, it didn’t work out for me.
   However, if you still manage to do
wire runner, then stands up to full
growth, the question is what to do there. We need lies─
gi, you need weapons, but to bring all this out too
very long. Reluctantly, you can withdraw
weapons deployed (and therefore pain─
smaller in terms of memory capacity) procedures, but with
with scaled enemies this is probably
it won't work.

Also the question of ne─
movements within the sector and "resting" in
wall. Calculating in advance can help here─
solid arrays of all walls for all sects─
ditch, but even in this case quite a lot
there will be time after EACH player step
spending money on checking whether we are trying
climb the wall" toif so, then no─
do not make any changes. In such cases, polo─
you can “slide” along the wall, and this too
not an easy task. True, you can store ka─
each sector is not only an array of coordinates
describing points, but also as a set of certain
"vectors", then warehouses will be enough─
align their direction with the current direction─
look and take a step in the resulting
direction. But this is in theory, in practice
it is not known whether it will work.

   There is an idea that it is possible to cross the sector─
new organization with raycasting. For example,
do not count all sectors, but only those
that catch my eye in the current position─
tions. This can be done by first preparing
an array that will be filled with numbers
sectors that are engaged by emitted from
camera fan. Of course he (the fan) won't
too frequent (far from it)for every peak─
village). Perhaps this will speed up the calculations, but...
it is possible, and vice versa...

                  * * *

   Ed.:
   See the demo in the app.
   To fill the floor and ceiling faster
gray, it is better to use interstro─ 
fine mesh, for example, 25 percent. 

   (It is assumed that the screen is initially
cleared by value#ff,lines are drawn but─ 
faces.) 
   We go from the top of each column of the screen to
middle, initiallyc=#ff:

 ld a,c
 and (hl);accumulate zeroes in the column
inc h
 and (hl);accumulate zeroes in the column
 ld c,a
;c=mask, which bits are needed in this byte 
 ;texture (units), for example. %11111000
;(hl)=lines to be superimposed (toes 
 ;against the background of ones), e.g. %11111001
 and d;e;texture line, e.g.%10111011
;a=%10111000 
cpl
;a=%01000111 
 and c
;a=%01000000 
 xor (hl)
 cpl
ld (hl),a;%10111001
inc h

   or
   (It is assumed that the screen is initially
cleared with the value #00, lines drawn 
units,c=#00.) 

 ld a,c
 or (hl);accumulate ones in the column
inc h
 or (hl);accumulate ones in the column
 ld c,a
;c=mask, which bits are needed in this byte 
 ;texture (toes), e.g. %00000111
;(hl)=lines to be superimposed (1 
 ;on background 0), e.g. %00000110
 or d;e;texture string, eg%01000100
;a=%01000111 
cpl
;a=%10111000 
 or c
 cpl
;a=%01000000 
 or (hl)
 ld (hl),a;%01000110
inc h

   We fill the floor in the same way - go from below
each column of the screen to the middle. 

   Both options take 50 cycles for 2
bytes, but work directly on the screen. 
   If we work in a buffer, and the hatching is on─
are placed in whole familiar columns─ 
mi, then you can fill the column through 
 xor (hl):ld (hl),a:inc l
(18 clock cycles per byte), 
and then transfer it to the screen with a texture 
through 
 pop bc
 ld a,c:and e:ld (hl),a:inc h
 ld a,b:and d:ld (hl),a:inc h
(24 clock cycles per byte). 
   Total 42. This is with a solid texture.
   When interlaced, every second is removed─
swarm ld (hl),a in the fill and every second 
ld a,b:and d:ld (hl),a (with possible replacement─
noyinc h:inc hnald h,N) in textured─ 
Vania, there are 20(19) clock cycles left per byte. 

   To save speed, you can remember
for each familiar screen column, 
what is his height now (minimum 
all linesincluded in this column, except 
vertical). And texture only this one 
height. 

Share your thoughts about the article