i can to execute only THIS for each point and nothing ....

ZS= (XP*XZ + YP*YZ + ZP*ZZ)
XS= (XP*XX + YP*YX + ZP*ZX) * ZO * (ZS+ZC) + XC
YS= (XP*XY + YP*YY + ZP*ZY) * ZO * (ZS+ZC) + YC

because i have precalculated all THIS before

XX, XY, XZ, YX, YY, YZ, ZX, ZY, ZZ are raw values precalculated. Its meaning, means

By example:

"XY" = In which amount (or level) the (X position 3D) will affects the Y position on the screen.

where the first leter is the 3D position, and the second leter is the effect on the screen.

Quote:

a 3x3 matrix results in 9+6 =15.

what are you talking about?

a to pre-save a table with all values?

impossible if we want like 256 diferents point of view for each axis

256*256*256...

or with big jumps

16*16*16 convinations....

in all ways there is too big tables to be generated, taking in account that each recod needs to save 9 bytes value

That is exactly what i mean with matrix calculations
your matrix is:
| XZ YZ ZZ |
| XX YX ZX |
| XY YY ZY |
and your vector
| XP |
| YP |
| ZP |
if you multiply these two you need 15 calculations

i am not talking about pre-saved tables i was starting to think you were

I do like the idee of a 3D Bosconian not that 1st person shooter (maze!) crap.
so i am looking foreward... or sideward... or upward... or in any other direction !

Quote:

That is exactly what i mean with matrix calculations your matrix is: | XZ YZ ZZ | | XX YX ZX | | XY YY ZY | and your vector | XP | | YP | | ZP | if you multiply these two you need 15 calculations

no no no , just count the ammount of * here

ZS= (XP*XZ + YP*YZ + ZP*ZZ)
XS= (XP*XX + YP*YX + ZP*ZX) * ZO * (ZS+ZC) + XC
YS= (XP*XY + YP*YY + ZP*ZY) * ZO * (ZS+ZC) + YC

and if you have a fixed zoom, you can to avoid two *, so that 13 can be 11 multiplications...

If were just counting the stars
then all i need is 9 calculations or not... aha that
must be the reason for a 4x4 matrix. When we use a 4x4
matrix things like scale and zoom can be included within the
matrix the number of * becomes 16 then but some of them
are zero so maby, if you check for them, the result is 13 indeed.

i will try to find the last version of the first part of the formula to do all the precalculations, without the VY(x) shit. to set it more clear.

The way I see it it is still just a mater of different notation and approach
Use of vector notation or seperate scalar notation in the end
its the result that matters.

Were both on the same track, same train even .

And about those precalculations, the result you get from those can
be writtten in matrix notation, or format, and with that matrix you can
calculate every new point you want. So with those precalculations
you have build your own matrix.

I remember now that 4x4 matrix is not needed to include zoom but tanslation.

so for that shaded objects/ wireframe demo in calculus they could have used
a 3x3 matrix and so 'only' need 9 multiplications for each point.

you can make one precalculation step to complement my formula shorter?

there is the one that i reach, but as i am not a math geek.....

is the one in the picture but with the variables renamed to make a bit clear

original code just retype

L0=ABS(VY(4)+192)-128)/64-1
L1=ABS((VY(6)+192) MOD 256-128)/64-1
L2=ABS(VY(5)-128)/64-1:L3=ABS(VY(6)-128)/64-1
L4=ABS(VY(5)+64) MOD 256-128)/64-1
L5=ABS(VY(4)-128)/64-1
L6=ABS((VY(5)+192) MOD 256-128)/64-1

until here are all just CASTING because as input range i use 0-255 byte.

L7=L3*L4
L8=L1*L2

and here are two multiplication that in the original formula (large one), this two multiplications are done several times, so i just does those one time, and then use the L7 and L8 values.

and now the real calculation

XX=SIN((L2*L3+L1*L0*L6)*1.570764)*VY(2)
XY=SIN((L8+L7*L0)*1.570764)*VY(3)
YX=SIN(((ABS((VY(4)+128) MOD 256-128)/64-1)*L1)*1.570764)*VY(2)
YY=SIN(L5*L3*1.570764)*VY(3)
ZX=SIN((L7+L8*L0)*1.570764)*VY(2)
ZY=SIN((L1*L4+L3*L0*(ABS((VY(5)+128) MOD 256-128)/64-1))*1.570764)*VY(3)

as you can see there is some CASTING too...

IF L6*L5>0 THEN XZ=1-COS(L6*L5) ELSE XZ=-1+COS(L6*L5)
IF L0>0 THEN YZ=1-COS(L0) ELSE YZ=-1+COS(L0)
IF L2*L5>0 THEN ZZ=1-COS(L2*L5) ELSE ZZ=-1+COS(L2*L5)

well, there are some logic part, to make that XZ,YZ,ZZ are always in the range from 0 to 1... because then normal values of COS(x) are from -1 to 1

this in assembler are too fast, there isn't any division, all are aditions and multiplications, SIN & COS values can be readed from a table.

as you see all was thought as a pre-step for the assembler coding.

now the same code all togheter, but changing the variable naming

L0=ABS(XV+192)-128)/64-1
L1=ABS((ZV+192) MOD 256-128)/64-1
L2=ABS(YV-128)/64-1:L3=ABS(ZV-128)/64-1
L4=ABS(YV+64) MOD 256-128)/64-1
L5=ABS(XV-128)/64-1
L6=ABS((YV+192) MOD 256-128)/64-1
L7=L3*L4
L8=L1*L2
XX=SIN((L2*L3+L1*L0*L6)*1.570764)*AX
XY=SIN((L8+L7*L0)*1.570764)*AY
YX=SIN(((ABS((XV+128) MOD 256-128)/64-1)*L1)*1.570764)*AX
YY=SIN(L5*L3*1.570764)*AY
ZX=SIN((L7+L8*L0)*1.570764)*AX
ZY=SIN((L1*L4+L3*L0*(ABS((YV+128) MOD 256-128)/64-1))*1.570764)*AY
IF L6*L5>0 THEN XZ=1-COS(L6*L5) ELSE XZ=-1+COS(L6*L5)
IF L0>0 THEN YZ=1-COS(L0) ELSE YZ=-1+COS(L0)
IF L2*L5>0 THEN ZZ=1-COS(L2*L5) ELSE ZZ=-1+COS(L2*L5)

well, there are surprices for me, the printed sheet that i found is not too early version, in the STEP 1, already are AX and AY (amplitude X, amplitude Y) (see at the end of the formulas), so, in the short and second STEP executed one time per point to draw has after all 11 multiplication and NOT 13. And having AX and AY separately makes freely the amplitude of the window for X and Y.

NOTES: XV,YV,ZV are the rotation values of the axis, its range are from 0 up to 255. where 64 in 90° degree rotated, 128 = 180° degree , and 192 ofcourse are 270° degree.

AX,AY are in pixels of the screen, if we want a full screen in SCREEN 8 drawed, AX=256/2:AY=212/2


STEP 2

ZS= (XP*XZ + YP*YZ + ZP*ZZ) 
XS= (XP*XX + YP*YX + ZP*ZX) * (ZS+ZC) + XC
YS= (XP*XY + YP*YY + ZP*ZY) * (ZS+ZC) + YC

XP,YP,ZP = -1 up to 1 range. In a assembler version is used INTEGER signed.

XC,YC aims to the center of the draw in the screen, normally XC=256/2:YC=212/2

The absolute value on the STEP 1 is 1.570764, and it is a value to compensate lose of amplitude ranges. Why the formula lose amplitude?

SIN(x)*SIN(y) (in its 45° degree boths), it is 0.70XXXX * 0.70XXX giving as result 0.50 ...... and that as maximun value, and not giving a range from 0 to 1
// corrected this part: 0.5 as result is too little value, at 45° axis in both, not needs to return 1 because this is not the case, but needs a little more).... if you don't do the corrections you can see how a cube just decrease a lot in size when you rotate the figure, as more axis are near of any 45° degree more little is the cube.... that is not normal to see. So i inserted this absolute values to compensate this problem. IN assembler version it is just another casting//



if we translate those errors of ranges we at the end will gets very little values, and we can't operates with that.

well, that is all....

surely it can have big improves....

and i hope all guys capable of help. So in that way i can to pick up this droped proyect. That born when i was a teenage.

It's really cool to find so much people interested in 3D matters
Sorry for my delay but I was a bit busy.

This is, in short, how E3D works.
Let's say that a vertex is a set of 3 coordinates: x, y and z.
Every E3D_OBJECT is made up of its own set of vertex: a vertex list.
In this vertexlist all coordinates are local: relative to the "center" of the object.

(1) - Applying a local to world transformation you get a worldVertexList where every entry contains the coordinates of vertex relative to the "world" origin.

(2) - Applying a world to view transformation you get a viewVertexList where every entry contains the coordinates of vertex relative to the "view-point",
substantially the origin of the world is moved into the camera.

(3) - Applying a view to screen transformation you get a screenVertexList where every entry contains the x and y coordinates of every vertex relative to the center of your viewing window (real screen coordinates are obtained adding an x and y offset: the position of the viewing window on your screen).

Transformations in (1) and (2) may be achieved with matrix multiplication:
multiplying every vertex (which is an array of 3 coordinates) by the related affine matrix
(9 multiplications and 6 additions for each vertex (right GhostP? ).

In (3) extra caution is required because of perspective.
I use a world-to-screen method: all vertex in the viewVertexList are
projected on a plane (which is the viewing window on your screen).
This plane is placed at a focus distance from the eye (or camera).

Focus values are application dependent, personally I choose 5/6 of window vertical size
(if your window is 640 x 480 then focus is 480*5/6 = 400).

To obtain screenVertexList I use these proportions:

xView : zView = xScreen : focus
yView : zView = yScreen : focus

so

xScreen = (xView * focus) / zView
yScreen = (yView * focus) / zView

zView must never be 0.
Also negative numbers are not convenient: vertex is behind the eye so it is not visible.
Clipping on z axis is required, if you are managing a starfield then
if a vertex as z < focus the problem is trivially solved.
If you are managing segments or polygons then it's a bit more complex,
but this is another argument .

Once z clipped (all z are >= focus), your primitives could require x and y clipping too (if 1 or more vertex drop outside your viewing window)...
this is also another argument .

Out of stage (3), once clipped in every direction, rasterization can be performed.
Actually E3D uses painter algorithm (far to near drawing order).
Software Z-buffer cannot be achieved in real-time also for R800 .
I hope one-chip MSX will give us the speed to do this.

/***/

Precalculated sin and cos tables are (in my opinion) performance effective,

E3D angles are 8 bits wide (unsigned) so 256 possible orientations.
Sin and cos values are 16 bits wide with the following format:
1 bit = sign
1 bit = integer part
14 bit = decimal part
Sin and cos values are obtained with a 512 bytes (each) precalculated look-up table.

E3D coordinates are 16 bits wide, C integers.

So when a coordinate must be multiplied by a sin or cos I can
use R800 16bit multiply instruction and to keep only the 16 m.s.b. of the result.
(I loose precision but gain speed).

Moreover localVertexList is never modified so the "original" object is preserved from
degenerating after many rotations.

/***/

If you wish a deeper (and surely better) explaination I can send you documentation
from an online book where all these things are (in my opinion) well detailed.

Quote:

you can make one precalculation step to complement my formula shorter?

Scaling and zooming can be done by multiplying de matrix's diagonal by
a scaling factor. A matrix to scale will look like this:
| fx 0 0 |
| 0 fy 0 |
| 0 0 fz |

Quote:

Lots of complex basic code

I would be lying if i told you i know exactly what that piece of code
does. But keep in mind that if this is a piece of optimized code you might have made assumptions on the way that will effect the number and/of applications
it can be used for.

My opinion still is if you are going to program coplex stuf like 3D you
use an obvious approuch and clear methode like verteces(vectors)
and matrices. They might seem slower but like i said before a matrix contains
a lot of zero's so checking for those will speed up things.
And you are gona need a 4x4 matrix because you need to translate (shift or
move) other objects, with different orientation, into your 'camera' matrix.

But i see that MicroTech is well informed on this matter.

Quote:

no no no , just count the ammount of * here ZS= (XP*XZ + YP*YZ + ZP*ZZ) XS= (XP*XX + YP*YX + ZP*ZX) * ZO * (ZS+ZC) + XC YS= (XP*XY + YP*YY + ZP*ZY) * ZO * (ZS+ZC) + YC and if you have a fixed zoom, you can to avoid two *, so that 13 can be 11 multiplications...

euh, multiplications is not the same as calculations.
the total CALCULATIONS is the som of "*" and "+"... duh

how'bout some 3D faqz on computer calculations and stuff... somewhere on the net. plenty of shizzle I'd say. even basic source codes. or else compilate all your stuff together and write a dedicated article to publish here on mrc!

no cents, sorry.