Code - 3D engine for Elite

Planet landing in 3D
 3D engine published in the past but─ 
at least, significantly improved, and made to it 
absolutely fantastic (by the standards of 8- 
bit machines) example! We give the floor 
to the author of this example -Dragons' Lord: 

 1. Source 3D Engine

   In order not to get confused in the multitude of mods─
fications of the engine, for some time now I have become yes─
assign conventional numerical values to versions.
My classification:
  - 3D engine 0.01 - initial prototype 
2016 
  -3D engine 0.02 - introduction of rolls
 - 3D engine 0.03 - some fixed 
overflow glitches 
  - 3D engine 0.04 - introduced auto-detection 
mouse and jump 
  -3D engine 0.05 - intermediate "no─ 
interlace1к", as the author himself called it 
  - 3D engine 0.06 - "fixinterlace", controll 
The addition of the "solid state screen" mode has been removed 
no interlace 
  - 3D engine 0.07 - feature introduced 
color video output on an ATM computer 
  - 3D engine 0.08 - the function "pa─ was written 
norama 360°", printing raster graphics 
on the back 
  - 3D engine 0.09 - added non-coloring 
ba, continuing the panorama drawing. 
   I will consider the version "3D engine 1.00"
Fully 3-dimensional option, suitable for
implementations "Elite". Now the engine is calculating─
calculates space using simplified formulas, and
I can’t imagine the implementation of full-fledged 3D─
seems possible. The current version is excellent─
goes for shootersfirst person and reality─
tions maze a laWolfenstein 3DorDoom. 
That is, 2-dimensional levels. Although the imitation of cre─
on and jumping are present.

 2. My modification

   I note that modifications have been made
version of the original engine  "3D engine 
0.06",but then the result was combined with 
version 0.09. Rolls for this task are off─
luciens.
   Firstly, you need to understand why the modification is needed─
tion is generally needed. The original engine has a number
points that confuse the user.
   Format of axes used in design
of the objects themselves (vertices): X axis -
from us, the Y axis is to the right, the Z axis is down. Format
space in which you place these
objects in the main code module: X axis - on
us, the Y axis is to the left, the Z axis is down. Format
space in which he moves
character (i.e. camera): X axis is from us,
Y axis is to the right, Z axis is up. How will he notice
attentive reader, I don’t beat space─
no way. And if the inversion of the first is logical
explain, it always happens that after
camera transformations invert objects
their axes, then the discrepancy between the last two
dimensions leads tocomplete impossibility
program adequate movements
objects in the dimension of camera movements. B
This issue is not resolved in the original engine.
   The second major limitation applies─
The beauty of the engine lies in its dimensions
scenes. Although they are used for coordinates
register pairs, i.e. 16 bit values,
but the engine is able to adequately calculate
only dimension -1023...0...+1023  for all
axes Next comes the repetition of objects in the scene─
us. That is, if you put a column in
coordinates0,0,0and run in any direction─
well, then through2048internal units is simple─
I'm afraid you'll come running to this table again─
biku, but on the other side, and so much─
multiple times every 2048. Moreover, in view
simplifications for calculating the position of objects, about
which I already mentioned, you will no longer be able to
interact with this object adequately─
but - with any rotation of the camera the object will be damaged─
children jump chaotically around the stage. Adequate
work with corners will only be within the limits
zero quadrant.
   Modification of object display logic─
tov in the dimension of the scene is designed to solve both
problems at once.
   How this is done: in the control module 
"script.asm"  output of calculated values 
mcamx and mcamy are intercepted, and the output goes
not into them, but into new memory cells camX, 
camY,leavingmcamxandmcamyin zeros. Thus 
Thus, the camera is hung in zero co─
the ordinates of the scene dimension and hangs there forever─
yes. Now if you press the buttons - nothing
will not happen, we are not running anywhere.
The world display logic changes to invert─
I understand: before, objects were motionless, but not
We moved the camera, now the camera is stationary─
woman, and we move the whole world around her.
All objects in the main code have at the beginning
block increment by the difference between their "from─
initial coordinates" and imaginary position─
position of the camera, i.e. coordinates placed
incamX, camY.
 That's it, now the camera is always at zero
quadrant, and the axis of movement of objects about─
inverted, entering into synergy with those
axes shown by the camera ( Z axis in
is not affected by this release because
it doesn't make sense). Now you can objects
adequately move dynamically: if yougave an increment  +100 along theX axis, that's exactly
this will happen visually.
   A range modifier has also been introduced. All
objects of the proposed level are divided into
conditional conglomerates (example space─
rno 128x128x128 internal units), which─
The distance from the imaginary camera is then checked
to the coordinates of the key object of this kong─
lomerata. If the range is greater than the specified one -
the conglomerate costs byjpand does not perform─
disappears, and the objects of the conglomerate disappear from
scenes.
   This mechanism (analogous to streaming conte─
iners, which have been developed for several years
developers"Star Citizen"and who without─
conditionally proud) allows you to solve one thing─
temporarily three problems.
   Firstly, the range can be adjusted and
thus unloading the stage under the car
with any processor clock cycles. Less distance─
density, fewer objects in the frame, higher fps.
Setting at the very beginning of the module 
"my_lunohod.asm" and looks like this: 
  - dalnost=%11111111: 256 space units─ 
nstva - for cars withprocessor frequency 
3.5 MHz; 
  - dalnost=%11111110: 512 space units─ 
nstva - for turbo mode 7.0 MHz; 
  - dalnost=%11111100: 1024 units simple─ 
for the Evolution mode 14 MHz, but 
not recommended for use, or required─ 
but switch the range of the engine itself from 4 to 
3 (the fact is that the maximum capacity) 
possible object with a diameter of 64 disappears the visa─ 
alternatively with range=4 set to approximately 
distance 1040, that is, it will be visible at 
the very edge of the horizon like a chaotic ripple─ 
current copy). 
   Secondly, a new built-in pose range─
will overcome the main limitation of is─
running engine and select a scene from as many
anything bignumber of objects that─
These are placed in the scene-forming code
all at the same time (now on stage 200 not─
dependent objects).
   And thirdly, what is obvious, you become
all accessible for development and travel
16-bit dimension of space across all
axes And without the fear of encountering a repeat─
new appearance of objects from another quadrant─
ta.Now you can build a city on the map 
0..65535 size. Your 
coordinates in the format XXXXX_YYYYY_ZZZZZ - and
you can see your position on the car─
those (you can disable9000cycles are extra
they won't).

 3. Level

   When the main technical points re─
Sheny, you can go directly to the creation─
honor - to development. As a sample
to evaluate the engine's capabilities, I chose
planet landing module from the game"Elite
Dangerous". We will build the ruins of the guards, 
general development plan is shown on the screen 
"elite_0_05_alpha_Original Guardian Ruins 
from the game Elite Dangerous.jpg". Built by 
only the entire central part is external
small buildings in the corners should not be completed
became. Why? Because the totality of fi─
fishing level is now just within one
Spectrum memory pages, i.e. fits
in  16384 and can, if necessary, successfully
stored in a 128K top memory bank as
one of the game levels. My level files -
this is specific:

"rotmodel.asm" 
"3dmodel.asm" 
"my_lunohod.asm" 

 Now they are located in memory as follows─
in a general way:

> >>> ORG - start my level 33831 
> ---------- rotmodel vertex --- size 6180 
> ---------- model poly -------- size 881 
> ---------- lunohod code ------ size 8416 
> -----------RESULT (all my level): 15477 
> >>> ORG - end my level 49308 

 Complete the level if necessary, to─
Of course, you can - for this you need to remove the rice─
panorama key and set in the engine settings 
endfree=#10000,which will give8Kadditional 
memory in the top page.
 A few words about the reali form factor─
called buildings. Present in the level
simulation of correct lighting, although in IS─
There is no lighting in the running engine. All buildings
painted as if the light is falling from the od─
no side. To do this, I had to store it in
memory copies of some axis-asymmetric
objects with different colors. This is of course
bad. The Spectrum's memory is not rubber.
If you remove these objects and expose them to light,
approximately1.5 .. 2 kilobytes will be released.
But it won't be as photorealistic. Also,
except rotation and sine shaders
moving dynamic objects on the fly─
moving objects will throw a shader on, simulating─
dynamic correct lighting, a la
Flat. The colors on the edges are changed (in
module  POLY ) for certain ranges
the angle of rotation of the object.

4. Conclusions

   The project was done with the goal of getting a complete─
a true and true representation of:
  -What will be the speed of rendering the scene 
a la "city". It can be noted that speed 
on machines with standard clocks 
(70000) is really not enough. Received 
the result is on the verge of critical value 
min fps=8. And this is in interlace mode, i.e. 
with interlaced output.  We conclude that 
the demonstrated level is the maximum 
possible dense development.  Necessary 
increase the distance between individual ko─ 
anglomerates (essentially “houses” for the future 
maps).Also on the proposed example view─ 
but in the "myopic" mode with range 
256 difficult to navigatespace─ 
tve, especially for a person who has never 
I have not seen this level before. Introduction car─ 
you in any form, with the player designation and 
buildings is a prerequisite. 
  -What will be the visual perception of ra─ 
evil objects. You can mark one as 
not strange, but a technical problem. Mac─ 
maximum possible size of one element 
= 64. To depict something fundamental─ 
too large, it is necessary to reduce the "height", 
and essentially an increment by  +z  in the file 
"script.asm" from default  #020  to  #010. 
Then two-level buildings “with a roof” 
are perceived as adequately as possible. But 
with the reverse side of the medal, the entry─ 
which contradicts the first one, is from─ 
drawing a flat tile underfoot, which 
in some places it is recommended to pave the road 
(much easier to navigate in 
"spherical vacuum"). The tile cannot 
adequately rendered from such a height 
small height due to fake rendering 
objects in the engine, - the tile starts to hit 
in inadequate convulsions. You have to─ 
make some compromise that worsens the indicated─ 
additional parameters to a certain value. A 
you cannot increase the number of floors of the building─ 
you want, becausethat there is not enough speed 
for rendering such multi-component elements─ 
glomerates. If we return to perception 
objects, it is shown that there are many complex ones─ 
component "houses" from non-standard arches─ 
nyh designs of reduced thickness depending on─ 
is excellent. At the same time, standing alone─ 
These simple geometric shapes look like 
disgusting and not perceived by the brain, 
as some kind of “buildings”. Even in cases where... 
where are such small separate objects 
a lot in the frame. During construction it is worth 
adhere to the “rarely, but accurately” rule. 
The brain wants the building to have a "roof" 
neck", which you can go under. 
  - What will be the size of the occupied memory─ 
tee. Memory is being used up faster than expected─ 
elk. I have already described the structure of the level above 
here it can be noted that the creation of similar─ 
higher levels are quite possible if you keep 
your wishes within some framework. Demo for─ 
shows a strictly static picture of the structure─ 
niy. There is no gameplay. Dynamic objects 
(guard drones) no.  Interactions with 
no objects.  Interactive change 
no buildings. Procedural generation is high─ 
variable soil and random RND objects─ 
there are no ruins outside the zone. All this is planned─ 
else and can be written without problems. 
This is not the case due to the desire not to litter 
demo level code. For a beginner you need 
gradual introduction to the 3d engine. Here 
which will probably never happen - this is fi─ 
ziki. I'm talking about prohibiting the player from walking 
through the walls. For a level with arbitrary 
development within 3.5 MHz is unsolvable 
task, and it is proposed to leave it as is. 
Relying on the player's imagination. In projects 
ala "Wolfenstein", with a regular map, 
physics is implemented very simply. 

 5. Conclusion

   I have not found a limit to the number of simultaneous
drawn objects, although checked─
ryal somewhere up to the number 60 pieces. This is oz─
starts that your fps will most likely rush to
zero, than you can display a bunch of objects─
comrade in attempts to hang up the system. This is nice─
but... Nothe buffer will not overflow.Oso─
It really warms the soul when you remember
limitations in standard Spectrum
"Elite" - no more than 6 dynamic objects 
simultaneously + station. Here you can─
drive as much as you like if it fits
to allocated memory: 52016..52992(_tables) 
free for object list 976  (one output 
the object takes16 bytes).
   By rendering speed: if you imagine
standard "Elite" and take the normal ones─
convex volumetric objects, then you can safely
draw 4 one such object per frame─
temporarily ( ~60  polygons). fps will not drop
below 10at any approximation. This is quite
usable. 5  objects simultaneously ( ~75
polygons) - fps will not drop below  8. This
critical, but acceptable.  Naturally II mean interlace mode. So
The “elite” with filled edges can be realized by those─
It is technically possible if you complete the calculations
inside the engine to full 3D.
   I really liked the conclusion. Speed
filling and displaying the video buffer on the screen for─
ultimate. This is the only engine where you
you have practically nothing to lose by asking about─
The ability to draw to the full screen of the Spectrum.
Rendering takes up only a small part of the total
settlement time.  Maximum load
system for calculating vertices, so accept
the rule is not to produce extra vertices without Cree─
technical necessity.

   Thank youAlone Coderfor the magnificent
work and hope for a full 3D implementation.

   Sincerely,Dragons' Lord.