Point of view
Alone Coder
It’s not entirely obvious, but the projection is spacious─
nothing on the screen from one point
talks about distances, no matter how much
were spinning and spinning in different directions. Poe─
therefore, it is much easier to build such projections
than real 3D, and you can use it
and in games (Myst III: Exileetc.).
* * *
Let's consider the simplest case - let us
(camera) we stand at one point and rotate the game─
fishing only to the sides. We only have one
degree of freedom. What do we see?
We see the same thing as if we
stood in the middle of the cylinder with tension on
it has texture. Or the same as if
we stood in the middle of the cube. Or prisms. This
doesn't matter.
The cylinder is the easiest to implement because
what it allows at any angle of rotation
recalculate screen coordinates into coordinates─
dinata in texture with a simple look on the tab─
face (this will be a large table - for everyone
one pixel). It also allows other
method - at any angle of rotationwe use
the same table storing the offset in
texture and scale for each column.
(We scale the pillars like in Wolfenstein.)
This second method takes up significantly
less memory and really applicable. First
it was supposed to be used for three─
dimensional quest Big L, but during its development─
ke faced a number of difficulties, and this code together
with graphics I finally got into the demo
New Wave 48K.
48K is quite a strong limitation─
tion. The texture size had to be limited
512x128 (32 kilobytes), because for ka─
of each column (through experiments there were
columns with a width of 4 pixels are selected) it is necessary
have 4 different shifts in texture (to
have a step of 2 pixels).
Explanation about texture size: the point is
that you can shift data horizontally by hand─
nalli is slow, so you need to store shifts─
crumpled bytes. If shifted in increments of 2 peaks─
sat down (otherwise how to preserve the shading?), then
there will be 4 shifts. We do not store 2 shifted
copies in one byte (they would be slow
push and apply), but only one.
Therefore, with a width512 it turns out (512/8)*
*4(shifts)*hgt bytes, which is when hgt=128
gives64*4*128=32768.
You canimagine this projection in rice─
nke (top view):
(somewhere in the distance - the surface of the cylinder)
conditional screen
camera,
it is also the center of the cylinder
The formulas were:
For each n=-23.5..+23.5 with step 1
(this is the column number) considerx=n/24 (this
column number within-1..+1 ) we consider
anglea=arctg x (here the viewing angle is 90
degrees, otherwise other limits are needed forx -
smaller is better, but then you need a larger resolution─
sewing texture horizontally);
consider the scalek=cos a (you can add
coefficient, if we want to save on you─
saute texture or vice versa make text─
ru more precisely);
calculate the column coordinate in the texture
xtex=a*128/pi (it turns out -32..+32 - for
width 512 in 2 pixel increments).
The code used was:
ld d,h
ld a,(de)
exx
xor (hl)
and d ;#f0
xor (hl)
ld (bc),a
inc h
inc b
exx
inc d
ld a,(de)
exx
xor (hl)
and d ;#f0
xor (hl)
ld (bc),a
inc b
[ld a,c:add a,20:ld c,a...между знакомест]
ex af,af'
add a,e
jr nc,$+3
inc h
ex af,af'
exx
add hl,bc
This type of drawing in 2 lines is acceptable
due to small scale differences. It
not only does it speed up rendering, it also
and allows less damage to hatching on
picture.
This was one of the stages of the struggle for pure─
that pictures. Another was related to the problem
horizontal stretching (due to small─
whom texture resolution). If you leave
everything is as it is, then the vertical lines will be
duplicate. To partially hide this
defect in the existing drawn picture
(from Surfin' Bird), shifted copies of pillar─
tsov (the same ones that are 4 pixels wide)
edited as follows:
on the left border of the column (look at the floor─
bytes in pairs):
01?? -> 10??
01?? -> 01??
on the right border of the column:
??10 -> ??10
??10 -> ??01
You can do it the other way around (for other
pictures).
* * *
Now let's go out into a new dimension and...
Let's talk about raising and lowering the camera. Here
we again face a choice - which one
figure stretch texture: cylinder, cube oranother polyhedron, a sphere... And the choice is here
much more difficult.
If we take a polyhedron, we will get─
I want to worry about real 3D movement─
ka withtexture mapping (tmap), which reduces to
no gain from a fixed camera (although...
the model of the world is simpler).
If it’s a cylinder, then what to plug it with─
tsy? If you don’t shut it up, then we need endless─
fine texture. Or you will have to limit the angles
raising and lowering the camera (zenith and nadir
make invisible).
If the sphere - conversion formulas for each─
These pixels are simply terrible.
Only mesh nodes can be calculated
8x8, and interpolate between them -
simplified tmap. This method has been time-tested─
menu, and you can use slow ones with it
calculation methods such as:
1.Raymarching - voxel scanning─
volume using small steps. This
has already been described in the article"About the flying layer"
not" in Info Guide #10 (regarding the intro
#5 ). This is a very slow method.
2.This calculation of the projection of a cylinder onto
screen. For each point we calculate the arctangent
and all that. 3.Same as step 2, but we get rid of
arctangent, making the cylinder square.
As far as I know, such wisdom
on the Spectrum I only did SaiROOs in the demo
Dogma, and it turned out quite slowly even
for that solution. I didn’t look at the code, but ri─
I didn’t shackle him. In Nedodemo I chose the most
a simple method, and for good reason - it turned out that
even he could barely keep up with the then
compo machine Pentagon 102ХSL v2.2.
The simplest method is this - for everyone
We have our own table for the camera elevation angle.
We draw on the screen directly─
exactly on her. Moreover, we generate from
her code (ld a,(hl):ld (de),a:inc d with need─
nyminc/dec for h and l ). Project mo─
press on any figure with axial symmetry. I
chose the sphere.
The textures were designed for a cube (made─
us through a 3D model with 6 cameras), I changed─
read them on the sphere with the help of specially on─
written utility. You can find it in is─
Nedodemo walkers on my website.
It would seem that 27 pages of memory have been filled -
where to go? But if you don't generate code from
tables, then you can notice that the tables
mirror symmetrical inX and pairwise correlated─
correspond to each other byY (with reflection).If the task was to achieve this effect
in128K, it would have been completed. But in 48K
- no.48K the world is significantly different from
the world of extended memory.
Another question is what to do to raise
resolution of this effect to an acceptable level
games. Unfortunately, there is no answer yet. What
definitely - the texture must have a size─
solution exceeding the screen size of at least
than 4 times. In Nedodemo the resolution is tex─
tours 256x64 (it is slightly flattened in ver─
ticked) with screen resolution56x61, and those─
xels are visible. That is, for example,
for screen resolution256x128 you will need
spherical texture order1024x256 or
cube with textures256x256.
Share your thoughts about the article